软件测试用例规范

1. 目的

(1) 为用例的质量负责，使用例编写工作能够有序、合理；

(2) 为测试人员设计用例提供一种规范；

(3) 能有效的提高系统所有功能点的覆盖率。

2. 适用范围

适用于人员：测试人员

适用于公司对项目的业务流程、功能（功能点）测试的测试用例编写。

3 测试用例

用例概念：

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

用例的用途

1. 指导测试工作有序进行，使实施测试的数据有据可依
2. 确保所实现的功能与客户预期的需求相符合
3. 跟踪测试进度，确定测试重点
4. 评估测试结果的度量标准
5. 分析缺陷的标准

用例的内容格式

编号

用例名称

摘要

前提

优先级

步骤编号

步骤

期望结果

测试结果

BugID

测试日期

1. 编号：用例编号，唯一标识；
2. 用例名称：测试用例的名称，体现测试要点
3. 摘要：要测试的功能点（系统、模块功能）
4. 前提：测试执行前需准备的相关操作，如测试数据、角色权限，或登入系统某页面等
5. 优先级：测试用例的优先级别，分为高、中、低
6. 步骤编号：操作步骤的编号，用于后期导入相应的测试用例工具
7. 步骤：完成该测试点所需的操作步骤
8. 期望结果：执行完成操作后，程序预期表现的结果
9. 测试结果：

与预期结果是否相符，相符实际结果内显示Pass（表明用例通过）

与预期结果不一致显示Failed（表明执行有偏差/错误）

1. BugID：提交Bug后，redmine中自动生成的ID
2. 测试日期：执行测试用例的日期

4 用例设计方法

测试用例设计方法

等价类划分法：

是一种最典型的黑盒测试方法，它完全不考虑程序的内部结构，而是只根据对程序的要求和说明进行测试用例的设计。测试人员要求对需求说明书中的各项功能需求进行细致分析，把程序的输入域划分成若干个部分，然后从每个部分中选取少数代表性数据作为测试用例，经过这种划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值

边界值分析法：

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

如：控件可录入字符的【最小值-1，最小值，最大值，最大值+1】

错误推测法：

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法，列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

5 测试用例设计的原则

全面性

1. 应尽可能覆盖程序的各种路径。
2. 应考虑存在跨年、跨月的数据。
3. 大量数据并发测试的准备。

正确性

1. 输入界面后的数据应与测试文档所记录的数据一致；
2. 预期结果应与测试数据发生的业务吻合。

符合正常业务惯例

1. 测试数据应符合用户实际工作业务流程。
2. 兼顾各种业务变化的可能。

系统性

1. 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系。
2. 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系。

连贯性

1. 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确。
2. 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。

仿真性

人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。

可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

6 用例设计步骤

        (1) 测试需求分析：

从项目需求分析文档/概要设计/详细设计/原型图中，了解出项目的需求。通过测试人员自己的分析、 理解，整理成为测试需求，使测试人员能清楚被测项目包含的功能点。

        (2) 业务流程分析：

分析了解被测试项目所属的行业及其业务知识。对被测项目的业务流程要全部梳理出来（可画出项目的流程图，也可用头脑风暴）。

项目的流程：主线流程、分支流程、数据流转，流转过程中关键点的判断条件以及完成操作的一些非必要条件。

       (3) 测试用例设计：

主要包括功能测试、界面测试、兼容性测试、易用性测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑录入正常、边界、异常值等系统的处理情况 Ø

       (4) 测试用例评审：

由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员及其他相关的测试人员。

       (5) 测试用例完善：

测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后， 测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。