测试用例规范

测试用例规范

一、概述

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

二、测试用例设计规范

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

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. 用例等级定义

级别	定义
BVT	1.该类用例涉及系统基本功能，用例数量应受到控制，占10-15%的比例。 2.划分依据：该用例执行的失败会导致多处重要功能无法运行，可以认为是发生概率较高而且经常使用的一些功能用例。 3.该级别的测试用例在每一轮版本测试中都必须执行。
高	1.该类用例涉及系统的重要功能，用例数量较多，占20-30%的比例。 2.划分依据：主要包括一些功能交互相关、各种主要应用场景、使用频率较高的正常功能测试用例。 3.在系统测试版本中基本都需要进行验证，以保证系统所有的重要功能都能够正常实现。
中	1.该类用例涉及系统的一般功能，用例数量较多，占40-60%的比例。 2.划分依据：使用频率低于高级别的用例。例如：数值或数据的边界情况、特殊字符、字符串超长等。 3.在系统测试的中后期并不一定需要每个版本都进行测试。
低	1.如果没有可以不适用该级别 2.该级别用例一般非常少，占10-15%的比例。 3.划分依据：该类用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的触发条件非常特殊，仍然应该被置入低级别用例中。如界面规范化的测试也可归入低级用例。在实际使用中使用频率非常低、对用户可有可无的功能。 4.在系统测试中有某些正常原因（包括：环境、人力、时间等）经过项目经理同意可以不进行测试。

2. 用例等级划分方法

1. 步骤一：

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

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

2. 步骤二：

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

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

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

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

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

3. 步骤三：

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

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

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

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

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