测试用例规范_测试用例编写规范

测试用例规范

一、概述

统一测试用例编写规范，为测试用例设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好的执行测试，提高测试效率，最终提高整个产品的质量。

二、测试用例设计规范

设计测试用例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

1. 测试需求分析

通常根据产品需求说明书或系统模块提取独立的功能点，划分功能模块，确定测试范围。

2. 业务流程分析

部分功能在需求说明书中有包含，但部分隐性需求绝大多数情况下是没有的。所以除了需要了解显性功能需求外，还需要熟悉业务流程，甚至是开发设计方案，这样才能设计出覆盖率高的测试用例。

3. 用例框架拆分

根据测试需求、业务流程分析，开始进行用例框架的拆分。通常用例框架的层级如下：

4. 测试用例设计

根据用例框架进行用例设计。

用例设计思路：
1. 正常功能验证：正常操作功能是否实现
2. 单个功能项验证：正常+异常
3. 功能之间交互验证：模块之间的数据传递
4. 隐性需求：熟悉业务

用例维度：
1. 功能性：功能有没有，好不好用
2. 性能效率：对应系统的资源耗费程度及响应时间
3. 易用性：容易理解、学习、使用
4. 兼容性：能够兼容不同的软硬件平台
5. 可靠性：不易出问题，万一出问题容易恢复
6. 安全性：对于用户的安全保障（外在的人生安全、内在的信息安全等）

三、测试用例描述规范

测试用例包含功能模块、用例名称、用例编号、用例等级、前置条件、操作步骤、预期结果等元素。下面对主要元素进行一些规范说明。

1. 功能模块：功能模块体现的是测试需求的结构，或系统功能模块结构。格式为：XXX_XXX_XXX。_后为上一层级的子模块，如：
   

2. 用例名称：描述每一条用例的测试点

   用例名称规则：

   • 应简洁清晰，能清楚表达测试用例的测试点
   • 用例名称是唯一的且能高度概括表达测试点

   如下图，从用例名称可看出该用例的测试点为列表搜索框的输入验证。
   

3. 用例编号：定义测试用例的编号，用例编号根据测试用例架构编写，且具有唯一性，便于查找和维护测试用例
   编号规则：通常以{模块名英文}_{序号}来命名。例如：
   

4. 用例等级：定义测试用例的优先级别，分为“BVT”“高”“中”“低”。详见第四章。

5. 前置条件：执行该用例的前提条件，清晰的前置条件有助于提升测试用例的执行效率与执行质量。

   前置条件规则：

   • 前置条件一般为环境信息，预置操作等，前置条件是可选项，可以有0个或多个前置条件。
   • 每一个前置条件、操作步骤、预期结果前面都需加上序号。即使只有一条，也要写上编号。
   • 即使【功能模块】、【用例名称】、【前置条件】有一样的内容，也不合并单元格，一条用例一行

   

6. 操作步骤：描述测试执行过程的步骤。通常该用例执行失败，关联提交bug后，开发也会以该步骤进行bug复现。所以操作步骤的描述很重要。

   操作步骤规则：

   • 操作步骤的描述应简单、清晰，对于复杂的测试用例，应分为几个步骤。
   • 连惯性的操作应放一起作为一条用例的操作步骤，非连惯性的操作应分开。
   • 一般测试操作步骤不超过5步，步骤太多，用例可读性降低，执行也容易出错。

7. 预期结果：描述测试执行的预期表现。若实际执行的结果与预期不符，则说明程序有问题。

   预期结果规则：

   • 一个操作步骤对应一个预期结果
   • 预期结果根据软件需求以及最终实现效果输出
   • 预期结果描述要清晰、明确，没有含糊的概念和一般性的描述，如：大概、可能、应该等。
   • 预期结果应详细具体，尽量做到不同的人看这个结果理解一致
   • 相同测试预期结果可以不同重复写，如不同界面插入U盘,提示语验证；建立通话，通话UI描述。
   • 预期结果中提示语、标题、softkey、翻译等大小写、是否有空格、特殊字符符号等都要描述准确

四、测试用例等级规范

1. 用例等级定义

2. 用例等级划分方法

1. 步骤一：

根据以下三个原则将测试用例划分为三个等级，分别为“高”、“中”、“低”

• 把所有功能性验证的测试标注为高级别用例。
• 把所有错误和边界值或确认测试标注为中级别用例。
• 把所有非功能性的测试（例如性能和易用性）标注为低级别用例。

2. 步骤二：

在步骤一的基础上进行用例的等级提升和降级

• 把功能性验证测试分为两组：重要和不是十分重要。
  将“不是十分重要”的功能性验证测试降级为中优先级别
• 把错误和边界测试分成两组：重要和不是十分重要
  将“重要”的错误和边界测试升级为高优先级别
• 把非功能性测试分成两组：重要和不是十分重要
  把“重要”的非功能性测试升级为中优先级别

针对每组高、中和低级别的测试用例，重复划分和升级/降级流程直到达到在不同优先级别之间移动的测试用例的数量到最小。

判定重要程度可以参考以下几点：

• 当该功能失效后，对客户或公司的影响程度，影响越大说明越重要。可以分为以下几个等级：
  • 功能的失败将丢失一个客户
  • 功能的失败将给公司造成重大的影响
  • 功能的失败将引起一个潜在的延期给客户
  • 功能的失败对公司将有较小的影响
  • 功能的失败没有任何影响
• 该功能（操作）的使用频率。
• 用户对该功能（操作）的使用习惯。

3. 步骤三：

提取BVT测试用例（Build Verification Tests）

为了确保研发提交的版本是可以测试的并准备给项目小组成员开始系统测试，需要检查系统的基本功能，确保系统的各功能可正常运行。

• 将高级别的测试用例分成两组：严重和重要的。
  将“严重”的高级别的测试用例升级为BVT级别。

Note：测试需求等级划分不需要进行BVT的提取。

4. 步骤四：
检查优先级别的百分比分布情况：BVT为10-15%，高为20-30%,中为40-60%，低为10-15%。当比例偏差较大时，可以重复步骤二，进行用例等级的提升或降级。