目的

1、目的
为用例评审提供一个参考标准，测试用例评审的目的在于查漏补缺，保证评审的覆盖率和有效性。

范围

2、范围
本文档阅读对象为项目经理、测试工程师及项目组所有成员，适合于任何产品和项目。

评审分类

3、评审分类
?测试组内部的评审：测试部门成员参与
?项目组内部的评审：项目经理、产品人员、开发人员和测试人员参与

评审内容

4、评审内容
?用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
?优先级安排是否合理。
?是否覆盖测试需求上的所有功能点
?用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法
?是否已经删除了冗余的用例
?是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现
?是否从用户层面来设计用户使用场景和使用流程的测试用例
?是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

评审方式

5、评审方式
?召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录

评审结束标准

6、评审结束标准
1）评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过；
附：测试用例评审检查项：
1）测试用例是否按照公司定义的模板进行编写的；
2）测试用例的本身的描述是否清晰，是否存在二义性；
3）测试用例内容是否正确，是否与需求目标相一致；
4）测试用例的期望结果是否确定、唯一的；
5）操作步骤应与描述是否相一致；
6）测试用例是否覆盖了所有的需求；
7）测试设计是否存在冗余性；
8）测试用例是否具有可执行性；
9）是否从用户层面来设计用户使用场景和业务流程的测试用例；
10）场景测试用例是否覆盖最复杂的业务流程；
11）用例设计是否包含了正面、反面的用例；
12）对于由系统自动生成的输出项是否注明了生成规则；
13）测试用例应包含对中间和后台数据的检查；
14）测试用例应有正确的名称和编号；
15）测试用例应标注有执行的优先级；
16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户权限等；
17）每个测试用例步骤应<=15 Step。

今日主要在编写测试用例，我主要负责悟空crm系统的办公模块，根据老师的讲解测试用例的编写方法基本将办公模块的测试用例编写完成.。上午进行了用例的同行评审，发现了自己的用例的一些问题，并进行了修改，下午完成了商业智能模块的部分功能的用例编写；
不足：在编写测试用例时容易出现遗漏的细节，编写测试用例还有待加强。