测试用例设计标准

编写目的 👀

测试用例 是为项目需求而编制的一组包含测试输入、执行条件以及预期结果的文档，以便测试某个程序是否满足客户需求。

测试用例 是测试工作的指导，是软件测试质量稳定的根本保障，评估测试结果的基准。有一份用例来指导测试执行，可以在测试人员疲累的时候起到一个牵引作用。

编写用例的过程中，通过熟悉需求，对系统架构或业务有更深入理解。

为什么需要测试用例

🔔 所以：

测试用例 一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。

适用范围

参与软件产品测试的各测试工程师。

测试用例编写流程

主要分为以下四步： 👀

1) 需求分析 -> 提取测试点（结合测试策略制定）；

2) 提取测试点（结合测试策略制定） -> 测试用例编写（结合功能用例设计方法）；

3) 测试用例编写（结合功能用例设计方法） -> 测试用例评审；

4) 测试用例评审。

需求分析

提取测试点

测试人员根据需求的澄清、产品原型、需求验收标准等

提取测试点，梳理成思维导图形式，方便的编写用例。

第 1 步：依据需求梳理功能及功能点；
第 2 步：通过测试理论方法及经验，梳理测试点；
第 3 步：挖掘隐性需求，覆盖非功能测试层面。

测试策略标准

具体内容详见上文中的 《测试策略设计》 章节。

测试用例设计方法文档

具体内容详见下文中的 《测试用例设计》 章节。

测试用例编写

模块划分

用例颗粒度划分规范

用例颗粒度原则：测试用例是执行的最小实体。

用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：

另一种用例划分维度：

倒排计划测试计划，一天按照 50 个用例排计划，结合测试策略中价值排序，结合功能的优先级输出用例！

用例编写要求规范

用例编写最基本的要求：

1.具有清晰名称、前提条件、操作步骤、期望结果的；
2.可被他人理解的；
3.可被他人执行的。

具体要求

测试用例数量标准

需求点数

测试用例的数量不少于需求点数量。

核心功能

核心功能点用例数量必须大于非核心功能点用例数量。

等价类、边界值的数量参照

- 有效用例的数量>=最大有效等价类(含有效边界值)数量；
- 无效用例的数量>=所有无效等价类数量之和；
- 用例数量>=最大有效等价类(含有效边界值)数量+所有无效等价类数量之和。

测试用例 checklist 自检 👀

用例有效性

遵守如下法则：

1.需求点 100%被覆盖；

2.被测功能点或控件 100%被覆盖；

3.必须验证正确性操作、正常数据和可能导致出错的数据、操作；

4.有数据值域的必须考虑数据值域覆盖：边界值、等价类；

5.所有边界值都必须覆盖；

6.等价类必须包含有效和无效等价类；

7.等价类各子类不存在交错以避免冗余；

8.等价类的使用避开边界值；

9.所有等价类都必须覆盖(等价类数量过多导致超过测试成本的，优先考虑有效等价类，然后根据数据使用频率、几率高低分优先级，高级优先覆盖，同时考虑自动化测试)；

10.用例可以直接执行或易于准确执行；

11.用例中的数据或描述不存在二义性或多义性，不会因执行人不同而产生不同执行结果；

12.用例有明确的预期结果能够用于准确判断是否符合要求；

13.集成用例必须包含打开系统和退出系统的验证；

14.业务用例必须考虑不同模块数据和业务的一致性；

15.含数据库部分必须包括数据库的验证；

16.核心功能点必须被覆盖多次 -> 是否重复，原则：少的用例覆盖多的功能点；

17.用例设计必须提供设计思路、策略以便于评审和将来复用(含用例设计方法思路、数据分类等)。

用例可执行性

注意：🔔

1.操作步骤的描述，是否清晰、易懂；
2.操作步骤是否充分和必要，并具有可操作性；
3.测试用例的检查点是否明确、充分和可操作。

测试用例评审

按照现有的测试用例评审模版评审。[候补]

用例维护规范

测试用例编写完成后，应对测试用例进行持续的维护：

1.新项目需求变更，应及时对测试用例进行修改；

2.维护期项目，可根据项目组情况周期对用例进行维护；

3.所有发现的 bug 和故障，基于测试用例无法发现，需转化为测试用例；

4.平台产品发布后的三个工作日内，需将项目用例根据具体情况归入产品功能用例库下。

测试用例执行数量标准

执行标准

每个小时 执行 6 个测试用例，一天 按 8 小时算，**一天 **按照 50 个用例倒排计划，结合功能的优先级输出用例。