模板
教程
环境
性能
功能
管理
软件测试用例评审说明
发表于：2023-07-07来源：csdn作者：daisyr07点击数：
标签：
软件测试用例评审是一个重要的环节，它是质量保证的关键手段，可以有效地帮助确保软件符合预期的功能要求和质量标准。 软件测试用例评审的工作流程是，首先准备工作，收集相关
软件测试用例评审是一个重要的环节，它是质量保证的关键手段，可以有效地帮助确保软件符合预期的功能要求和质量标准。 软件测试用例评审的工作流程是，首先准备工作，收集相关的软件测试用例文档，确定用例评审活动的主要参与者；然后进行用例评审，确定测试用例的有效性、识别测试用例的缺陷、评估测试用例的可行性以及提出改进建议；接着编写评审报告，整理评审结果并发布评审报告；最后完成后续工作，包括实施改进建议、更新用例文档以及进行测试等。
一 .用例评审目的
一 .用例评审目的
为用例评审提供一个参考标准，保证评审的覆盖率和有效性
为了避免三方需求理解不一致
保证测试人员的质量标准与项目标准一致
为了减少测试人员执行阶段无效工作
保证相关人员对即将要上线的需求有了解
二. 用例评审作用
1.对于产品经理
检查测试人员是否准确理解需求，确保每个需求点都覆盖到。
通过评审正常和异常的测试用例，来反思当时设计需求时未考虑的情况，也是自我回溯的一个过程。
2.对于开发人员
检查自己的程序代码是否还有很多情况未考虑完善，对自己的代码也是一个自我回溯检查的过程，间接实现了测试左移。
对于用例中无法实现的逻辑及时沟通，三方达成高度一致。
3.对于测试人员
与各方人员沟通，完善测试用例
三.用例评审参与人员
用例评审一定是要求产品（制定该需求的产品经理）、开发（实现该产品的前后端开发人员）、测试（负责该需求用例编写和执行的测试人员）都参与。
会议由测试人员主导，相应需求的测试同学依次上去讲解自己的测试用例。
测试组内部的评审：测试部门成员参与
项目组内部的评审：项目经理、产品人员、开发人员和测试人员参与
四. 用例评审内容
1.一般用例评审内容
用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
优先极安排是否合理。
是否覆盖测试需求上的所有功能点。
用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
是否已经删除了冗余的用例。
是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
是否从用户层面来设计用户使用场景和使用流程的测试用例。
是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
2.测试组内部评审侧重
测试用例本身的描述是否清晰，是否存在二义性；
是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
是否针对需求变更进行跟着，覆盖了所有的软件需求；
是否尽可能多的覆盖了异常流程和异常测试点。
3.测试用例评审检查项
测试用例是否按照公司定义的模板进行编写的；
测试用例的本身的描述是否清晰，是否存在二义性；
测试用例内容是否正确，是否与需求目标相一致；
测试用例的期望结果是否确定、唯一的；
操作步骤应与描述是否相一致；
测试用例是否覆盖了所有的需求；
测试设计是否存在冗余性；
测试用例是否具有可执行性；
是否从用户层面来设计用户使用场景和业务流程的测试用例；
场景测试用例是否覆盖最复杂的业务流程；
用例设计是否包含了正面、反面的用例；
对于由系统自动生成的输出项是否注明了生成规则；
测试用例应包含对中间和后台数据的检查；
测试用例应有正确的名称和编号；
测试用例应标注有执行的优先级；
测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
每个测试用例步骤应<=15 Step；
自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；
非功能测试需求或不可测试需求是否在用例中列出并说明
五.用例评审方式
线上会议
线下会议
通用OA与相关人员沟通
六.用例评审时间
测试用例完成后
需求文档提交后，开发提测前
会议时间最好控制在1小时之内，如果内容较多，可多次评审
七.用例评审流程
1.会前准备
测试用例编写完成
提前通知参会人员，约定好评审时间并预约好会议室
提前将测试用例发送给参会人员查阅
会议5分钟前到达会议室，将测试用例，需求文档等打开
用例较多时，提前做好标注，优先讲解优先级高的用例，并尽量将前后端用例区分，方便侧重评审
将自己的疑惑整理在一起，方便询问
2.会中流程
2.1方式1：对照测试用例，从上而下，从左到右，逐条念。
普遍的流程都是这样的。
优点：逐个讲解，全面仔细
缺点：费时，不分主次，降低参会人员的注意力
2.2方式2：先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
优先讲解优先级高的用例，其次疑惑多的用例，再者功能简单，优先级低的功能点。
优点：有侧重点，效率高
缺点：讲解不全面，可能存在忽略点
2.3会议注意
对于评审过程中，超过5分钟无法确定结果的问题，可以记录下来，作为会后讨论跟进的重点。
评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点。
对于有歧义的问题，需要与产品和开发确认清楚。
评审过程中，参会人员可能会有视觉和听觉疲劳，主讲人要抓住重点和重要人员。
对于评审过程中的问题，及时做好标记。
用例评审只针对用例，不针对个人能力。
3.会后总结
3.1用例评审会议后，需要对评审中的问题进行跟进和完善。
需要产品经理补充和修改的点需要让其在需求文档和原型图上进行记录
对遗漏的测试点进行补充，对有误的测试点进行修正，并对用例进行管理
3.2如有要求，完成用例评审文档
3.3对个人会议行为进行总结
七.用例评审结束标准
评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过。
评审结束后，测试负责人出测试用例评审报告给到相关人员。
评审结果经项目经理同意确认
原文转自：https://blog.csdn.net/Daisy74RJ/article/details/131562723
