测试用例评审

转载

测试用例评审

首先要清楚内部评审的定义，是测试组内部的评审，仍是项目组内部的评审。评审的定义不一样，内容也不会相同。

一.评审分类：

 

测试组内部评审

测试组内部的评审，应该着重于：

1. 测试用例自己的描述是否清晰，是否存在二义性；
2. 是否考虑到测试用例的执行效率，每每测试用例中步骤不断重复执行，验证点却不一样，并且测试设计的冗余性，都形成了效率的低下；
3. 是否针对需求跟踪矩阵，覆盖了全部的软件需求；
4. 是否彻底遵照了软件需求的规定。这并不必定的，由于即便再严格的评审，也会出现错误，应具体状况具体对待。

项目组内部评审

若是是项目组内部的评审，也就须要评审委员会来作了，角度不一样，评审的标准也不一样。好比：

1. 收集客户需求的人员注重你的业务逻辑是否正确；
2. 分析软件需求规格的人注重你的用例是否跟规格要求一致；
3. 开发负责人会注重你的用例中对程序的要求是否合理。

二.测试用例评审步骤

测试用例的评审可以使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来讲也是一个快速提升用例设计能力的过程。

1.须要评审的缘由

测试用例是软件测试的准则，但它并非一经编制完成就成为准则。因为用例开发人员的设计经验和对需求理解的深度各不相同，因此用例的质量不免会有不一样程度的差别。

2.进行评审的时机

第一，是在用例的初步设计完成以后进行评审；
第二是在整个详细用例所有完成以后进行二次评审。若是项目时间比较紧张，尽量保证对用例设计进行评审，提早发现其中的不足之处。

3.参与评审人员

• 部门评审，测试部门全体成员参与的评审。
• 公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
• 客户评审，包括了客户方的开发人员和测试人员。这种状况在外包公司比较常见。

4.评审类容

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

我的认为，一个“健康”的测试用例至少要经过前5个标准。

五、评审的方式

1. 召开评审会议。与会者在设计人员讲解以后给出意见和建议，同时进行详细的评审记录。
2. 通用邮件与相关人员沟通
3. 通用IM工具直接与相关人员交流方式只是手段，获得其它人员对于用例的反馈信息才是目的。不管采用那种方式，都应该在沟通以前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

六、评审结束标准

在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到经过评审。