如何进行测试用例评审报告.docVIP

#g4*， ，t1、 如何进展测试用例评审 测试用例评审工作对测试人员能力的提高，测试效率的提高都有很好的作用，那么如果进展测试用例评审呢？它又哪些标准呢？通过的标准又是什么呢？ 关于“测试用例内部评审的标准〞的讨论的摘要： 首先要清楚内部评审的定义，是测试组内部的评审，还是工程组内部的评审。评审的定义不同，内容也不会一样。 如果是测试组内部的评审，应该着重于： 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、评审完毕标准 　　在评审活动中会收集到用例的反应信息，在此根底上进展用例更新，直到通过评审。 测试用例评审检查单： ?? ? 序号主要检查项 　　1?需求规格说明书?是否评审并建立了基线? 　　2 是否按照测试方案时间完成用例编写? 　　3 需求新增和变更是否进展了对应的调整? 　　4 用例是否按照公司定义的模板进展编写? 　　5 测试用例是否覆盖了?需求规格说明书?? 　　6 用例编号是否和需求进展对应? 　　7 非功能测试需求或不可测试需求是否在用例中列出并说明? 　　8 用例设计是否包含了正面、反面的用例? 　　9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果? 　　10 步骤/输入数据局部是否清晰，是否具备