Post by "ted", 05-28-2007, 10:20
-----------------------------------------------------
如何定义测试用例的质量标准？
在定义测试用例的质量标准之前，先要了解设计测试用例的目的。测试用例是测试工作中最重要的元素或测试件（test ware）之一，是测试执行的基础。测试用例不仅能有效地帮助实施后继的回归测试、知识的传递和测试的管理等，而且更重要的是能更快、更有效地发现缺陷，确保测试的系统性和全面性，在测试的深度和广度达到所期望的目标。也就是说，测试用例的质量就是满足测试目标的程度，体现在 “测试覆盖率和测试执行效率”两个方面。所以，测试用例最基本的质量标准就是：
- 达到已定义的或所要求的测试覆盖率，如大于98％。
- 使测试执行的效率达到最好的水平，如最有效的途径并使60％以上的测试用例被测试工具执行。
但是，按照这样的标准，很难在测试执行前或执行过程中评估测试用例的质量，而不得不在执行完这些测试用例之后进行度量，特别是测试覆盖率。所以，理想的情况要求在测试用例设计过程中，可以按照某种特定的质量标准对测试用例进行复审（review）、实施评估。那么，这种特定的质量标准是什么呢？
根据多年的实践经验，测试用例的标准不能局限于一个层次，因为测试用例设计类似于软件设计，软件设计有架构设计（结构设计/概要设计）和详细设计，所以对于测试用例的质量标准，也应分为两个层次来考虑：
高层次——满足某一个测试目标或测试任务来整体看测试用例，衡量一组测试用例的结构、设计思路和覆盖率等指标。
低层次——从单个测试用例看，衡量其描述的规范性、可理解性和可维护性等指标。
1．高层次（high-level）标准
高层次标准是从满足某一个特定的测试目标出发来进行定义，分析一组测试用例的设计思路、设计方法和策略，包括测试用例的层次、结构等。从高层次看，测试用例设计的关键点是：始终从客户需求的角度（出发）想，始终围绕测试的覆盖率和执行效率不断思考，最终通过有效的技术方法完成测试用例的设计。
对于一整套的测试用例组（集合），可定义如下的质量标准：
(1) 测试用例的目标清楚，并能满足软件质量的各个方面，包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。
(2) 设计思路正确、清晰。例如，通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。
(3) 在组织和分类上，测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/层次相一致，或者与测试的目标/子目标的分类/层次相一致，并具有合理的优先级或执行顺序。
(4)测试用例覆盖所有测试点、覆盖所有已知的用户使用场景（User scenario），也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出来，找到相对应的测试用例。
(5)测试手段的区别对待。在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。
(6) 有充分的负面测试。作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。
(7) 没有重复、冗余的测试用例，满足相应的行业标准等。
2．低层次(low-level) 标准
低层次标准是考察单个测试用例是否满足测试的需求，是否能被更有效地执行。测试用例设计的结果就是交付测试用例，使测试用例被执行，所以除了覆盖率，执行的效率也是测试用例的一个重要属性。测试用例越清楚，越容易被理解和执行。执行效率越高就说明测试用例越好，如果测试用例能被机器（computer）执行，当然执行效率得到体现。
对于具体的某个测试用例，不妨可定义如下的质量标准：
(1) 测试用例的出发点是发现缺陷，即单个测试用例在“暴露缺陷”上具有较高的可能性。
(2) 测试用例的单一性。一个测试用例面向一个测试点，不要将许多测试点揉在一起。例如，通过一个测试用例发现1～2个缺陷，而不能发现5～10个缺陷甚至更多的缺陷。
(3) 符合测试用例设计规范或测试用例模板，见下面附表所示。
(4) 描述清楚，包括特定的场合、特定的对象和特定的术语，没有含糊的概念和一般性的描述。例如，测试用例名称为“登录功能使用正常”，就是一个描述不清楚的例子，而这样的描述“登录功能中用户名大小写不敏感性验证”、“登录功能中用户名唯一性验证”和“用户帐号被锁定后再进行登录操作”等就比较好。
(5) 操作步骤的准确性，按照步骤的操作得到唯一的测试结果。
(6) 操作步骤的简单性。操作步骤不应该太复杂，过于复杂的操作步骤意味着测试用例需要被分解为多个测试用例或者分解为多个环节进行验证。
(7) 所期望的测试结果是可验证的，即能迅速、明确地判断测试的实际结果是否与所期望的结果相同或相匹配。例如，在测试用例中描述期望结果为“登录成功”，这实际是不可验证的。要使这个期望结果具有可验证性，我们就应该这样描述所期望的结果——“‘退出（log out）’按钮出现”。
(8) 测试环境的正确性、测试数据的充分性。
(9) 前提条件、依赖性被完全识别出来。
这样，测试用例具有很好的可理解性和可维护性，可以提高测试执行的效率。并能保证不同的人员执行相同的用例能获得统一的结果。步骤的准确性和期望结果的可验证性，非常有助于测试执行的自动化实现。也只有实现了测试执行的自动化，测试执行的效率才是最高的，而且测试人员才有更多的时间去思考、去设计更优秀的测试用例，进入良性循环，相互促进，不断地提升测试的质量和效率。
附表 测试用例模板
字段名称
| 类型
| 注释
| 标志符
| 整型
| 唯一标识该测试用例的值，自动生成
| 测试项
| 字符型
| 测试的对象，可以从软件配置库中选择
| 测试目标
| 字符型
| 从固定列表中选择一个
| 测试环境要求
| 字符型
| 可从列表中选择，如果没有，则直接输入新增内容
| 前提
| 字符型
| 事先设定、条件限制，如已登录、某个选项已选上
| 输入数据
| 字符型
| 输入要求说明、或数据列举
| 操作步骤
| 字符型
| 按1., 2., … 操作步骤的顺序，准确详细地描述。
| 期望输出
| 字符型
|
| 所属模块
| 整型
| 模块标识符。
| 优先级
| 整型
| 1，2，3 （1－优先级最高）
| 层次
| 整型
| 0，1，2，3
( 0 – 最高层)
| 关联的测试用例
| 整型
| 上层（父）用例的标识符。
| 执行时间
| 实型
| 分钟
| 自动化标识
| 布尔型
| T，F
| 关联的缺陷
| 枚举型
| 缺陷标识符列表。
|
|
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图