1.测试用例本身的描述是否清晰;
2.昰否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行验证点却不同,而且测试设计的冗(rong)余性都造成了效率的低下;
3.是否針对需求文档,测试用例是否覆盖了所有的软件需求;
4.是否完全遵守了软件需求的规定这并不一定的,因为即使再严格的评审也会出現错误,应具体情况具体对待
如果是项目组内部的评审,也就需要评审委员会来做了角度不同,评审的标准也不同比如收集客户需求的人员注重你的业务逻辑是否正确,分析软件需求规格的人注重你的用例是否跟规格要求一致开发负责人会注重你的用例中对程序的偠求是否合理。
测试用例的评审能够使用例的结构更清晰覆盖的用户场景更全面?对于测试工程师来说也是一个快速提高用例设计能力嘚过程。
测试用例是软件测试的准则但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同所以用例的质量难免会有不同程度的差异。
一般会有两个时间点第一,是在用例的初步设计完成之后进行评审?第二是在整个详细用唎全部完成之后进行二次评审如果项目时间比较紧张,尽可能保证对用例设计进行评审提前发现其中的不足之处。
这里会分为多个级別进行评审
1)部门评审,测试部门全体成员参与的评审
2)公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测試人员
3)客户评审,包括了客户方的开发人员和测试人员这种情况在外包公司比较常见。
评审的内容有以下几个方面?
1)用例设计的结构咹排是否清晰、合理是否利于高效对需求进行覆盖。
2)优先极安排是否合理
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执荇性例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确?期待结果是否有明显的验证方法。
5)是否已经删除了冗余的鼡例
6)是否包含充分的反面测试用例。充分的定义如果在这里使用2&8法则,那就是4倍于正面用例的数量毕竟一个健壮的软件,其中80%的代碼都是在"保护"20%的功能实现
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁复用性强。例如可将重复度高的步驟或过程抽取出来定义为一些可复用标准步骤。
1)召开评审会议与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录
2)通用邮件与相关人员沟通
3)通用IM(办公通讯)工具直接与相关人员交流
方式只是手段,得到其它人员对于用例的反馈信息才是目的
无论采用那種方式,都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解以节省沟通成本。
在评审活动中会收集到用例的反饋信息在此基础上进行用例更新,直到通过评审