什么是测试用例评审？
测试用例（Test Case）：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
评审：指评议和审查，审议。为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。
测试用例评审如何走向正规？
做事的方式有从上而下和从下往上，我比较擅长的是从下往上。
开始评审用例
正式开始做测试用例评审时，团队成员都不知道怎么做，而且团队有四个新人，技能和业务上都不够熟，为了让评审能走下去，我所采取的方式：一是设计测试用例人员先讲解下需求、再讲设计思路，二是测试经理、产品经理主动说出自己的疑问。其他人成员主要听和理解，这一评审方式好处 让团队成员可以更快地理解需求（在较短的时间内积累不同业务知识）。坏处就是：团队成员思考的时间少，不能发现问题，较难通过用例评审提高自己设计用例的技能。
我经过三个月的工作积累，也明显感觉到团队成员对业务有了一定的了解和分析能力，到了测试用例评审改进的时机啦，毕竟测试用例评审主要目的之一就是提高大家编写测试用例的水平。
优化评审方式
优化评审前，做一个培训会，再次告诉所有成员较为规范的测试用例评审会评审哪些内容，我们当前的评审有哪些缺点，如何来改进（这里有讨论），以下是初步优化内容：
1）提前一天发出需求和测试用例给参与用例评审的人员；
2）会议前2小时 参与用例评审人员 将问题反馈到 主持人；
3）主持人根据问题排优先级和严重程度（正式评审时 按优先级和严重程度 开始讨论）；
4）评审过程中发现问题能当场修正的当场修正，修正时间超过5分钟的，留到会后；
5）评估测试用例所需的执行时间和优先级；
6）整理待修正内容和评估修正需要的时间，会后发出；
7）设计测试用例的成员需要在预估修正所需时间内 发出 修改后的测试用例；
8）主持人检查 测试用例是否修正，没有修正则继续跟进；
9）测试用例的主持人每月换一次，测试部门成员轮流当主持人。
明规范、定标准
根据前段时间的测试用例评审经验，将前后台的测试用例进行总结，定义出明确的规范和标准：
1）简单业务需求 ，团队成员交叉审核即可；
2）核心业务流程+复杂业务，启动团队评审流程；
3）评审流程标准化，包括 评审人员的构成、评审后的签字确认等。
在公众号（ 51ste软件测试部落 ）后台输入 用例模板 ，可以获取一套常用的用例编写模板。