测试用例评审意义.pdfVIP

测试⽤例评审意义 ⾸先要清楚内部评审的定义，是测试组内部的评审，还是项⽬组内部的评审。评审的定义不同，内容也不会相同。 如果是测试组内部的评审，应该着重于： 1. 测试⽤例本⾝的描述是否清晰，是否存在⼆义性 2.是否考虑到测试⽤例的执⾏效率.往往测试⽤例中步骤不断重复执⾏，验证点却不同，⽽且测试设计的冗余性，都造成了效率的低下 3.是否针对需求跟踪矩阵，覆盖了所有的软件需求， 4.是否完全遵守了软件需求的规定。这并不⼀定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。 如果是项⽬组内部的评审，也就需要评审委员会来做了，⾓度不同，评审的标准也不同。⽐如： 收集客户需求的⼈员注重你的业务逻辑是否正确； 分析软件需求规格的⼈注重你的⽤例是否跟规格要求⼀致； 开发负责⼈会注重你的⽤例中对程序的要求是否合理。 要清楚地⼀点是：为了保证测试⽤例设计的质量，以及评审的收益，在提交项⽬组评审之前，必须通过测试部门或测试组内部的评审。 1.测试⽤例是否覆盖了所有需求. 2.测试⽤例内容是否正确,是否与需求⽬标⼀致. 3.测试⽤例内容是否完整,是否清楚包含输⼊和预期输出结果. 4.测试⽤例是否具有指导 性,是否能灵活指导测试⼈员通过⽤例发现更多缺陷,⽽不是限制他们的思维. 初期设计测试点时，应该进⾏测试组内部评审，当然⾸先是要保证需求全被覆盖，如果能在评审 时，让需求分析⼈员参与进来，效果会更好。 测试⽤例评审如何去做呢？ 测试⽤例的评审能够使⽤例的结构更清晰，覆盖的⽤户场景更全⾯；对于测试⼯程师来说也是⼀个快速提⾼⽤例设计能⼒的过程。 1、需要评审的原因 测试⽤例是软件测试的准则，但它并不是⼀经编制完成就成为准则。由于⽤例开发⼈员的设计经验和对需求理解的深度各不相同，所以⽤例的质量难免会有不同程度的 差异。 2、进⾏评审的时机 ⼀般会有两个时间点。第⼀，是在⽤例的初步设计完成之后进⾏评审；第⼆是在整个详细⽤例全部完成之后进⾏⼆次评审。如果项⽬时间⽐较紧张，尽可能保证对⽤例 设计进⾏评审，提前发现其中的不⾜之处。 3、参与评审⼈员 这⾥会分为多个级别进⾏评审。 1) 部门评审，测试部门全体成员参与的评审。 2) 公司评审，这⾥包括了项⽬经理、需求分析⼈员、架构设计⼈员、开发⼈员和测试⼈员。 3) 客户评审，包括了客户⽅的开发⼈员和测试⼈员。这种情况在外包公司⽐较常见。 4、评审内容 评审的内容有以下⼏个⽅⾯： 1) ⽤例设计的结构安排是否清晰、合理，是否利于⾼效对需求进⾏覆盖。 2) 优先极安排是否合理。 3) 是否覆盖测试需求上的所有功能点。 4) ⽤例是否具有很好可执⾏性。例如⽤例的前提条件、执⾏步骤、输⼊数据和期待结果是否清晰、正确；期待结果是否有明显的验证⽅法。 5) 是否已经删除了冗余的⽤例。 6) 是否包含充分的负⾯测试⽤例。充分的定义，如果在这⾥使⽤28法则，那就是4倍于正⾯⽤例的数量，毕竟⼀个健壮的软件，其中80%的代码都是在“保护”20%的功 能实现。 7) 是否从⽤户层⾯来设计⽤户使⽤场景和使⽤流程的测试⽤例。 8) 是否简洁，复⽤性强。例如，可将重复度⾼的步骤或过程抽取出来定义为⼀些可复⽤标准步骤。 个⼈认为，⼀个“健康”的测试⽤例⾄少要通过前5个标准。 5、评审的⽅式 1) 召开评审会议。与会者在设计⼈员讲解之后给出意见和建议，同时进⾏详细的评审记录。 2) 通⽤邮件与相关⼈员沟通 3) 通⽤IM⼯具直接与相关⼈员交流 ⽅式只是⼿段，得到其它⼈员对于⽤例的反馈信息才是⽬的。 ⽆论采⽤那种⽅式，都应该在沟通之前把⽤例设计的相关⽂档发送给对⽅进⾏前期的学习和了解 ，以节省沟通成本。 6、评审结束标准 在评审活动中会收集到⽤例的反馈信息，在此基础上进⾏⽤例更新，直到通过评审。 个⼈愚见，仅参考 ^o^ 测试⽤例评审检查单： 序号主要检查项 1 《需求规格说明书》是否评审并建⽴了基线? 2 是否按照测试计划时间完成⽤例编写? 3 需求新增和变更是否进⾏了对应的调整? 4 ⽤例是否按照公司定义的模板进⾏编写? 5 测试⽤例是否覆盖了《需求规格说明书》? 6 ⽤例编号是否和需求进⾏对应? 7 ⾮功能测试需求或不可测试需求是否在⽤例中列出并说明? 8 ⽤例设计是否包含了正⾯、反⾯的⽤例? 9 每个测试⽤例是否清楚的填写了测试特性、步骤、预期结果? 10 步骤/输⼊数据部分是否清晰，是否具备可操作性?