1:评审的过程
A:开始前做好如下准备
1、确定需要评审的原因
2、确定进行评审的时机
3、确定参与评审人员
4、明确评审的内容
5、确定评审结束标准
6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
B：开始评审
1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2、 通用邮件与相关人员沟通
3、 通用IM工具直接与相关人员交流
4、根据评审内容进行评审
2：评审内容
1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2、 优先极安排是否合理。
3、 是否覆盖测试需求上的所有功能点。
4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5、 是否已经删除了冗余的用例。
6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
3：参与评审人员（这里会分为多个级别进行评审）
1、 部门评审，测试部门全体成员参与的评审。
2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见
1、用例评审目的
测试用例评审流程规范主要为开展测试用例评审工作提供指引，规范测试用例评审管理工作。
2、测试用例评审流程内容
2.1 前提：测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写；
2.2 流程输入：A.测试用例； B.需求规格说明；
2.3 流程输出：A.问题记录清单； B.测试用例评审报告；
2.4 参与评审人员：项目经理、测试负责人、测试人员、需求分析人员、架构设计人员、开发人员；
2.5 评审方式：
1）召开评审会议。与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录；
2）通过邮件、及时通讯工具与相关人员沟通。
无论采用哪种方式，都应该在评审之前事先把需要评审的测试用例相关文档以邮件的形式发给参与评审的相关人员，同时在邮件中提醒参与评审的相关人员在评审前查阅一遍评审内容，并记录相关问题，以便在评审会议上提出，以节省沟通成本。
2.6 评审用例检查清单：
1）测试用例是否按照公司定义的模板进行编写的；
2）测试用例的本身的描述是否清晰，是否存在二义性；
3）测试用例内容是否正确，是否与需求目标相一致；
4）测试用例的期望结果是否确定、唯一的；
5）操作步骤应与描述是否相一致；
6）测试用例是否覆盖了所有的需求；
7）测试设计是否存在冗余性；
8）测试用例是否具有可执行性；
9）是否从用户层面来设计用户使用场景和业务流程的测试用例；
10）场景测试用例是否覆盖最复杂的业务流程；
11）用例设计是否包含了正面、反面的用例；
12）对于由系统自动生成的输出项是否注明了生成规则；
13）测试用例应包含对中间和后台数据的检查；
14）测试用例应有正确的名称和编号；
15）测试用例应标注有执行的优先级；
16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
17）每个测试用例步骤应<=15 Step；
18）自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；
19）非功能测试需求或不可测试需求是否在用例中列出并说明？
2.7 退出标准：
1）评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过；
2）评审结束后，测试负责人出测试用例评审报告给到相关人员；
3）评审结果经项目经理同意确认。
2.8 控制机制：
采用评审会议时，主持人应尽量把握会议进度，尽量按时有效的完成评审工作；
附件1：问题记录清单 附件2：测试用例评审报告
测试用例评审的意义何在：测试用例要符合产品需求，但是产品功能是开发写的，开发实现的逻辑需要评审沟通，以免有不清楚的逻辑点；可以提高测试用例的正确性、提高测试效率；提高测试用例的覆盖度，更好的发现BUG。
三、用例评审时间
对于敏捷开发项目，建议控制在半小时以内。
如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。
四、用例评审的形式
1、对照测试用例，从上而下，从左到右，逐条念。
这是目前很多公司的做法，如果你也这么做过，相信你并不一定喜欢这种方式，因为它费时，不分主次，参会人员的热情与注意力逐渐降低，整个用例评审效率低，作为主持人也讲的口干舌燥，事倍功半。
2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。
这种做法，有很多优点，评审刚开始的一段时间，大家注意力集中，参与激情高，这段时间讨论有难度有疑问的问题，效率高。最重要的事最先做。
另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的。
五、正式评审
正式评审过程中需要注意几个细节，如果你都做到了，那么可以说整个评审是成功的，有价值的。
1、评审要按用例的优先级，功能的复杂程度进行；
2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；
3、超过5分钟无法确定结果的问题留作会后讨论跟进。
六、评审结束后需要做些什么事？
不是说评审会结束了，就完事了，其实对于整个用例评审，这才做了一半。
评审结束后，第一时间整理测试用例，把修正的内容重新整理补全。
会上未确定的内容，会后继续跟进，直到确定结果。
没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点，补全了哪些？哪些模块功能有变动？哪些功能推迟到下一期做？等），
这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享，这点很重要。
