测试用例编写规范

1， 目的
测试用例是测试人员执行测试活动基本依据，因此测试用例输出质量高低直接影响迭代产品测试活动有效性和效率。为了保证测试执行人员使用最有效的测试用例，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，最终提高产品线的质量。特编写统一测试用例编写规范，为测试设计人员提供测试用例设计编写指导，提高编写用例的可读性、可执行性、合理性。

2， 范围
适用于公司各业务线测试人员对功能测试用例或接口测试用例的编写。

3 用例设计流程
3.1， 测试分析：进行测试用例编写的前提。测试人员根据产品需求团队提供产品PRD或开发团队提供的设计文档进行测试需求分析，确认明确或隐含的需求要求。从而确认测试范围，联调测试范围，外部合作团队的配合范围等。

3.2， 测试设计：依据测试分析整理并编写出测试用例（思维导图），细化为测试用例。在项目时间要求下，测试用例评审对象是脑图或完整测试用例，详细测试用例会抽取一些作为附加评审对象。参加的人员应包括测试负责人、项目经理、开发人员及其他相关的测试人员。

3.3， 测试用例完善：产品组需求迭代版本测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须定期修改更新；在测试过程中发现设计测试用例时考虑不全，需要对测试用例进行修改完善；产品上线后业务方反馈问题，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。任何测试用例的新增和更新均需要经过测试用例评审流程。

4， 规范要求
4.1 测试用例整体要求

• 测试用例编写应按照产品PRD文档、迭代产品架构设计文档及测试需求功能分析点进行编写，要求覆盖全部需求功能点。

• 测试用例编写应该制订统一的测试用例模板执行，并约定模板的使用方法

• 测试用例中要写清楚测试的操作步骤和预期结果，能被不同测试人员，开发人员，产品经理和项目经理理解和执行

• 测试用例中要明确一级模块、二级模块和三级功能

• 同一个功能点的测试用例，功能流程或接口测试需要单独编写，因为它们的功能呈现和操作方式不同

• 界面显示、错误信息提示、用户界面友好性等界面相关检查暂不作为测试范围，由业务方团队负责验收

• 注重测试用例的可复用性，即在以后相似系统的测试过程中可以重复使用

• 测试用例编写和评审都用Excel表格，评审通过后的测试用例导入统一测试管理平台。

4.2 测试用例组成部分

一般的测试用例包括如下组成部分：需求标识、用例标识、用例标题、摘要、重要性、前提条件、操作步骤、预期结果、用例编写者、状态、预期执行耗时、测试方式。

需求标识：唯一标识，与用例编号对应，为一对多关系。

用例标识：能够准确的标识每一条用例，每一个用例编号在所有测试用例中必须唯一(testLink自动生成)。

摘要：用例的测试目的、适用实体和相关信息的简单介绍。

用例标题：能够清晰表达测试用例的测试目的和关键测试要素。

用例集目录：标明用例所处的一级模块、二级模块或三级功能等，如果某个模块比较复杂，可能会有更多层级，每个层级会用斜杠分隔。

重要性：区分测试用例的重要程度，确定用例执行的级别。

前提条件：需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所需要处于的状态和配置。需要保证在完成预置条件中所描述的状态和配置以及外部环境后，测试执行的正确性、一致性。

操作步骤：为了达到测试用例的测试目的，所需要执行的操作；每个操作步骤对应一个预期结果。

预期结果：针对测试用例的测试目的，测试步骤中操作后对应的预期输出状态。

用例编写者：测试用例的设计人员。

状态：评审之前为“草稿”状态，评审通过后为“就绪”状态。

预期执行耗时：测试用例完整执行一遍所需要的。

是否需要自动化：是/否。

是否已经自动化：是/否。

4.3 测试用例实现规则

规则1：用例描述要求
每个用例必需要有至少一条操作步骤和预期结果；
操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
操作步骤中不要包含结果的检查；
预期结果中只能包含结果，不能有步骤；
用例描述中不允许出现假设性词汇，比如：假如，或许，可能等；
用例描述中不允许出现二义性语句。
用例命名格式：模块_用例标题；
用例名称不允许出现重复、包含关系，或者仅有数字编号差异；
用例名称简介易懂，不要包括具体操作步骤；
规则2：用例名称要求
每条测试用例必须有明确的用例名称。
每条测试用例基线化后，要进行版本归档。
规则3：用例要素要求
用例标识、用例标题、摘要、重要性、操作步骤、预期结果、用例编写者、状态、预期执行耗时为必填内容，不能为空，其他字段为选填内容。

规则4：用例重要性要求
由于User Story的优先级决定的是在一个版本中的开发优先级，用例的重要性参考的是模块对于系统功能的重要度，因此这里的重要性不以Use Story优先级为参考依据。

高（优先执行）：产品基本的功能验证，即关键路径的测试用例，包括最常执行的功能、基本流程的输入（正向流程+正向数据）。
中（次级执行）：包括界面数据有效性校验、默认值、边界值。
低（最后执行）：建议执行的测试用例，包括不常执行的功能、异常流程的输入以及异常数据的输入。
执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
前提条件包括测试执行入口、账号类型和权限、数据准备；
不可将其他用例作为前置条件，但可以将其它用例执行结果作为前置条件。
每一测试步骤只能对应一条预期结果；
每一条预期结果与其对应的测试步骤的编号要求保持一致；
一个结果有多个检查点时，确保检查点完整；
规则5：用例执行前提要求
需要对测试用例执行前的要求进行说明。
规则6：测试步骤与预期结果要求
结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
结果涉及页面，需明确页面提示结果、数据变化；
结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
结果涉及消息：需明确关键查看内容；
结果对应不同输入数据有差别时需分别对应描述清晰。
规则7：测试数据要求
测试数据在步骤里面明确列出
测试数据编写形式为：[字段名：字段值]
对于页面输入数据，需要区分系统字段与自定义字段
5， 用例设计方法
5.1 等价类划分

把全部输入数据合理地划分成若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况：有效等价类和无效等价类。

5.2 边界值测试

大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

5.3 错误推测

基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。

5.4 分类树

分类树方法是在软件功能测试方面一种有效的测试方法，通过分类树把测试对象的整个输入域分割成独立的类。按照分类树方法，测试对象的输入域被认为是由各种不同的方面组成并且都与测试相关。对于每个方面，分离和组成各种类别，而分类结果的各类又可能再进一步地被分类。这种通过对输入域进行层梯式的分类表现为树状结构。随后，通过组合各种不同分类的结果来形成测试用例。

5.5 常用功能测试点

检查类型

检查点

输入数据设计

边界值，边界值+1，边界值-1
最大个数，最大个数+1，最小个数，最小个数-1
空值、空表
极限值
0值，负数，非法字符
日期、时间控制
跨年度数据
数据格式
数据之间的关联性、逻辑性
计算方式以及计算结果准确性，数字精度的取舍问题，汇总数据与分项数据累加的误差问题
常用的较验

字段长度较验
必输项校验
重名校验
字符类型较验
标点符号检查
中文字符处理
按键处理

浏览器前进后退
常用快捷键检查
回车键检查
默认值

文本框
单选框
多选框
下拉列表
界面检查

只读项
文字拼写
字体
页面跳转
按钮功能
6， 用例维护
6.1 新增测试用例

对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明

6.2 修改测试用例

随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明

6.3 删除冗余的测试用例

如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个增添新的测试用例

6.4 归档过时的测试用例

因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的归档。当前测试用例状态会被更改并且移动到归档测试用例目录下。

7， 总结
测试用例编写维护需要大量的时间，版本也要进行维护和更新，迭代版本的测试用例可放在对项目组的wiki，SVN或Git上进行持久化保存。