如何有效的进行用例设计和评审

作为一个合格的测试工程师，必须掌握测试的日常工作流程。

那么在一个产品周期里面，测试工程师是什么时候介入工作的呢体承担了哪些工作呢两问题，也是在日常面试中经常遇到的，这里我用一张思维导图进行简单的概括（如下图）

通过上面这个场景，实现在“同一条测试数据”的基础上，校验“不同字段，不同枚举值”。

原本需要8条测试用例，经过“场景用例设计”后，只需要3条测试用例即可校验。

2. 查询条件校验

方法：全局到细化

实现：

2.1全局校验查询条件字段是否齐全或正确

2.2具体查询条件功能校验

那么如何有效的进行用例评审呢/p>

1. 用例标注重点

需求疑问：在经过产品确认后，输出具体测试用例

设计交互：UI未提供交互，需求文档未描述的功能的实际交互细节

…

以上在设计测试用例过程中，【未在需求文档中明确描述&在设计测试用例过程中已同产品确认】，需要在用例评审中着重提醒开发，保持信息同步。

2. 逻辑概述+核心评审

业务流程较为繁长的测试用例条数较多，少则上百，多则上千，逐一讲解，不论是对开发或产品，甚至测试本身，都会出现前后文衔接不上。此时可以使用“全局流程+局部细”的方式来评审测试用例。

全局流程-逻辑概述

借助“Xmind”思维导图，进行简要的逻辑概述，阐述用例描述的基础流程。该阶段描述后，经产品和开发确认无疑问，则进行用例评审时，可略过该部分的基础测试用例。

局部细节-突出核心细节用例

除了基础业务流程外的，一些特殊场景细节的测试用例，可能影响业务流程或对公司造成损失，使用加粗/颜色标注，在用例评审时着重提醒开发。

特殊场景包括：

前后端数据同步交互、多人同时操作数据等，以下为逻辑校验的核心测试用例（仅供参考）

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览208551 人正在系统学习中