本文详细介绍了在UML中设计功能测试用例的一种模式，旨在确保测试用例与需求Use Case对应，提高路径覆盖，同时强调测试脚本与测试数据的分离，以降低耦合性和提高维护性。内容涵盖了测试用例设计的基本规则，如测试用例的组成、脚本与数据的分离、需求覆盖性设计，并提出了测试用例度量参数，包括脚本的易用性、易维护性、完整性等。
UML中一种功能测试用例设计模式
作者：廖光明 （liaogm2002@hotmail.com）
1.1 目的
统一项目系统测试阶段测试用例设计方法，达到测试用例与需求Use Case对应，路径覆盖较好、维护方便，测试脚本与数据分离、偶合性低,场景清晰的目的。
1.2 术语说明
按照UML规则和RUP过程，引入如下术语:
The specification (usually formal) of a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a target test item.
测试用例是为特定测试目标开发的测试输入、执行条件和预期结果的集合。这些特定目标可以是：验证一个特定的程序路径或核实是否符合特定需求。
A model that describes a system's functional requirements in terms of use cases.
A description of system behavior, in terms of sequences of actions.
The specification of an executable statement that forms an abstraction of a computational procedure. An action typically results in a change in the state of the system, and can be realized by sending a message to an object or modifying a link or a value of an attribute.
Use Case instance
Use Case instance is the performance of a sequence of actions being specified in a Use Case. A use-case instance is a specific "end-to-end" concrete path through a Use Case—actors are replaced by specific persons (actor instances), specific values and responses are given and only a single path is taken through one or more possible flows of the Use Case. See also: scenario
A specific sequence of actions that illustrates behaviors. A scenario may be used to illustrate an interaction or the execution of one or more use-case instances.
A collection of step-by-step instructions that realize a test, enabling its execution. Test scripts may take the form of either documented textual instructions that are executed manually or computer readable instructions that enable automated test execution.
A package-like artifact used to group collections of test scripts, both to sequence the execution of the tests and to provide a useful and related set of Test Log information from which Test Results can be determined..Synonyms: test driver.
2 适用范围
适用于项目功能测试Test Case的设计。
由于测试用例的复杂性，需要特殊设计的Case，可不受本规范限制。
3 测试用例设计基本规则
3.1 测试用例组成
按照测试用例的定义，测试用例包括输入、执行步骤和期望结果三个基本组成部分。
3.2 测试脚本与测试数据分离
按照测试脚本（Test Script）的定义，测试脚本包括两种类型：
l 用于指导手工测试执行的操作步骤文字描述
l 用于自动测试能被计算机识别的操作步骤代码。
测试程序就是测试操作过程，一个测试程序可输入不同特性的数据，如：典型数据值、边界值、异常值等。因此，为提高脚本使用效率，测试程序与测试数据分离管理。
3.3 测试用例需求覆盖性设计
3.3.1 把 Use-Case model 分解为 Use Case
按照UML的定义:Use-Case model 通过Use Case来描述系统的功能需求。为使Use-Case model可测试，可把Use-Case model分解为Use Case，形成具有明确输入，输出和action组合的功能单元。
3.3.2 从场景生成测试用例
用于功能性测试的测试用例来源于测试目标的Use Case。Use Case中不同的路径确定一个Use Case instance既一个场景，每个场景必需编制测试用例。通过测试用例与Use Case instance的对应来尽可能覆盖测试目标的需求。对应关系如下所示：
3.3.2 场景由分枝构成
根据定义，场景包括一个或以上的分枝；每个场景包括起点、终点和Use Case中某些特定分枝的组合（路径）。生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。
Use Case的与分枝关系图如下：
因此，根据Use Case中不同分枝（即不同备选流）设计场景如下:
| 场景1 | 基本流 |
|
|
|
| 场景2 | 基本流 | 分枝1 |
|
|
| 场景3 | 基本流 | 分枝1 | 分枝2 |
|
| 场景4 | 基本流 | 分枝3 |
|
|
| 场景5 | 基本流 | 分枝3 | 分枝1 |
|
| 场景6 | 基本流 | 分枝3 | 分枝1 | 分枝2 |
| 场景7 | 基本流 | 分枝4 |
|
|
| 场景8 | 基本流 | 分枝3 | 分枝4 |
|
根据1.2节的定义，每个分枝包括一个或以上的Action.每个Action尽量对应一个测试脚本，当需求变更时，以实现维护量最小。通过Main脚本来组合不同Branch，形成一个Scenario。Use Case与Test Case在TD中的实现方式如下图所示：
Use Case scenario因业务复杂性不同，规模差距悬殊。在实际测试中可分拆为多个子场景，从而对应不同粒度的测试用例。一个完整的测试用例应该有明确的输入/输出数据或明确的状态改变。因此，一般可通过缩短路径来提高测试用例 的粒度。
3.5 手工测试用例设计基本规则
测试用例属性一般包括对应的Use Case ID，Pre-condition，Version等，关于测试程序与测试数据的分离表示模板如下,根据实际情况，可适当修改。
3.5.1 基本模板
测试脚本:
| 测试操作及输入 | 预期结果描述 | |
| Step1 |
|
|
| Step2 |
|
|
| Step3 |
|
|
| Step4 |
|
|
| …… |
|
|
数据列表：
| Test Case No. | 输入数据 | 期望数据 | |||
| inputField1 | …… | inputFieldN | outputField1 | outputFieldN | |
| 典型值 |
|
|
|
|
|
| 边界值 |
|
|
|
|
|
| 异常值1 |
|
|
|
|
|
| 异常值2 |
|
|
|
|
|
| …… |
|
|
|
|
|
3.5.2 输入说明
测试脚本中Step必需包含如下任一个要素:
1) 有明确的用户数据输入；
2) 一个用户操作界面或页面的变换；
3) 一个明确的消息触发或值的输出；
数据例表中，输入数据字段必须包含用户从界面输入的所有字段，期望数据必需包含测试目的所需要检验的字段，包含：业务运算结果和状态标记字段等。
3.5.3 测试脚本与测试数据的交互
TD中手工测试用例测试脚本与测试数据的组织方案如下：
每个测试脚本在TestSet中生成多个Test Case Instance，每个Test Case Instance对应测试数据库中的一条记录。
如图所示：
3.6 自动化测试用例设计基本规则
见《自动化测试脚本设计规范》 –作者：廖光明
4 测试用例度量参数
4.1 测试脚本的度量
1. 易用性。
对于一个即熟悉测试工作，又熟悉被测程序的测试人员，应当可以花费很少的时间就可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。
2. 易维护性
当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。
3. Checkpoint完整性
对与业务相关数据和状态进行了有效检查，无遗漏处；
4. 偶合性低（模块化程度）
输入、输出和状态变化明确，具有明确界面，状态标志清晰; 对输入/输出的数据或状态标识进行参数化，便于测试数据的组合输入和检查；
5. 代码行数（或操作step数）
4.2 测试数据的度量
1. 逻辑覆盖率
测试数据代表不同的逻辑路径：如典型值数据组合，边界值组合等。
4.3 测试用例度量值
1. Bug发现数
2. 脚本维护次数
3. 脚本行数
扫一扫
71
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
