功能黑盒测试，著名的经典三角形测试用例设计方法分析

Mario洁

黑盒测试案例设计技术篇

1  概述

本章介绍黑盒测试的概念和进行黑盒测试的目的与意义，及关于等价类划分、边界值分析、因果图法、判定
表法、正交试验法、功能图法等测试用例设计方法的原理与实现，并从测试设计说明、测试用例说明、测试
程序说明三个方面介绍如何编写测试用例，最后结合一个ATM的例子体现如何设计测试用例。

2  测试用例设计方法

初涉软件测试者可能认为拿到软件后就可以立即进行测试，并希望马上找出软件的所有缺陷，这种想法就如
同没有受过工程训练的开发工程师急于去编写代码一样。软件测试也是一个工程，也需要按照工程的角度去
认识软件测试，在具体的测试实施之前，我们需要明白我们测试什么，怎么测试等，也就是说通

过制定测试用例指导测试的实施。

2.1  什么是测试用例

所谓的测试用例设计就是将软件测试的行为活动，作一个科学化的组织归纳。软件测试是有组织性、步骤性
和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是
软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加
以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。

简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的
执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测
出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件
开发人员接获通知后，将这个问题修改完成于下一个测试版本内，软件测试工程师取得新的测试版本后，必
须利用同一个用例来测试这个问题，确保该问题已修改完成。

因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中
精心挑选出具有代表性或特殊性的测试数据来进行测试。

使用测试用例的好处主要体现在以下几个方面。

① 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

② 测试用例的使用令软件测试的实施重点突出、目的明确。

③ 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。

④ 功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并
随着测试用例的不断精化其效率也不断攀升。

具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、
正交试验设计法、功能图法等。应该说，这些方法是比较实用的，但采用什么方法，在使用时自然要针对开
发项目的特点对方法加以适当的选择。下面我们讨论几种常用的方法。

2.2  等价类划分法

等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据
对程序的要求和说明，即需求规格说明书。我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。
把说明中对输入的要求和输出的要求区别开来并加以分解。

由于穷举测试工作量太大，以至于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为
测试用例。例如，在不了解等价分配技术的前提下，我们做计算器程序的加法测试时，测试了1+1，1+2，
1+3和1+4之后，还有必要测试1+5和1+6吗，能否放心地认为它们是正确的？我们感觉1+5和1+6，与
前面的1+1，1+2都是很类似的简单加法。

等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试
用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个
例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有
发现错误，则这一类中的其他例子也不会查出错误（除非等价类中的某些例子属于另一等价类，因为几个
等价类是可能相交的）。使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，
列出等价类表。

1．划分等价类和列出等价类表

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并
合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。

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

有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可
检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：与有效等价类的定义恰巧相反。

设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考
验。这样的测试才能确保软件具有更高的可靠性。

下面给出6条确定等价类的原则：

① 在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。

② 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类
和一个无效等价类。

③ 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

④ 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立
n个有效等价类和一个无效等价类。

⑤ 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效
等价类（从不同角度违反规则）。

⑥ 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步
地划分为更小的等价类。

在确立了等价类之后，建立等价类表，列出所有划分出的等价类如表5-1所示。

表5-1  等价类表示例

输入条件有效等价类无效等价类输入条件有效等价类无效等价类

………………

2．确定测试用例

根据已列出的等价类表，按以下步骤确定测试用例：

① 为每个等价类规定一个惟一的编号。

② 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有
效等价类均被测试用例所覆盖。

③ 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。请看一些例子。

在两数相加用例中，测试1+13和1+99999999似乎有点不同。这是一种直觉，一个是普通加法，而另一
个似乎有些特殊，这个直觉是对的。程序对1和最大数值相加的处理和对两个小一些的数值相加的处理有
所不同。后者必须处理溢出情况。因为软件操作可能不同，所以这两个用例属于不同的等价区间。

如果具有编程经验，就可能会想到更多可能导致软件操作不同的“特殊”数值。如果不是程序员，也不用担
心，你很快就会学到这种技术，无须了解代码细节就可以运用。


如图5-1

如图5-1所示是复制的多种方法，给出了选中编辑菜单后显示复制和粘贴命令的计算器程序。每一项功能（
即复制和粘贴）有5种执行方式。要想复制，可以单击复制菜单命令，键入C，按Ctrl+C或Ctrl+Shift+C组
合键。任何一种输入途径都会把当前数值复制到剪贴板中，一一执行同样的输出操作，产生同样的结果。

如果要测试复制命令，可以把这5种输入途径划分减为3个，单击菜单命令，键入C和按Ctrl+C组合键。对
软件质量有了信心之后，知道无论以何种方式激活复制功能都工作正常，甚至可以进一步缩减为1个区间，
例如按Ctrl+C组合键。

再看下一个例子。看一下在标准的另存为对话框（如图5-2所示）中输入文件名称的情形。

Windows文件名可以包含除了“、”、“/”、“：”、“·”、“?”、“<>”和“”之外的任意字符。文件名长度是1
～255个字符。如果为文件名创建测试用例，等价区间有合法字符、非法字符、合法长度的名称、过长
名称和过短名称。

例题：根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。“一个程序读入3个整
数，把这3个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形是不等边
的、是等腰的、还是等边的”。

我们可以设三角形的3条边分别为A，B，C。如果它们能够构成三角形的3条边，必须满足：

A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。

图5-2  存盘对话框

如果是等腰的，还要判断A=B，或B=C，或A=C。

如果是等边的，则需判断是否A=B，且B=C，且A=C。

列出等价类表，如表5-2所示。

表5-2  等 价 类 表

输 入 条 件有效等价类无效等价类

是否三角形的3条边（A>0），      （1）

（B>0），      （2）

（C>0），      （3）

（A+B>C），   （4）

（B+C>A），   （5）

（A+C>B）    （6）

（A≤0），       （7）

（B≤0），       （8）

（C≤0），       （9）

（A+B≤C），    （10）

（B+C≤A），    （11）

（A+C≤B）     （12）

是否等腰三角形（A=B），     （13）

（B=C），     （14）

（C=A），     （15）

（A≠B）and（B≠C）and（C≠A），

（16）

是否等边三角形（A=B）and（B=C）and（C=A），

（17）

（A≠B），       （18）

（B≠C），       （19）

（C≠A），       （20）

设计测试用例：输入顺序是【A，B，C】，如表5-3所示。

表5-3  测 试 用 例

序号【A，B，C】覆盖等价类输    出

1【3，4，5】（1），（2），（3），（4），（5），（6）一般三角形

2【0，1，2】（7）不能构成三角形

3【1，0，2】（8）

4【1，2，0】（9）

5【1，2，3】（10）

6【1，3，2】（11）

7【3，1，2】（12）

8【3，3，4】（1），（2），（3），（4），（5），（6），（13）等腰三角形

9【3，4，4】（1），（2），（3），（4），（5），（6），（14）

10【3，4，3】（1），（2），（3），（4），（5），（6），（15）

11【3，4，5】（1），（2），（3），（4），（5），（6），（16）非等腰三角形

12【3，3，3】（1），（2），（3），（4），（5），（6），（17）是等边三角形

13【3，4，4】（1），（2），（3），（4），（5），（6），（14），（18）非等边三角形

14【3，4，3】（1），（2），（3），（4），（5），（6），（15），（19）

15【3，3，4】（1），（2），（3），（4），（5），（6），（13），（20）

请记住，等价分配的目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。因为，选择
了不完全测试，就要冒一定的风险，所以必须仔细选择分类。

关于等价分配最后要讲的一点是，这样做有可能不客观。科学有时也是一门艺术。测试同一个复杂程序
的两个软件测试员，可能会制定出两组不同的等价区间。只要审查等价区间的人都认为它们足以覆盖测
试对象就可以了。

2.3  边界值分析法

人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上的，而不是在输入范围
的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。例如，在做三角形计算时，要输
入三角形的3个边长A、B和C。这3个数值应当满足A>0、B>0、C>0、A+B>C、A+C>B、B+C>A，才
能构成三角形。但如果把6个不等式中的任何一个大于号“>”错写成大于等于号“≥”，那就不能构成三角
形。问题恰恰出现在容易被疏忽的边界附近。这里所说的边界是指相当于输入等价类和输出等价类而言，
稍高于其边界值及稍低于其边界值的一些特定情况。

1．边界条件

我们可以想象一下，如果在悬崖峭壁边可以自信地安全行走，平地就不在话下了。如果软件在能力达
到极限时能够运行，那么在正常情况下一般也就不会有什么问题。

边界条件是特殊情况，因为编程从根本上说不怀疑边界有问题。奇怪的是，程序在处理大量中间数值
时都是对的，但是可能在边界处出现错误。下面的一段源代码说明了在一个极简单的程序中是如何产
生边界条件问题的。

Mario洁

rem create a 10 element integer array

rem initialize each element to–1

dim data（10）as integer

dim i as integer

for i=1 to 10

data（i）=–1

next i

end

这段代码的意图是创建包含10个元素的数组，并为数组中的每一个元素赋初值–1。看起来相当简单。
它建立了包含10个整数的数组data和一个计数值i。For循环是从1～10，数组中从第1个元素到第10个
元素被赋予数值–1。那么边界问题在哪儿呢？

在大多数开发语言脚本中，应当以声明的范围定义数组，在本例中定义语句是dim data（10）as interg
er，第一个创建的元素是data（0），而不是data（1）。该程序实际上创建了一个从data（0）～ data
（10）共11个元素的数组。程序从1～10循环将数组元素的值初始化为-1，但是由于数组的第一个元素
是data（0），因此它没有被初始化。程序执行完毕，数组值如下：

data(0)= 0data(6)= –1

data(1)= –1data(7)= –1

data(2)= –1data(8)= –1

data(3)= –1data(9)= –1

data(4)= –1data(10)= –1

data(5)= –1

注意data（0）的值是0，而不是–1。如果这位程序员以后忘记了，或者其他程序员不知道这个数据数组是
如何初始化的，那么他就可能会用到数组的第1个元素data（0），以为它的值是–1。诸如此类的问题很常
见，在复杂的大型软件中，可能导致极其严重的软件缺陷。

2．次边界条件

上面讨论的普通边界条件是最容易找到的。它们在产品说明书中有定义，或者在使用软件的过程中确定。
而有些边界在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查。这样的边界条件称为次边界
条件或者内部边界条件。

寻找这样的边界不要求软件测试员具有程序员那样阅读源代码的能力，但是要求大体了解软件的工作方式。
2的乘方和ASCII表就是这样的例子。

（1）2的乘方

计算机和软件的计数基础是二进制数，用位（bit）来表示0和1，一个字节（byte）由8位组成，一个字（w
ord）由两个字节组成等。表5-4中列出了常用的2的乘方单位及其范围或值。

表5-4  软件中2的乘方

术    语范围或值术    语范围或值

位0或1千1,024

双位0～15兆1,048,576

字节0～255亿1,073,741,824

字0～65,535万亿1,099,511,627,776

表5-4中所列的范围和值是作为边界条件的重要数据。除非软件向用户提出这些范围，否则在需求文档中
不会指明。然而，它们通常由软件内部使用，外部是看不见的，当然，在产生软件缺陷的情况下可能会看到。

在建立等价区间时，要考虑是否需要包含2的乘方边界条件。例如，如果软件接受用户输入1～1000范围
内的数字，谁都知道在合法区间中包含1和1000，也许还要有2和999。为了覆盖任何可能的2的乘方次边界，
还要包含临近双位边界的14、15和16，以及临近字节边界的254、255和256。

（2）ASCII表

另一个常见的次边界条件是ASCII字符表。如表5-5所示是部分ASCII值表的清单。

表5-5  部分ASCII值表

字符ASCII值字符ASCII值字符ASCII值字符ASCII值

Null0B66250a97

Space32Y89957b98

/47Z90:58y121

048[91@64z122

149'96A65{123

注意，表5-5不是结构良好的连续表。0～9的后面ASCII值是48～57。斜杠字符（/）在数字0的前面，
而冒号字符“：”在数字9的后面。大写字母A～Z对应65～90。小写字母对应97～122。这些情况都代表
次边界条件。

如果测试进行文本输入或文本转换的软件，在定义数据区间包含哪些值时，参考一下ASCII表是相当明智
的。例如，如果测试的文本框只接受用户输入字符A～Z和a～z，就应该在非法区间中包含ASCII表中这
些字符前后的值@、[ 、和{ 。

（3）其他一些边界条件

另一种看起来很明显的软件缺陷来源是当软件要求输入时（比如在文本框中）,不是没有输入正确的信息，
而是根本没有输入任何内容，只按了Enter键。这种情况在产品说明书中常常被忽视，程序员也可能经常
遗忘，但是在实际使用中却时有发生。程序员总会习惯性地认为用户要么输入信息，不管是看起来合法
的或非法的信息，要么就会选择Cancel键放弃输入，如果没有对空值进行好的处理的话，恐怕程序员自
己都不知道程序会引向何方。

正确的软件通常应该将输入内容默认为合法边界内的最小值，或者合法区间内的某个合理值，否则，返
回错误提示信息。

因为这些值通常在软件中进行特殊处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独
的等价区间。
3．边界值的选择方法

边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价
类边界的测试用例。实践证明，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。
边界值分析法不仅重视输入条件边界，而且也适用于输出域测试用例。

对边界值设计测试用例，应遵循以下几条原则：

① 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的
值作为测试输入数据。

② 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作
为测试数据。

③ 根据规格说明的每个输出条件，使用前面的原则①。

④ 根据规格说明的每个输出条件，应用前面的原则②。

⑤ 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元
素作为测试用例。

⑥ 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

⑦ 分析规格说明，找出其他可能的边界条件。

2.4  错误推测法

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

错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择
测试用例。例如，设计一些非法、错误、不正确和垃圾数据进行输入测试是很有意义的。如果软件要
求输入数字，就输入字母。如果软件只接受正数，就输入负数。如果软件对时间敏感，就看它在公元
3000年是否还能正常工作。还有，例如，在单元测试时曾列出的许多在模块中常见的错误，以前产品
测试中曾经发现的错误等，这些就是经验的总结。另外，输入数据和输出数据为0的情况，或者输入表
格为空格或输入表格只有一行，这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

2.5  因果图法

前节介绍的等价类划分方法和边界值分析法都是着重考虑输入条件，并没有考虑到输入情况的各种组
合，也没考虑到各个输入情况之间的相互制约关系。如果在测试时必须考虑输入条件的各种组合，可
能的组合数将是天文数字。因此必须考虑描述多种条件的组合，相应地产生多个动作的形式来考虑设
计测试用例，这就需要利用因果图。在软件工程中，有些程序的功能可以用判定表的形式来表示，并
根据输入条件的组合情况规定相应的操作。很自然，应该为判定表中的每一列设计一个测试用例，以
便保证测试程序在输入条件的某种组合下，操作是正确的。

1．因果图设计方法

因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的
改变），通过因果图转换为判定表。

利用因果图导出测试用例需要经过以下几个步骤：

① 分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等
价类，而结果是输出条件。

② 分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。

③ 标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这
些特定的情况，在因果图上使用若干个标准的符号标明约束条件。

④ 把因果图转换成判定表。

⑤ 为判定表中每一列表示的情况设计测试用例。

因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，
构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而增加。

事实上，在较为复杂的问题中，这个方法常常是十分有效的，它能有力地帮助我们确定测试用例。
当然，如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图了，而是可以直接利用
判定表设计测试用例了。

通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如图5-3所示。各结点表示状态，可取“
0”或“1”值。“0”表示某状态不出现，“1”表示某状态出现。

图5-3  因果图的基本图形符号

① 恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。

② 非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。

③ 或（∨）：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现。

④ 与（∧）：若几个原因都出现，结果才出现。若其中有1个原因不出现，则结果不出现。

为了表示原因与原因之间、结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束
条件的符号。从输入（原因）考虑，有4种约束，例如：（a）、（b）、（c）、（d）。从输出（结果
）考虑，还有1种约束，例如：（e），如图5-4所示。

图5-4  因果图的约束符号

① E（互斥）：表示a、b两个原因不会同时成立，两个中最多有一个可能成立。

② I（包含）：表示a、b、c这3个原因中至少有一个必须成立。

③ O（惟一）：表示a和b当中必须有一个，且仅有一个成立。

④ R（要求）：表示当a出现时，b必须也出现。a出现时不可能b不出现。

⑤ M（屏蔽）：表示当a是1时，b必须是0。而当a为0时，b的值不定。

2．因果图测试用例

例如：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、
“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币。

分析这一段说明，我们可以列出原因和结果。

原因：① 投入1元5角硬币；② 投入2元硬币；

原因：③ 按“可乐”按钮；④ 按“雪碧”按钮；⑤ 按“红茶”按钮。

中间状态：① 已投币；② 已按钮。

结果：① 退还5角硬币；② 送出“可乐”饮料；

原因：③ 送出“雪碧”饮料；④ 送出“红茶”饮料。

根据原因和结果，我们可以设计这样一个因果图（如图5-5所示。）

图5-5  因果图

转换为测试用例，如表5-6所示，每一列可作为确定测试用例的依据。

表  5-6

1234567891011

输

入

投入1元5角硬币（1）11110000000

投入2元硬币（2）00001111000

按“可乐”按钮（3）10001000100

按“雪碧”按钮（4）01000100010

按“红茶”按钮（5）00100010001

中间

结点

已投币（11）11111111000

已按钮（12）11101110111

输

出

退还5角硬币（21）00001110000

送出“可乐”饮料（22）10001000000

送出“雪碧”饮料（23）01000100000

送出“红茶”饮料（24）00100010000

Mario洁

2.6  判定表驱动法

前面因果图方法中已经用到了判定表。判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。在程
序设计发展的初期，判定表就已被用作编写程序的辅助工具了。它可以把复杂的逻辑关系和多种条件组合的
情况表达得较明确。

1．判定表组成

判定表通常由4个部分组成，如图5-6所示。

图5-6  判定表

 条件桩（condition stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

 动作桩（action stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

 条件项（condition entry）：列出针对它所列条件的取值，在所有可能情况下的真假值。

 动作项（action entry）：列出在条件项的各种取值情况下应该采取的动作。

 规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是
一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，条件项和动作项就有多少列。

2．判定表建立

判定表的建立因该依据软件规格说明，步骤如下：

① 确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有2n种规则。

② 列出所有的条件桩和动作桩。

③ 填入条件项。

④ 填入动作项。制定初始判定表。

⑤ 简化。合并相似规则或者相同动作。

Beizer指出了适合使用判定表设计测试用例的条件：

① 规格说明以判定表的形式给出，或很容易转换成判定表。

② 条件的排列顺序不影响执行哪些操作。

③ 规则的排列顺序不影响执行哪些操作。

④ 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

⑤ 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

2.7  正交试验法

利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求
规格说明中得到。往往因果关系非常庞大，导致利用因果图而得到的测试用例数目多得惊人，给软件测
试带来沉重的负担。为了有效地、合理地减少测试的工时与费用，可利用正交试验法进行测试用例的设计。

1．正交试验设计方法

依据Galois理论，正交试验设计方法是从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排
测试的一种科学的试验设计方法。

正交试验法，就是使用已经造好了的表格“——”正交表来安排试验并进行数据分析的一种方法。它简单易
行并且计算表格化，应用性较好。下边通过一个例子来说明正交试验法。

例题：为提高某化工产品的转化率，选择了三个有关因素进行条件试验，反应温度（A），反应时间（B）
，用碱量（C），并确定了它们的试验范围如下。

 A：80～90℃；

 B：90～150分钟；

 C：5%～7%。

试验目的是搞清楚因子A、B、C对转化率有什么影响，哪些是主要的，哪些是次要的，从而确定最适生
产条件，即温度、时间及用碱量各为多少才能使转化率最高。这里，对因子A、B和C，在试验范围内都
选了三个水平，如下所示。

 A：A1=80℃，A2=85℃，A3=90℃；

 B：B1=90分钟，B2=120分钟，B3=150分钟；

 C：C1=5%，C2=6%，C3=7%。

当然，在正交试验设计中，因子可以是定量的，也可以是定性的。而定量因子各水平间的距离可以相等，
也可以不相等。这个三因子三水平的条件试验，通常有两种试验方法：

① 取三因子所有水平之间的组合，即A1B1C1，A1B1C2，A1B2C1，……，A3B3C3，共有33=27次试验。
用图5-7表示立方体的27个节点。这种试验法叫做全面试验法。

图5-7  全面试验法取点

全面试验对各因子与指标间的关系剖析得比较清楚。但试验次数太多。特别是当因子数目多，每个因子
的水平数目也很多时，试验量非常大。如选6个因子，每个因子取5个水平时，如欲做全面试验，则需5
6＝15625次试验，这实际上是不可能实现的。如果应用将要介绍的正交试验法，只做25次试验就行了。
而且在某种意义上讲，这25次试验代表了15625次试验。

② 简单对比法，即变化一个因素而固定其他因素，如首先固定B、C于Bl、Cl，使A变化：

   ↗A1

B1C1 →A2

   ↘A3（好结果）

如得出结果A3最好，则固定A于A3，C还是Cl，使B变化：

   ↗B1

A3C1 →B2 （好结果）

   ↘B3

得出结果以B2为最好，则固定B于B2，A于A3，使C变化：

   ↗C1

A3B2→C2 （好结果）

   ↘C3

试验结果以C2为最好。于是就认为最好的工艺条件是A3B2C2。

这种方法一般也有一定的效果，但缺点很多。首先这种方法的选点代表性很差，如按上述方法进行试验，
试验点完全分布在一个角上，而在一个很大的范围内没有选点，因此这种试验方法不全面，所选的工艺条
件A3B2C2不一定是27个组合中最好的。其次，用这种方法比较条件好坏时，是把单个的试验数据拿来，进

行数值上的简单比较，而试验数据中必然包含着误差成分，所以单个数据的简单比较不能剔除误差，必然
造成结论的不稳定。

简单对比法的最大优点就是试验次数少，例如，6因子5水平试验，在不重复时，只用5+（6–1）×（5–1）
＝5+5×4＝25次试验就可以了。

考虑兼顾这两种试验方法的优点，从全面试验的点中选择具有典型性、代表性的点，使试验点在试验范
围内分布得很均匀，能反映全面情况。但我们又希望试验点尽量地少，为此还要具体考虑一些问题。 如
上例，对应于A有Al、A2、A3 3个平面，对应于B、C也各有3个平面，共9个平面。则这9个平面上的试验
点都应当一样多，即对每个因子的每个水平都要同等看待。具体来说，每个平面上都有3行、3列，要求
在每行、每列上的点一样多。这样，作出如图5-8所示的设计，试验点用⊙表示。我们看到，在9个平面
中每个平面上都恰好有3个点，而每个平面的每行每列都有1个点，而且只有1个点，总共9个点。这样的
试验方案，试验点的分布很均匀，试验次数也不多。

当因子数和水平数都不太大时，尚可通过作图的办法来选择分布很均匀的试验点。但是因子数和水平数
多了，作图的方法就不行了。试验工作者在长期的工作中总结出一套办法，创造出所谓的正交表。按照
正交表来安排试验，既能使试验点分布得很均匀，又能减少试验次数，而且计算分析简单，能够清晰地
阐明试验条件与指标之间的关系。用正交表来安排试验及分析试验结果，这种方法叫正交试验设计法。

一般用L代表正交表，常用的有L8（27）、L9（34）、L16（45）、L8（4×24）等。此符号各数字的意
义如下。

例如：L8（27），其中，7为此表列的数目（最多可安排的因子数）；2为因子的水平数；8为此表行的数
目（试验次数）。

又例如：L18（2×37），有7列是3水平的，有1列是2水平的，L18（2×37）的数字告诉我们，用它来安
排试验，做18个试验最多可以考察1个2水平因子和7个3水平因子。

在行数为mn型的正交表中（m，n是正整数），试验次数（行数）＝（每列水平数–1）+l，如L8（27），
8＝7×（2–1）+l，利用上述关系式可以从所要考察的因子水平数来决定最低的试验次数，进而选择合适
的正交表。比如要考察5个3水平因子及一个2水平因子，则起码的试验次数为5×（3–1）+1×（2–1）+
1＝12（次），这就是说，要在行数不小于12，既有2水平列又有3水平列的正交表中选择，L18（2×37
）适合。正交表具有两条性质：每一列中各数字出现的次数都一样多；任何两列所构成的各有序数对出
现的次数都一样多。所以称之为正交表。

例如，在L9（34）中（如表5-7所示），各列中的l、2、3都各自出现3次；任何两列，例如第3、4列，
所构成的有序数对从上向下共有9种，既没有重复也没有遗漏。其他任何两列所构成的有序数对也是这9
种各出现一次。这反映了试验点分布的均匀性。

表5-7  L9（34）正交表

行    号列    号

1234

水    平

11111

21222

31333

42123

52231

62312

73132

83213

93321

试验方案应该如何设计呢？安排试验时，只要把所考察的每一个因子任意地对应于正交表的一列（一个
因子对应一列，不能让两个因子对应同一列），然后把每列的数字“翻译”成所对应因子的水平。这样，
每一行的各水平组合就构成了一个试验条件（不考虑没安排因子的列）。对于上例，因子A、B、C都是
3水平的，试验次数要不少于3×       （3–1）+1＝7（次），可考虑选用L9（34）。因子A、B、C可任
意地对应于L9（34）的某三列，例如A、B、C分别放在l、2、3列，然后试验按行进行，顺序不限，每一
行中各因素的水平组合就是每一次的试验条件，从上到下就是这个正交试验的方案，如表5-8所示。这个
试验方案的几何解释正好是正交试验设计图例。

3个3水平的因子，做全面试验需要33＝27次试验，现用L9（34）来设计试验方案，只要做9次，工作量
减少了2/3，而在一定意义上代表了27次试验。

2．正交试验测试用例设计步骤

利用正交试验设计测试用例的步骤如下。

 提取功能说明，构造因子“——”状态表。把影响实验指标的条件称为因子，而影响实验因子的条件叫
做因子的状态。利用正交试验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影
响其功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当做状态。对软件需求规
格说明中的功能要求进行划分，把整体的、概要性的功能要求进行层层分解与展开，分解成具体的、有
相对独立性的基本的功能要求。这样就可以把被测试软件中所有的因子都确定下来，并为确定因子的权
值提供参考的依据。确定因子与状态是设计测试用例的关键。因此，要求尽可能全面地、正确地确定取
值，以确保测试用例的设计做到完整与有效。

 加权筛选，生成因素分析表。对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态
作用的大小、出现频率的大小以及测试的需要，确定权值的大小。

 利用正交表构造测试数据集，正交表的推导依据Galois理论。

利用正交试验设计方法设计测试用例，与使用等价类划分、边界值分析、因果图等方法相比，有以下优
点：节省测试工作工时；可控制生成的测试用例的数量；测试用例具有一定的覆盖率。

正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，我们要选择哪种组合方式是最
好的，每个参数可能就是一个因子，参数的不同取值就是水平，这样我们可以采用正交试验法设计出最
少的测试组合，达到有效的测试目的。

2.8  功能图法

一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静
态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，因此，
仅用静态说明组成的规格说明对于测试来说往往是不够的，必须用动态说明来补充功能说明。

1．功能图设计方法

功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态
迁移图和逻辑功能模型构成。

 状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定
输出数据和后续状态。

 逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态
说明，输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输
入/输出数据满足的一对条件组成。

Mario洁

功能图方法实际上是一种黑盒、白盒混合用例设计方法。

功能图方法中要用到逻辑覆盖和路径测试的概念和方法，属白盒测试方法中的内容。逻辑覆盖是以程序内
部的逻辑结构为基础的测试用例设计方法，该方法要求测试人员对程序的逻辑结构有清楚的了解。由于覆
盖测试的目标不同，逻辑覆盖可分为：语句覆盖、判定覆盖、判定-条件覆盖，条件组合覆盖及路径覆盖。
下面我们指的逻辑覆盖和路径是功能或系统水平上的，以区别于白盒测试中的程序内部的，如图5-9及表
5-9所示。

图5-9  功能图

表5-9  判  定  表

输  入口令＝记录YNN

错输入＝3次NYN

输  出M2—

M3—

M4—

消去卡—

续表

状  态S1—

S2—

S3—

2．功能图法生成测试用例

功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述一个状态，指出数据输入的位置（
或时间），而迁移则指明状态的改变，同时要依靠判定表和因果图表示的逻辑功能。

采用什么样的方法生成测试用例？从功能图生成测试用例，得到的测试用例数是可接受的。问题的关键是
如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，状态迁移图就可转化成一个程

序的控制流程图形式。问题就转化为程序的路径测试问题（白盒测试范畴概念）了。

测试用例生成规则：为了把状态迁移（测试路径）的测试用例与逻辑模型的测试用例组合起来，从功能图
生成实用的测试用例，需定义下面的规则。一个结构化的状态迁移中，定义3种形式的循环：顺序、选择和
重复。但分辨一个状态迁移中的所有循环是有困难的。

从功能图生成测试用例的过程如下。

 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试库由原因值（输入数据）组
合与对应的结果值（输出数据或状态）构成。

 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径。

 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是视状态到最后状态的一个
状态序列，以及每个状态中输入数据与对应输出数据组合。

 测试用例的合成算法：采用条件构造树。

2.9  场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触
发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描
绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

提出这种测试思想的是Rational公司，并在RUP2000中文版中有详尽的解释和应用。

用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。

1．基本流和备选流

如图5-10所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的
最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后
重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再
重新加入到某个流（如备选流2和4）。

按照如图5-10中所示的每个经过用例的路径，可以确定以下不同的用例场景。

场景1：基本流；

场景2：基本流、备选流1；

场景3：基本流、备选流1、备选流2；

场景4：基本流、备选流3；

场景5：基本流、备选流3、备选流1；

场景6：基本流、备选流3、备选流1、备选流2；

场景7：基本流、备选流4；

场景8：基本流、备选流3、备选流4。

注：为方便起见，场景5、6和8只考虑了备选流 3循环执行一次的情况。

需要说明的是，为了能清晰地说明场景，我们所举的例子都非常简单，在实际应用中，测试用例很少如此简单。

2．ATM例子

（1）例子描述

如图5-11所示是ATM例子的流程示意图。

   图5-10  基本流和备选流图

   5-11  ATM流程示意图

如表5-10所示，包含了如图5-11中所示提款用例的基本流和某些备用流。

表5-10  用  例  流

基本流本用例的开始是ATM处于准备就绪状态

准备提款：客户将银行卡插入ATM机的读卡机

验证银行卡：ATM机从银行卡的磁条中读取账户代码，并检查它是否属于可以接收的银行卡

输入PIN：ATM要求客户输入PIN码（4位）验证账户代码和PIN，验证账户代码和PIN，以确定该账户是否有效
以及所输入的PIN对该账户来说是否正确。对于此事件流，账户是有效的，而且PIN对此账户来说正确无误

ATM选项：ATM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”

输入金额：要从ATM中提取的金额。对于此事件流，客户需选择预设的金额（10元、20元、50元或100元）。

授权ATM通过将卡ID、PIN、金额以及账户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，
银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新账户余额

出钞：提供现金

返回银行卡：银行卡被返还

收据：打印收据并提供给客户。ATM还相应地更新内部记录

用例结束时ATM又回到准备就绪状态

备选流1——银行卡无效在基本流步骤2中验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息

备选流2——ATM内没有现金在基本流步骤5中ATM选项，选项将无法使用。如果ATM内没有现金，则“提款
”选项不可用

备选流3——ATM内现金不足在基本流步骤6中输入金额，如果ATM机内金额少于请求提取的金额，则将显
示一则适当的消息，并且在步骤6输入金额处重新加入基本流

备选流4——PIN有误在基本流步骤4中验证账户和PIN，客户有三次机会输入PIN。如果PIN输入有误，ATM
将显示适当的消息；如果还存在输入机会，则此事件流在步骤3输入PIN处重新加入基本流。如果最后一次
尝试输入的PIN码仍然错误，则该卡将被ATM机保留，同时ATM返回到准备就绪状态，本用例终止

备选流5——账户不存在在基本流步骤4中验证账户和PIN，如果银行系统返回的代码表明找不到该账户或禁
止从该账户中提款，则ATM显示适当的消息并且在步骤9返回银行卡处重新加入基本流

续表

备选流6——账面金额不足在基本流步骤7授权中，银行系统返回代码表明账户余额少于在基本流步骤6输入
金额内输入的金额，则ATM显示适当的消息并且在步骤6输入金额处重新加入基本流

备选流7——达到每日最大的提款金额在基本流步骤7授权中，银行系统返回的代码表明包括本提款请求在
内，客户已经或将超过在24小时内允许提取的最多金额，则ATM显示适当的消息并在步骤6输入金额上重新
加入基本流

备选流x——记录错误如果在基本流步骤10收据中，记录无法更新，则ATM进入“安全模式”，在此模式下
所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明ATM已经暂停工作

备选流y——退出客户可随时决定终止交易（退出）。交易终止，银行卡随之退出

备选流z——“翘起”ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压
器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且ATM进入“安全
模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施

第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了
下面的事件流：

基本流——提取预设金额（10元、20元、50元、100元）

备选流2——ATM内没有现金

备选流3——ATM内现金不足

备选流4——PIN有误

备选流5——账户不存在/账户类型有误

备选流6——账面金额不足

（2）场景设计

如表5-11所示是生成的场景。

表5-11  场 景 设 计

场 景 描 述基  本  流备  选  流

场景1——成功的提款基本流

场景2——ATM内没有现金基本流备选流2

场景3——ATM内现金不足基本流备选流3

场景4——PIN有误（还有输入机会）基本流备选流4

场景5——PIN有误（不再有输入机会）基本流备选流4

场景6——账户不存在/账户类型有误基本流备选流

场景7——账户余额不足基本流备选流

注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入表中。

（3）用例设计

对于这7个场景中的每一个场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。如表
5-12所示是一种通用格式，其中行代表各个测试用例，列代表测试用例的信息。本例中的测试用例包含测
试用例ID、场景/条件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的
数据元素，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中，V表示
这个条件必须是有效的才可执行基本流，I表示这种条件下将激活所需备选流 ，n/a表示这个条件不适用于
测试用例。

表5-12  测试用例表

TC（测试用例）ID号场景/条件PIN账号输入（或选择）的金额账面金额ATM内的金额预期结果

CW1场景1——成功的提款VVVVV成功的提款

CW2场景2——ATM内没有现金VVVVI提款选项不可用，用例结束

CW3场景3——ATM内现金不足VVVVI警告消息，返回基本流步骤6-输入金额

CW4场景4 ——PIN有误（还有不止一次输入机会）IVn/aVV警告消息，返回基本流步骤4，输入PIN

CW5场景4——PIN有误（还有一次输入机会）IVn/aVV警告消息，返回基本流步骤4，输入PIN

CW6场景4——PIN有误（不再有输入机会）IVn/aVV警告消息，卡予保留，用例结束

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1被称为正面测试用例。它
一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有
在符合条件的情况下才执行基本流。这些负面测试用例由CW2～CW6表示。虽然CW2～CW6相对于基本流
而言都是负面测试用例，但它们相对于备选流2～4而言是正面测试用例。而且对于这些备选流中的每一个而
言，至少存在一个负面测试用例，就是CW1-基本流。

每个场景只有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场
景4-PIN有误，至少需要三个正面测试用例，以激活场景4：

① 输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤        3-输入PIN。

② 输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

③ 最后一次输入时输入了“正确”的 PIN。备选流在步骤5-输入金额处重新加入基本流。

注意，在上面的矩阵中，无需为条件输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易
看到测试的是什么条件。由于只需要查看 V和 I，这种方式还易于判断是否已经确定了充足的测试用例。从表
5-12中可发现存在几个无效的条件I，这表明测试用例还不完全，如场景6-不存在的账户/账户类型有误和场
景7-账户余额不足就缺少测试用例。

（4）数据设计

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的
测试用例。

表5-13  测试数据表

TC（测试用例）ID号场景/条件PIN账号输入的金额（或选择的金额）账面

金额（元）

Mario洁

ATM内的金额（元）预期结果

CW1场景1——成功的提款4987809-49850.00500.002 000成功的提款。账户余额被更新为450.00

CW2场景2——ATM内没有现金4987809-498100.00500.000.00提款选项不可用，用例结束

CW3场景3——ATM内现金不足4987809-498100.00500.0070.00警告消息，返回基本流步骤6输入金额

CW4场景4——PIN有误（还有不止一次的输入机会）4978809-498n/a500.002 000警告消息，返回基本流
步骤4，输入PIN

CW5场景4——PIN有误（还有一次输入机会）4978809-498n/a500.002 000警告消息，返回基本流步骤4，
输入PIN

CW6场景4——PIN有误（不再有输入机会）4978809-498n/a500.002 000警告消息，卡予保留，用例结束

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括以下
内容。

场景6——账户不存在/账户类型有误：未找到账户或账户不可用；

场景6——账户不存在/账户类型有误：禁止从该账户中提款；

场景7——账户余额不足：请求的金额超出账面金额。

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

① 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）；

② 无法读卡（读卡机堵塞、脱机或出现故障）；

③ 账户已消户、冻结或由于其他方面原因而无法使用；

④ ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一种币值不足，而不是所有币
值都不足）；

⑤ 无法联系银行系统以获得认可；

⑥ 银行网络离线或交易过程中断电。

结论：所有从事软件测试和即将从事软件测试的人大都是从黑盒测试做起的，每种类型的软件有各自的特点，
每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，它能极大地
提高测试效率和测试覆盖度，认真掌握这些方法的原理，有效提高测试水平，积累更多的测试经验，这是
测试人员最宝贵的财富。

2.10  测试方法选择的综合策略

测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的
特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实
际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖度，这就需要认真掌握这些方法的
原理，积累更多的测试经验，以有效地提高测试水平。

以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。

① 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量
和提高测试效率最有效的方法。

② 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力
最强。

③ 可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。


④ 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足
够的测试用例。

⑤ 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。

⑥ 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

⑦ 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。

⑧ 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

3  测试用例的编写

3.1  测试用例计划的目的

仔细计划测试用例，是达成测试目标的必由之路。这样做的重要性体现如下。

即使在小型软件项目上，也可能有数千个测试用例。建立用例可能需要一些测试员经过几个月甚至几年的时
间。正确的计划会组织好用例，以便全体测试员和其他项目小组成员有效地审查和使用。

我们已经知道，在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复。
假如没有正确的计划，就不可能知道需要执行哪个测试用例，原有的测试是否得到重复。

有时我们需要回答整个项目期间的重要问题。例如，计划执行多少个测试用例；在软件最终版本上执行多少
个测试用例；多少个通过，多少个失败；有忽略的测试用例吗，等等。如果没有测试用例计划，就不能回答
这些问题。

在少数高风险行业中，软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件是
危险的。正确的测试用例计划和跟踪提供了一种证实测试的手段。

3.2  测试设计说明
大家知道，项目整体测试计划的级别非常高。它虽然把软件拆分为具体特性和可测试项，并将其分派到每个
测试员头上，但是它并没有指明如何对这些特性进行测试，可能仅仅对使用自动化测试还是黑盒测试或者白
盒测试有一些提示，但是并不会涉及如何使用以及在哪里使用这些工具。
为了更好地进行测试，我们需要为单个软件特性定义具体的测试方法，这就是测试设计说明。ANSI/IEEE 829
中对测试设计说明的解释是：测试设计说明就是在测试计划中提炼测试方法，要明确指出设计包含的特性以
及相关的测试用例和测试程序，并指定判断特性通过/失败的规则。
测试设计说明的目的是组织和描述针对具体特性需要进行的测试。然而，它并不给出具体的测试用例或者执
行测试的步骤。以下内容来自于ANSI/IEEE 829标准，应该作为测试设计说明的部分内容。
 标识符：用于引用和定位测试设计说明的惟一标识符。该说明还应该引用整个测试计划，还应该包含任何
其他计划或者说明的引用。
 要测试的特性：对测试设计说明所包含的软件特性的描述。例如“计算器程序的加法功能”、“写字板程序
中的字体大小选择和显示”、“QuickTime软件的视频卡配置测试”。该部分还将明确指出要间接测试的特性，
它通常作为主特性的辅助特性。例如，文件打开对话框的用户界面虽然不在测试设计说明中重点指出，但是
在测试读写功能的过程中要间接测试。
 方法：描述测试的通用方法。如果方法在测试计划中列出，就应该在此详细描述要使用的技术，并给出如
何验证测试结果的方法。例如，我们这样描述一种方法，开发一种测试工具，顺序读写不同大小的数据文件，
数据文件的数目和大小及包含的内容由程序员提供的示例来确定。用文件比较工具比较输出的文件和源文件，
如果相同，则认为通过；如果不同，则认为失败。
 测试用例信息：用于描述所引用的测试用例的相关信息。应该列出所选的等价区间，给出测试用例的引用
信息以及用于执行测试用例的测试程序说明。例如：“检查最大值  测试用例ID#15326”、“检查最小值  测试
用例ID#15327”，在这部分不定义实际测试用例。
 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。这种描述有可能非常简单和
明确，例如“通过是指当执行全部测试用例时没有发现软件缺陷”。也有可能不是非常明确，例如“失败是指10
%以上的测试用例没有通过”。
3.3  测试用例说明
如何记录和记载创建的测试用例？如果你已经开始进行一些软件测试了，就可能采用过一些用例描述格式。本
节讲解编写测试用例的有关内容，指出将要考虑的重点。
ANSI/IEEE 829标准称测试用例说明为编写用于输入输出的实际数值和预期结果，同时还明确指出，使用具体
测试用例产生的测试程序的限制。一个测试用例的编写可参考表5-14。
表5-14  测 试 用 例
编号：
编制人审定人时间
软件名称编号/版本
测试用例

Mario洁

用例编号
参考信息（参考的文档及章节号或功能项）：
输入说明（列出选用的输入项，覆盖正常、异常情况）：
输出说明（逐条与输入项对应，列出预期输出）：
环境要求（测试要求的软、硬件、网络要求）：
特殊规程要求：
用例间的依赖关系：
用例产生的测试程序限制：
测试用例应该解释要向软件发送什么值或者条件，以及预期结果。一个测试用例说明可以由多个测试用例说
明来引用，也可以引用多个测试程序。ANSI/IEEE 829标准还列出了一些应该包含在内的重要信息，如下所示。
 标识符：由测试设计过程说明和测试程序说明引用的惟一标识符。
 测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。如果测试设
计说明提到“计算器程序的加法功能”，那么测试用例说明就会相应地提到“加法运算的上限溢出处理”。它还要
指出引用的产品说明书或者测试用例所依据的其他设计文档。
 输入说明：该说明列举执行测试用例的所有输入内容或者条件。如果测试计算器程序，输入说明可能简单
到“1+1”。如果测试蜂窝电话交换软件，输入说明可能是成百上千种输入条件。如果测试基于文件的产品，输
入说明可能是文件名和内容的描述。
 输出说明：描述进行测试用例预期的结果。例如，1+1等于2吗？在蜂窝软件中上千个输出变量设置正确吗
？读取文件的全部内容和预想的一样吗？
 环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。
 特殊要求：描述执行测试必须的特殊要求。测试写字板程序也许不需要任何特殊条件，但是测试一些特殊
的软件（如核电站软件）就有特殊要求。
 用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。
如果按照这里推荐的文档格式，对于每一个测试用例至少都要写上一页的描述文字，数千个测试用例可能要形
成几千页文档。所以我们经常把ANSI/IEEE 829标准当作规范而不是标准使用（除非必须这样做，许多政府项
目和某些行业要求按照此规格编写测试用例，但是在大多数情况下可以采用简便方法）。
采用简便方法并不是说放弃或者忽视重要的信息，而是意在找出一个更有效的方法对这些信息进行精简，例如，
没有必要刻意要求不能用书面段落形式表述测试用例。如表5-15给出了一个打印机兼容性简单列表的例子。
表5-15  打印机兼容性简单列表
测试用例序列号型  号模  式黑  白选  项
WP0001CanonBJC-7000黑白文字
WP0002CanonBJC-7000黑白超级照片
WP0003CanonBJC-7000黑白自动
WP0004CanonBJC-7000黑白草稿
WP0005CanonBJC-7000彩色文字
WP0006CanonBJC-7000彩色超级照片
WP0007CanonBJC-7000彩色自动
WP0008CanonBJC-7000彩色草稿
WP0009HPLaserJet Ⅳ高
WP0010HPLaserJet Ⅳ中
WP0011HPLaserJet Ⅳ低
表中的每一行是一个测试用例，有自己的标识符。伴随测试用例的所有其他信息，例如测试项、输入说明、输
出说明、环境要求、特殊要求和依赖性等对所有这些用例都必须有，可以一并编写，附加到表格中。审查测试
用例的人可以快速看完测试用例信息，然后审查表格，检查其范围。
表述测试用例的其他选择有大纲、状态表或数据流程图等方式。
3.4  测试程序说明
编写完测试设计和测试用例之后，就要说明执行测试用例的程序。什么是测试程序呢？ANSI/IEEE 829标准把测
试程序定义为“明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤”。
测试程序，有时也叫“测试脚本说明”，详细定义了执行测试用例的每一步操作。以下是需要定义的内容。
 标识符：用来把测试程序与相关测试用例和测试设计相联系的惟一标识。
 目的：本程序描述的目的以及将要执行的测试用例的引用信息。
 特殊要求：执行测试所需的其他程序、特殊测试技术或者特殊设备。
 程序步骤：执行测试用例的详细描述。它包含以下内容。
① 日志：指出用什么方法记录测试结果和现象。
② 设置：说明如何准备测试。
③ 启动：说明启动测试的步骤。
④ 程序：描述运行测试的步骤。
⑤ 衡量标准：描述如何判断结果。
⑥ 关闭：描述因意外原因而推迟测试的步骤。
⑦ 终止：描述正常停止测试的步骤。
⑧ 重置：说明如何把环境恢复到测试前的状态。
⑨ 偶然事件：说明如何处理计划之外的情况。
如果我们把测试程序只理解成“尝试执行所有的测试用例并报告发现的问题”是不够的。这虽然简单、容易，但
是无法告诉新加入的测试员如何进行测试，不能重复而且无法证明哪些步骤执行了。使用详细的程序说明，则
把要测试什么、如何测试等问题都表述得一目了然。如图5-12所示是“Windows计算器”的测试程序说明的例子
片断。

俗话说“做什么都要适可而止”，测试用例计划也一样。测试用例计划包括四个目标，即组织性、重复性、跟踪
和测试证实。开发测试用例的软件测试工程师要力争实现这些目标，但是其实现程度取决于行业、公司、项目
和测试组的具体情况，通常也不太可能按照最细致的程度去编写测试用例。
我们设计的测试用例计划要力求达到最佳的详细程度，比如，在一个测试程序中要求在PC机上安装Windows 2
000来执行测试，测试程序在其设置部分声明需要      Windows 2000，但是未声明Windows 2000的哪个版本。
那么一两年内出现新版本会怎样？测试程序需要升级来反映这个变化吗？为了避免这个问题，可以省略具体的
版本，而用“可用的最新版本”这样的说明来替代。
无比详细的测试用例说明减少了测试的随意性，使测试可以很好地重复，使得无经验的测试人员按照测试用例
说明也能执行测试。但是编写如此细致的测试用例说明要花费相当多的时间和精力，并且由于细节繁多，也会
阻滞测试工作，造成测试执行时间变长
。
开始编写测试用例时，最好是采用当前项目的标准，同时需要根据ANSI/IEEE 829标准定义的格式，看什么符合
项目要求，并可以做适当的调整。
不同的测试工程师设计的测试用例也会有所不同。通常有经验的测试工程师设计出来的测试用例，在深度及广
度上会比经验少的测试工程师的完整，这也是所谓的测试经验值。举例来讲，客户反应前一版V1.3的软件在W
indows 98的环境下运行时，在屏幕保护程序激活后会产生问题，开发工程师将这问题解决并且已提交修正版
本供客户网络下载，并且目前开发工程师所开发的软件最新版本为V1.5版，软件测试工程师就必须在V1.5版的
测试用例内，加入屏幕保护程序激活测试用例，甚至将这个用例增加至其他的测试平台。