如何进行测试用例评审

1、WOR格式如何进行测试用例评审测试用例评审工作对测试人员能力的提高，测试效率的提高都有很好的作用，那么如果进行测试用例评审呢？它又哪些标准呢？通过的标准又是什么呢？关于“测试用例内部评审的标准”的讨论的摘要：首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。如果是测试组内部的评审，应该着重于：1. 测试用例本身的描述是否清晰，是否存在二义性2. 是否考虑到测试用例的执行效率 .往往测试用例中步骤不断重复执行，验证点却不同， 而且测试设计的冗余性，都造成了效率的低下3. 是否针对需求跟踪矩阵，覆盖了所有的软件需求，4. 是否完全遵守了软件需求的规

2、定。这并不一定的，因为即使再严格的评审， 也会出现错误，应具体情况具体对待。如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如：收集客户需求的人员注重你的业务逻辑是否正确；分析软件需求规格的人注重你的用例是否跟规格要求一致；开发负 责人会注重你的用例中对程序的要求是否合理。以及评审的收益，在提交项目组评审之要清楚地一点是：为了保证测试用例设计的质量，前，必须通过测试部门或测试组内部的评审。1. 测试用例是否覆盖了所有需求是否与需求目标一致是否清楚包含输入和预期输出结果2. 测试用例内容是否正确3. 测试用例内容是否完整4.测试用例是否具有指导性是否能灵活指导测试

3、人员通过用例发现更多缺陷而不是限专业资料整理制他们的思维初期设计测试点时，应该进行测试组内部评审， 评审时，让需求分析人员参与进来，效果会更好。当然首先是要保证需求全被覆盖，如果能在测试用例评审如何去做呢?覆盖的用户场景更全面；对于测试工程师来说也测试用例的评审能够使用例的结构更清晰， 是一个快速提高用例设计能力的过程。1、需要评审的原因测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。2、进行评审的时机一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审；第二是在整个详细用例全部完成

4、之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。3、参与评审人员这里会分为多个级别进行评审。1）部门评审，测试部门全体成员参与的评审。2）公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和 测试人员。3）客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常 见。4、评审内容评审的内容有以下几个方面：1）用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。2）优先极安排是否合理。3）是否覆盖测试需求上的所有功能点。4）用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期 待结果是否清晰、正确

5、；期待结果是否有明显的验证方法。5）是否已经删除了冗余的用例。6）是否包含充分的负面测试用例。充分的定义，如果在这里使用 2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。7）是否从用户层面来设计用户使用场景和使用流程的测试用例。8）是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些 可复用标准步骤。个人认为，一个“健康”的测试用例至少要通过前5个标准。5、评审的方式1）召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的 评审记录。2）通用邮件与相关人员沟通3）通用IM工具直接与相关人员交流方

6、式只是手段，得到其它人员对于用例的反馈信息才是目的。无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的 学习和了解，以节省沟通成本。6、评审结束标准在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审测试用例评审检查单：序号主要检查项1需求规格说明书是否评审并建立了基线？2是否按照测试计划时间完成用例编写？3需求新增和变更是否进行了对应的调整？4用例是否按照公司定义的模板进行编写？5测试用例是否覆盖了需求规格说明书？6用例编号是否和需求进行对应？7非功能测试需求或不可测试需求是否在用例中列出并说明？8用例设计是否包含了正面、反面的用例？9每个测试用例是否清楚的填写了测试特性、步骤、预期结果？10步骤/输入数据部分是否清晰，是否具备可操作性？11测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述12测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计 方法？是否针对需求不同部分设计使用不同设计方法？13重点需求用例设计至少要有三种设计方法？14每个测试用例是否都阐述预期结果和评估该结果的方