用例评审
用例评审
1. 用例评审
1. 用例评审目的
为用例评审提供一个参考标准，保证评审的覆盖率和有效性
- 为了避免三方需求理解不一致
- 保证测试人员的质量标准与项目标准一致
- 为了减少测试人员执行阶段无效工作
- 保证相关人员对即将要上线的需求有了解
2. 用例评审作用
- 对于产品经理
- 检查测试人员是否准确理解需求，确保每个需求点都覆盖到
- 通过评审正常和异常的测试用例，来反思当时设计需求时未考虑的情况，也是自我回溯的一个过程
- 对于开发人员
- 检查自己的程序代码是否还有很多情况未考虑完善，对自己的代码也是一个自我回溯检查的过程，间接实现了测试左移
- 对于用例中无法实现的逻辑及时沟通，三方达成高度一致
- 对于测试人员
- 与各方人员沟通，完善测试用例
3. 用例评审参与人员
用例评审一定是要求产品（制定该需求的产品经理）、开发（实现该产品的前后端开发人员）、测试（负责该需求用例编写和执行的测试人员）都参与
会议由测试人员主导，相应需求的测试同学依次上去讲解自己的测试用例
- 测试组内部的评审：测试部门成员参与
- 项目组内部的评审：项目经理、产品人员、开发人员和测试人员参与
4. 用例评审内容
- 一般用例评审内容
- 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖
- 优先极安排是否合理
- 是否覆盖测试需求上的所有功能点
- 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法
- 是否已经删除了冗余的用例
- 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现
- 是否从用户层面来设计用户使用场景和使用流程的测试用例
- 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤
- 测试组内部评审侧重
- 测试用例本身的描述是否清晰，是否存在二义性
- 是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
- 是否针对需求变更进行跟着，覆盖了所有的软件需求
- 是否尽可能多的覆盖了异常流程和异常测试点
- 测试用例评审检查项
- 测试用例是否按照公司定义的模板进行编写的
- 测试用例的本身的描述是否清晰，是否存在二义性
- 测试用例内容是否正确，是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一的；操作步骤应与描述是否相一致
- 测试用例是否覆盖了所有的需求
- 测试设计是否存在冗余性
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
- 对于由系统自动生成的输出项是否注明了生成规则
- 测试用例应包含对中间和后台数据的检查
- 测试用例应有正确的名称和编号
- 测试用例应标注有执行的优先级
- 测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等
- 每个测试用例步骤应 <= 15 Step
- 自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）
- 非功能测试需求或不可测试需求是否在用例中列出并说明
5. 用例评审方式
- 线上会议
- 线下会议
- 通用OA与相关人员沟通
6. 用例评审时间
- 测试用例完成后
- 需求文档提交后，开发提测前
- 会议时间最好控制在1小时之内，如果内容较多，可多次评审
7. 用例评审流程
会前准备
- 测试用例编写完成
- 提前通知参会人员，约定好评审时间并预约好会议室
- 提前将测试用例发送给参会人员查阅
- 会议5分钟前到达会议室，将测试用例，需求文档等打开
- 用例较多时，提前做好标注，优先讲解优先级高的用例，并尽量将前后端用例区分，方便侧重评审
- 将自己的疑惑整理在一起，方便询问
会中流程
- 方式1：对照测试用例，从上而下，从左到右，逐条念。普遍的流程都是这样的。
- 优点：逐个讲解，全面仔细
- 缺点：费时，不分主次，降低参会人员的注意力
- 方式2：先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。 优先讲解优先级高的用例，其次疑惑多的用例，再者功能简单，优先级低的功能点
- 优点：有侧重点，效率高
- 缺点：讲解不全面，可能存在忽略点
- 方式1：对照测试用例，从上而下，从左到右，逐条念。普遍的流程都是这样的。
会议注意
- 对于评审过程中，超过5分钟无法确定结果的问题，可以记录下来，作为会后讨论跟进的重点
- 评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点
- 对于有歧义的问题，需要与产品和开发确认清楚
- 评审过程中，参会人员可能会有视觉和听觉疲劳，主讲人要抓住重点和重要人员
- 对于评审过程中的问题，及时做好标记
- 用例评审只针对用例，不针对个人能力
会后总结
- 用例评审会议后，需要对评审中的问题进行跟进和完善
- 需要产品经理补充和修改的点需要让其在需求文档和原型图上进行记录
- 对遗漏的测试点进行补充，对有误的测试点进行修正，并对用例进行管理
如有要求，完成用例评审文档
对个人会议行为进行总结
8. 用例评审结束标准
- 评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过
- 评审结束后，测试负责人出测试用例评审报告给到相关人员
- 评审结果经项目经理同意确认
说明：具体根据公司要求，部分公司并不要求完成用例评审报告，那么可以进行自我总结复盘
2. 用例评审的标准规范
用例评审是软件测试流程工作中非常重要的一个环节
- 什么是用例评审？
- 如何进行用例评审？
- 用例评审的标准规范是什么？
- 用例评审考核标准是什么？
今天我们主要围绕以上四个问题来展开讲解。
1. 什么是用例评审
用例评审指测试人员根据产品需求完成用例设计后，召集产品、开发、测试一起开会过审测试人员编写的用例，测试用例设计者负责宣讲重点部分用例业务逻辑内容的过程。
因测试人员个人能力、项目经验、思考问题的角度不同，编写用例难免会存在遗漏的情况、理解有误，考虑不周等情况，给产品带来不必要的质量风险。
为了解决上述问题，从而推出用例评审环节，解决用例设计者带来的质量风险等一切不可控问题，为软件产品质量保驾护航。
2. 如何进行用例评审？
测试项目设计者组织用例评审会议，发布用例评审通知，具体细则内容如下：
实施用例评审工作前，测试人员需优先组织测试组成员开展内部用例评审工作，提前发现问题及时修改，为对外评审做好准备。
预约用例评审时间与产品、开发、测试、项目经理及项目组相关干系人提前确认沟通好。
内审通过后，测试组项目负责人提前发送测试评审邮件。
评审邮件内容包括以下内容：
- 用例评审参与人：产品、开发、测试、项目经理等相关人员；用例评审时间：xxxx年xx月xx日
- 项目名称：XX产品
- 评审内容：
- 测试组用例设计负责人根据需要功能点宣读用例，内容包括：
- XX产品XX版本号、系统模块、功能点简要说明，重点评审业务模块复杂、需求优先级别高的模块，优先级较低的用例可不宣讲。
评审注意事项：需提前讲解用例评审规则，讲述用例评审目的、提前发送评审邀请邮件。
测试人员评审记录问题问题，评审通过后对用例进行更新维护。
测试人员评审完某一模块内容需要与开发、产品、测试确认是否有问题，才能进入后续内容的评审。
3. 用例评审的规范标准是什么？
正所谓：“无规矩不成方圆”。
用例评审同样存在自己的标准规范。
比如说，你需要遵循那些评审原则与事项，细节内容如下表所示：
| 编号 | 评审内容 | 备注(是否) |
|---|---|---|
| 1 | 测试用例是否按照公司定义的模板进行编写 | |
| 2 | 测试用例的本身的描述是否清晰，是否存在二义性 | |
| 3 | 测试用例内容是否正确，是否与需求目标相一致 | |
| 4 | 测试用例的期望结果是否确定、唯一的 | |
| 5 | 操作步骤应与描述是否相一致 | |
| 6 | 测试用例是否覆盖了所有的需求 | |
| 7 | 测试设计是否存在冗余性 | |
| 8 | 测试用是否具有可执行性 | |
| 9 | 是否从用户层面来设计用户使用场景和业务流程的测试用例 | |
| 10 | 场景测试用例是否覆盖复杂的业务流程 |
4. 用例评审考核标准是什么？
评审的目的是拿到用例评审结果，再对评审过程内容进一步优化更新。
评审结果只有两种，评审通过，评审未通过。
针对问题较多用例需要开展二次评审，用例评审考核标准主要为测试人员的工作考核进行计分，具体结果考核细则项如下图：
根据当前用例评审内容的全面性、覆盖面、完整性、是否存在遗漏，是否缺少功能点等相面来综合考量给予计分。
总之，用例评审是测试流程中必备的环节，用例设计更是整个产品质量的灵魂，想要更好的保障软件产品质量，需要多站在用户场景思考问题，对用户操作、业务逻辑过程进行深度思考，才能从根本上挖掘质量问题，让产品满足需求，为客户的产品质量保驾护航。