广州科众
系统测试用例编写指南
版本信息
目录
1 文档概述 (4)
1.1编写目的 (4)
1.2应用范围 (4)
1.3阅读指引 (4)
1.4参考文档 (4)
2 系统测试需求 (5)
2.1测试需求概述 (5)
2.2系统测试需求 (5)
2.3测试特性跟踪矩阵 (5)
3 系统测试用例 (6)
3.1测试用例概述 (6)
3.2功能测试用例 (6)
3.3性能测试用例 (6)
3.4配置/安装/兼容性测试用例 (7)
4 编号规则 (8)
4.1规则概述 (8)
4.2测试需求编号 (8)
4.3测试用例编号 (8)
1文档概述
1.1 编写目的
为了规范系统测试用例的编写格式，以及对系统测试用例的管理；特制定此规范。

1.2 应用范围
本规范为测试工程师编写系统测试规格说明书时提供格式上的指导，本规范不涉及具体的测试设计方法。

1.3 阅读指引
本规范的第2章定义了测试特性跟踪矩阵的相关要求，第3章对常用系统测试的格式做了规定，第4章对测试需求和测试用例所使用的编号规则做了规定。

1.4 参考文档
2系统测试需求
2.1 测试需求概述
这里“测试需求”是指“测试的需求”，不是对需求进行测试。

测试需求与系统需求很像，它强调的是要对什么进行测试。

测试需求来源于项目开发中其他作品，如系统测试需求可能来源于需求规格、Use Case模型、用户手册和产品原型等，而单元测试需求可能来源于详细设计规格说明和设计模型等，而集成测试需求则可能来源于总体设计等。

2.2 系统测试需求
系统测试需求主要来源于需求规格说明，对于不同类型的需求规格需要进行不同类型的测试。

系统需求可分为两类：功能需求和非功能需求（又称技术需求或运作需求）。

功能需求描述的是系统要做什么，而非功能需求描述的系统运作所要求的条件，如：性能、配置和兼容性等。

如上所述根据不同类型的需求就有功能测试、性能测试、配置测试、安装测试和兼容性测试等测试类型。

对功能测试来讲，最有意义的是可执行需求规格（如Use Case），如果没有可执行需求规格，则需要系统分析员或测试分析员进行可执行需求规格的开发。

而从可执行需求规格到功能测试用例的过程则相对来讲是个较为机械的过程。

对性能测试来讲，性能需求的描述相对来说是简单的，性能测试的工作重点就是使用性能测试工具开发测试脚本并执行脚本。

2.3 测试特性跟踪矩阵
3系统测试用例
3.1 测试用例概述
设计测试用例的目的是确定并传达一些条件，这些条件将在测试中执行，并且是核实实现产品需求（功能、性能等）是否成功和能否接受所必需的条件。

测试用例反映了一种测试覆盖（基于需求规格的测试覆盖）评测方法，这是因为每个测试用例都至少可以追踪到一个测试需求，而这些需求反映出产品的需求。

3.2 功能测试用例
3.3 性能测试用例
3.4 配置/安装/兼容性测试用例
待定。

4编号规则
4.1 规则概述
为了在测试用例管理和需求管理的过程中方便对需求的管理、对测试用例的管理和在测试用例管理的过程中实现对需求规格的可追溯性；对测试用例和需求规格的具体条目使用统一的编号规则。

编号的基本规则如下：
a)编号格式为：.dd。

b)X为类型，aa、bb、cc、dd四个字段代表规格描述的不同层次的数字编号。

c)在一个项目的同一类文档中，条目的编号必须是唯一的。

d)文档经评审后，条目编号不允许改变。

e)增加条目时，在需要改变字段中以当前段的最大数字为基础增加。

f)当条目内容改变时，条目编号不变，将原条目移至附录的变更记录，再更新原条目。

g)当条目删除时，条目编号不删除，将原条目移至附录的变更记录。

h)当条目删除时，条目编号被保留。

4.2 测试需求编号
测试需求条目的编号只使用三个字段来描述，即：aa、bb、cc。

具体意义如下所下表所示：
4.3 测试用例编号
测试用例条目编号使用全部四个字段来描述，是在测试需求的基础上增加第四个字段而。