①评审过程中收集相关人员的反馈信息，并在此基础上进行测试用例更新，直到评审通过；②评审结束后，测试负责人出测试用例评审报告给到相关人员；③评审结果经项目经理同意确认。

1）测试用例是否按照公司定义的模板进行编写的； 
2）测试用例的本身的描述是否清晰，是否存在二义性；
3）测试用例内容是否正确，是否与需求目标相一致；
4）测试用例的期望结果是否确定、唯一的；
5）操作步骤应与描述是否相一致；
6）测试用例是否覆盖了所有的需求；
7）测试设计是否存在冗余性；
8）测试用例是否具有可执行性；
9）是否从用户层面来设计用户使用场景和业务流程的测试用例；
10）场景测试用例是否覆盖最复杂的业务流程； 
11）用例设计是否包含了正面、反面的用例； 
12）对于由系统自动生成的输出项是否注明了生成规则；
13）测试用例应包含对中间和后台数据的检查；
14）测试用例应有正确的名称和编号；
15）测试用例应标注有执行的优先级；
16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
17）每个测试用例步骤应<=15 Step；
18）自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；
19）非功能测试需求或不可测试需求是否在用例中列出并说明。 

按照规范、客户需求、文档，可行性等

一、需要评审的原因

  测试用例是软件测试的准则，但它并不是编制完成后就直接成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。　　　　

二、用例评审内容

  1.用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

  2.优先极安排是否合理。

  3.是否覆盖测试需求上的所有功能点。

  4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

  5. 是否已经删除了冗余的用例。

  6.是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。

  7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。

  8. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

三、用例评审过程

  1.提前发出用例初稿，并确定参与用例评审人员，目前我们是只包含测试工程师和测试经理参与；

  2.先做简单的业务流程介绍，这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，其他测测试工程师可能都不知道测试的思路，或者半途加入的新的测试，对需求和业务都不够熟悉，如何让评审快速进入状态，先做简单的需求业务流程介绍，说明白打算如何去做评审。

  3.按模块进行，有些模块，业务性不是特别强的，可以简单说下有哪些模块，每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的。

  4.按业务流程进行，业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来；

  5.按测试数据进行，涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。

四、用例评审需要避免

  1.测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清。

  2.杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点；

  目前我们是测试组内部的评审，我们着重于：

  （1）测试用例本身的描述是否清晰，是否存在二义性;

  （2）是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

  （3）是否针对需求变更进行跟着，覆盖了所有的软件需求；　　

  （4）是否尽可能多的覆盖了异常流程和异常测试点。

①评审过程中收集相关人员的反馈信息，并在此基础上进行测试用例更新，直到评审通过；

②评审结束后，测试负责人出测试用例评审报告给到相关人员；

③评审结果经项目经理同意确认。

• 目的

• 范围

• 评审分类

• 评审内容

• 评审方式

• 评审结束标准

如下：

1.

用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。  

2.

优先极安排是否合理。  

3.

是否覆盖测试需求上的所有功能点。  

4.

用例是否具有很好可执行性。