测试用例的评审能够应用例的结构更清晰，掩饰的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。
1、需要评审的原因
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计阅历和对需求了解的深度各不相同，所以用例的质量未免会有不同程度的区别。
2、进行评审的时机
一般会有两个时间点。第一，是在用例的初步设计完成之落先行评审;第二是在整个详细用例整个完成之落先行二次评审。如果项目时间对照紧张，尽能够保证对用例设计进行评审，提前发现其中的缺少之处。
3、加入评审人员
这里会分为多个级别进行评审。
1) 部门评审，测试部门整个成员加入的评审。
2) 公司评审，这里包含了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3) 客户评审，包含了客户方的开发人员和测试人员。这种状态在外包公司对照稀有。
4、评审内容
评审的内容有以下几个方面：
1) 用例设计的结构摆布是否清晰、合理，是否利于高效对需求进行掩饰。
2) 优先极摆布是否合理。
3) 是否掩饰测试需求上的所有功能点。
4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待效果是否清晰、正确;期待效果是否有明显的验证方式。
5) 是否已经删除了冗余的用例。
6) 是否包含短缺的负面测试用例。短缺的定义，如果在这里应用2&8法则，那就是4倍于正面用例的数量，究竟一个结实的软件，其中80%的代码都是在“保护”20%的功能完成。
7) 是否从用户层面来设计用户应用途景和应用流程的测试用例。
8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
个人认为，一个“虚弱”的测试用例至少要通过前5个标准。
5、评审的方式
1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2) 通用邮件与相关人员沟通
3) 通用IM工具直接与相关人员替换
方式只是手段，得到其它人员对于用例的反映信息才是宗旨。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以勤俭沟通成本。
6、评审结束标准
在评审静止中会收集到用例的反映信息，在此基础上进行用例更新，直到通过评审。
文章来源于领测软件测试网 https://www.ltesting.net/
