测试用例设计标准

编写目的 👀

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

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

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

为什么需要测试用例

● 测试用例是测试人员在测试过程中的重要参考依据；

● 测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不执行毫无意义的测试操作；

● 测试用例是一个知识传递的过程，能保持一致、稳定的测试质量；

● 从项目管理的角度来说，测试用例的通过率是检验代码质量最主要的指标之一；

● 测试用例也可以作为评估测试人员进度、工作量以及跟踪/管理测试的工作效率的主要因素，从而更加合理地做出测试安排或调整；

● 良好的测试用例不断地被重复使用，使得测试过程事半功倍；

TIP

在软件产品的开发过程中，开发人员不断的推出新的版本，测试人员需要对原有功能进行多次的回归测试，即使在一个版本中，也要进行 2 ～ 3 次的回归测试。这些回归测试，就要求 能重复使用测试用例。

● 如果没有测试用例，很可能到执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。

🔔 所以：

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

适用范围

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

测试用例编写流程

主要分为以下四步： 👀

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

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

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

4) 测试用例评审。

需求分析

需求文档

产品需求文档就是产品功能说明书，包含大量的功能细节，目的是提高沟通效率，避免研发过程出现误会。

注意：👀

● 需求背景与目标说明：让别人知道为什么要做，要做到什么程度，用户检验功能完成情况；

● 特性列表：所谓特性其实就是功能模块，把需要做的功能模块都罗列出来，主要用于明确需要做的功能有哪些，用图表体现更佳；

● 主要逻辑：每个特性之下的操作逻辑，简单特性可以文字说明，复杂特性建议用流程图表现；

● 特性功能点：补充每个功能点的相关细节描述，是开发，与测试工作的重要依据。包括：流程细节描述、正常逻辑表现，异常逻辑表现；文案内容，性能需求交互图（可无）；

● 特性需求，性能需求，数据上报：这一部分类似备注，说明了做这个功能要达到怎样的程度，需要再哪些地方进行数据埋点。

产品原型

产品原型是客户需求转变，是产品设计方案和底层逻辑的可视化表达，是设计测试用例的重要依据。

需求验收标准

验收标准 是一个正式的 需求清单，它确保所有的用户故事都能完成，所有的场景都能被考虑在内。简单来说，验收标准规定了满足用户故事的条件。简明扼要的标准可以帮助开发团队避免对客户的需求产生歧义，防止沟通不畅。

提取测试点

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

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

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

测试策略标准

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

测试用例设计方法文档

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

测试用例编写

模块划分

按照系统大的菜单进行划分，里边小的页面用关键字区分。

1） 产品、功能点同层级的结构按同纬度来划分。如应用、同等级产品、同等级功能点等；

2） 产品是指产品线下大的业务模块；

3） 功能点指业务模块下的子功能点，是最小功能点叶子节点；

4） 功能点目前无法再细分层级，后续会扩展功能点层次，在此之前，允许使用功能点名进行分层用例划分；

5） 产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称。

用例颗粒度划分规范

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

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

1）一个功能正常流程，编写一个测试用例；

2）一个功能中多个异常流程，应分开编写多个测试用例；

3）同一功能不同入口，可合并编写一个测试用例；

4）同一功能不同数据准备，应分开编写多个测试用例；

5）同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；

另一种用例划分维度：

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

用例编写要求规范

用例编写最基本的要求：

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

具体要求

用例名称

1.常用的结构“主、谓、宾”；
2.名称简洁易懂，不要包括具体操作步骤。

前置条件

1.执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
2.不可将其他用例作为前置条件，前置条件需要语言描述；
3.完整清楚，包括入口、帐号类型、账号权限、数据准备等；

具体要求如下

● 入口：覆盖所有功能入口，包含 URL 直接访问；
● 账号类型和权限：覆盖全部会员类型，注意业务权限控制，比如子账号权限，disable 会员权限；
● 数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条件，写明数据库表字段值；对于复杂的数据准备，写清具体 SQL。

操作步骤

1.操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；

2.操作和结果是一一对应的，但操作中不要包含结果的检查；

3.用例描述中不允许存在连词、介词，如：而且，和，还（这种情况可拆分为多个点）；

4.用例描述中不允许出现假设性词汇，如：假如，或许，可能，…的时候等；

5.用例描述中不允许出现二义性语句。

预期结果

1.原则上每个用例必需要有预期结果，结果不能为空；
2.结果中只能包含结果，不能有步骤；
3.一个结果有多个检查点时，确保检查点完整；

INFO

● 结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
● 结果涉及页面：需明确页面提示结果、数据变化；
● 结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
● 结果涉及消息：需明确关键查看内容；
● 结果对应不同输入数据有差别时需分别对应描述清晰。

测试用例数量标准

需求点数

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

核心功能

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

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

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

测试用例 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 个用例倒排计划，结合功能的优先级输出用例。