指南：测试用例

指南：测试用例
测试用例
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试
某个程序路径或核实是否满足某个特定需求。
主题
解释
 从用例中生成测试用例
 从补充规约中生成测试用例
o 为性能测试生成测试用例
o 为安全性/访问控制测试生成测试用例
o 为配置测试生成测试用例
o 为安装测试生成测试用例
o 为其他非功能性测试生成测试用例
 为单元测试生成测试用例
 白盒测试
 黑盒测试
 为产品验收测试生成测试用例
 为回归测试编制测试用例
解释
要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐
述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。
然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行
软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来
实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率
和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或
最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该
需求进行核实的必要性这三者权衡考虑的结果。
确定测试用例之所以很重要，原因有以下几方面。
 测试用例构成了设计和制定测试过程的基础。
 测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件
或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就
越有信心。
 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施
和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已
得以执行和验证”，远比“我们已完成95 % 的测试”更有意义。
 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地
估计测试周期各连续阶段的时间安排。
 测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型
和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：
 一个测试用例用于证明该需求已经满足，通常称作正面测试用例；
 另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所
需条件下才能够满足该需求，这个测试用例称作负面测试用例。
从用例中生成测试用例
用于功能性测试的测试用例来源于测试目标的用例（请参见工件：用例）。应该
为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这
个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表
示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流
开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中
（备选流1 和3），还可能起源于另一个备选流（备选流2），或者终止用例
而不再重新加入某个流（备选流2 和4）。
用例的事件流示例
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，
再将基本流和备选流结合起来，可以确定以下用例场景：
场景1 基本流
场景2 基本流备选流1
场景3 基本流备选流1 备选流2
场景4 基本流备选流3
场景5 基本流备选流3 备选流1
场景6 基本流备选流3 备选流1 备选流2
场景7 基本流备选流4
场景8 基本流备选流3 备选流4
注：为方便起见，场景5、6 和8 只描述了备选流3 指示的循环执行一次的情
况。
生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导
致特定用例场景的执行。
例如，假定上图描述的用例对备选流3 规定如下：
“如果在上述步骤2‘输入提款金额’中输入的美元量超出当前帐户余额，则出
现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步
骤2‘输入提款金额’，此时银行客户可以输入新的提款金额。”
据此，可以开始确定需要用来执行备选流3 的测试用例：
测试用例
ID
场景条件预
期 结果
TC x 场景4 步骤2 - 提款金额> 帐户余额在
步 骤 2 处 重
新 加入 基 本 流
TC y 场景4 步骤2 - 提款金额< 帐户余额不
执 行备 选 流
3，
执 行基 本 流 TC z 场景4 步骤2 - 提款金额= 帐户余额不
执 行备 选 流
3，
执 行基 本 流
注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如
此简单。
下面是一个由用例生成测试用例的更符合实际情况的示例
示例：
一台ATM 机器的主角和用例。
下表包含了上图中提款用例的基本流和某些备用流：
基本流本用例的开端是ATM 处于准备就绪状态。
1. 准备提款- 客户将银行卡插入ATM 机的读卡机。
2. 验证银行卡- ATM 机从银行卡的磁条中读取帐户代
码，并检查它是否属于可以接收的银行卡。
3. 输入PIN - ATM 要求客户输入PIN 码（4 位）
4. 验证帐户代码和PIN - 验证帐户代码和PIN 以确定
该帐户是否有效以及所输入的PIN 对该帐户来说是否
正确。对于此事件流，帐户是有效的而且PIN 对此帐
户来说正确无误。
5. ATM 选项- ATM 显示在本机上可用的各种选项。在
此事件流中，银行客户通常选择“提款”。
6. 输入金额- 要从ATM 中提取的金额。对于此事件流，
客户需选择预设的金额（10 美元、20 美元、50 美元
或100 美元）。
7. 授权- ATM 通过将卡ID、PIN、金额以及帐户信息作
为一笔交易发送给银行系统来启动验证过程。对于此事
件流，银行系统处于联机状态，而且对授权请求给予答
复，批准完成提款过程，并且据此更新帐户余额。
8. 出钞- 提供现金。
9. 返回银行卡- 银行卡被返还。
10. 收据- 打印收据并提供给客户。ATM 还相应地更新内
部记录。
用例结束时ATM 又回到准备就绪状态。
备选流1 -
银行卡无效
在基本流步骤2 中- 验证银行卡，如果卡是无效的，则卡被
退回，同时会通知相关消息。
备选流2 - 在基本流步骤5 中- ATM 选项，如果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 - 帐面金额不足
可以从这个用例生成下列场景
场景1 - 成功的提款基本流
场景2 - ATM 内没有现
金
基本流备选流2
场景3 - ATM 内现金不
足
基本流备选流3
场景4 - PIN 有误（还有
输入机会）
基本流备选流4
场景5 - PIN 有误（不再
有输入机会）
基本流备选流4
场景6 - 帐户不存在/帐
户类型有误
基本流备选流5
场景7 - 帐户余额不足基本流备选流6
注：为方便起见，备选流3 和6（场景3 和7）内的循环以及循环组合未纳入
上表。
对于这7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表
来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，
而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用
例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存
在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，
至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，
V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无
效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）
表明这个条件不适用于测试用例。
TC
（测
试用
例）
ID
号
场景/条件PIN
帐号
输入的
金额
（或
选择
的金
帐面金
额
ATM
内的金
额
预期结果
额）
CW1. 场景1 - 成
功的提款
V V V V V 成功的提
款。
CW2. 场景2 -
ATM 内没
有现金
V V V V I 提款选项不
可用，用例
结束
CW3. 场景3 -
ATM 内现
金不足
V V V V I 警告消息，
返回基本流
步骤6 - 输
入金额
CW4. 场景4 - PIN
有误（还有
不止一次输
入机会）
I
V n/aV V 警告消息，
返回基本流
步骤4，输
入PIN
CW5. 场景4 - PIN
有误（还有
一次输入机
会）
I
V n/aV V 警告消息，
返回基本流
步骤4，输
入PIN
CW6. 场景4 - PIN
有误（不再
有输入机
会）
I
V n/aV V 警告消息，
卡予保留，
用例结束
在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1
称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本
流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基
本流。这些负面测试用例由CW2 至6 表示（阴影单元格表明这种条件下需要执
行备选流）。虽然CW2 至6 对于基本流而言都是负面测试用例，但它们相对于
备选流2 至4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至
少存在一个负面测试用例（CW1 - 基本流）。
每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4 正是这
样的一个示例。要全面地测试场景4 - PIN 有误，至少需要三个正面测试用例
（以激活场景4）：
 输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3 - 输
入PIN。
 输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
 最后一次输入时输入了“正确”的PIN。备选流在步骤5 - 输入金额处重新加入基本
流。
注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建
测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V
和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的
测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还
不完全，如场景6 - 不存在的帐户/帐户类型有误和场景7 - 帐户余额不足就
缺少测试用例。
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适
度，并取消多余或等效的测试用例。有关详细信息，请参见检查点：测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定
测试数据（关于测试数据的详细信息，请参见指南：测试数据）。
TC
（测
试用
例）
ID
号
场景/条件PIN
帐号
输入的
金额
（或
选择
的金
额）
帐面金
额
ATM
内的金
额
预期结果
CW1. 场景1 - 成
功的提款
4987 809 -
498
50.00 500.00 2,000 成功的提
款。帐户余
额被更新
为450.00
CW2. 场景2 -
ATM 内没
有现金
4987 809 -
498
100.00 500.00 0.00 提款选项
不可用，用
例结束
CW3. 场景3 -
ATM 内现
金不足
4987 809 -
498
100.00 500.00 70.00 警告消息，
返回基本
流步骤6 -
输入金额
CW4. 场景4 -
PIN 有误
（还有不止
一次输入机
会）
4978
809 -
498
n/a500.00 2,000 警告消息，
返回基本
流步骤4，
输入PIN
CW5. 场景4 -
PIN 有误
（还有一次
输入机会）
4978
809 -
498
n/a500.00 2,000 警告消息，
返回基本
流步骤4，
输入PIN
CW6. 场景4 - 4978 809 - n/a500.00 2,000 警告消息，
PIN 有误
（不再有输
入机会）
498 卡予保留，
用例结束
以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要
的其他测试用例包括：
 场景6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用
 场景6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款
 场景7 - 帐户余额不足：请求的金额超出帐面金额
在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
 无法读卡（读卡机堵塞、脱机或出现故障）
 帐户已消户、冻结或由于其他方面原因而无法使用
 ATM 内的现金不足或不能提供所请求的金额（与CW3 不同，在CW3 中只是一
种币值不足，而不是所有币值都不足）
 无法联系银行系统以获得认可
 银行网络离线或交易过程中断电
在确定功能性测试用例时，确保满足下列条件：
 已经为每个用例场景确定了充足的正面和负面测试用例。
 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、
外部还是在边界条件/值上都存在测试用例。
 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还
应能处理用户界面对象状态或条件。
 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊
需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。
关于测试数据的其他信息，另请参见指南：测试数据。
从补充规约中生成测试用例
并不是所有的测试目标需求都将在用例中有所反映。非功能性需求（如性能、安
全性和访问控制）以及配置要求等将会说明测试目标的其他行为或特征。补充规
约是为其他行为生成测试用例的主要来源。
关于如何生成这些其他测试用例的指南说明如下：
 为性能测试生成测试用例
 为安全性/访问控制测试生成测试用例
 为配置测试生成测试用例
 为安装测试生成测试用例
 为其他非功能性测试生成测试用例
为性能测试生成测试用例
性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见
工件：补充规约）。为性能测试生成测试用例时，请使用下列指南：
 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能
标准通常表示为时间/事务、事务量/用户或百分数的形式。
 对每个关键用例，都应确保至少要确定一个测试用例。关键用例是在上述说明中和/
或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工件：工
作量分析文档）。
与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试
用例。常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测
试用例，还有一个测试用例高于阈值。
除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：
 数据库的大小- 存在多少个记录？
 工作量- 同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和
类型
 环境特征（硬件、网件以及软件配置）
将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。
关于测试数据的其他信息，另请参见指南：测试数据。
以下是各种性能测试的一些示例：
对于负载测试：
TC（测
试用
例）ID
号
工作量条件
预期结果
PCW1. 1
（单个ATM）
完成提款交易全部交易（不依
赖于主角的时
间）在20 秒之
内完成
PCW2. 2
（1,000 个同时运
行的ATM）
完成提款交易全部交易（不依
赖于主角的时
间）在30 秒之
内完成
PCW3. 3
（10.000 个同时
运行的ATM）
完成提款交易全部交易（不依
赖于主角的时
间）在50 秒之
内完成
对于强度测试：
TC（测
试用
例）ID
号
工作量条件
预期结果
SCW1. 2
（1,000 个同时运
行的ATM）
数据库锁定- 2 个
ATM 请求同一帐户
ATM 请求排成
队列
SCW2. 2
（1,000 个同时运
行的ATM）
无法实现银行系统
的通信
交易排成队列或
超时
SCW3. 2
（1,000 个同时运
行的ATM）
在交易过程中，银行
系统通信被终止
显示警告消息
为安全性/访问控制测试生成测试用例
主角和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定
主角生成测试结果。复杂系统包含许多主角，所以我们编制测试用例时必须确保
只有指定执行用例的主角可以进行此操作，这一点非常关键。在基于主角类型的
用例事件流存在差别时，尤其如此。
例如，在ATM 用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个ATM
机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该ATM 不支持
的银行卡，则将对该主角“银行客户”执行不同的用例事件流。
对于功能性测试用例，请同样遵循上面列举的指南。
关于测试数据的其他信息，另请参见指南：测试数据。
关于安全性和访问控制测试用例的示例：
TC（测
试用
例）ID
号
条件卡
（V 表明卡
有效）
读卡机
（V 表明读
卡机工作正
常）
银行的网
络
预期结果
ACW1. 在银行网
络之内
V V V 所有用例都可
用
ACW2. 银行网络
之外
V V I 只有提款用例
可用
ACW3. 无法读卡I V V 警告消息，卡被
退出
ACW4. 因被盗，卡
已挂失
I V V 警告消息，卡予
保留
ACW5. 卡已过期I V V 警告消息，卡予
保留
为配置测试生成测试用例
在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合。为了核实测
试目标在不同的配置情况下（如不同的操作系统、浏览器或CPU 的速度）能否
正常工作或执行，应该对此进行测试。此外，测试还应涵盖构件的组合，以便检
测在不同构件的交互中产生的缺陷。例如，确保由应用程序安装的DDL 版本不
会与另一个应用程序需要的相同DDL 的版本发生冲突。
采用下列指南来生成用于配置测试的测试用例：
 确保对每个关键配置，应至少存在一个测试用例可用于对其进行确定。这是通过确
定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。应确
保最先测试最常见的配置，包括：
o 打印机支持
o 网络连接- 局域网和广域网
o 服务器配置- 服务器驱动程序、服务器硬件
o 台式机和/或服务器上安装的其他软件
o 所有已安装软件的软件版本
 确保对于每个可能有问题的配置至少存在一个测试用例。这些配置可能包括：
o 具有最低性能的硬件。
o 历史上存在兼容性问题的共驻内存的软件。
o 通过最慢的LAN/WAN 连接访问服务器的客户机。
o 资源不足（缓慢的CPU 速度、最小的内存或分辨率，磁盘空间不足等等）
为安装测试生成测试用例
安装测试需要核实测试目标可以在所有可能的安装情况下安装。安装情况可以指
首次安装测试目标，或是在装有较早版本的机器上安装测试目标的某个较新的版
本或工作版本。安装测试还应确保在遇到异常情况时（如磁盘空间不足），测试
目标的执行情况仍可接受。
测试用例应包含以下各种软件的安装情况：
 分发介质，例如磁盘、CD-ROM 或文件服务器。
 首次安装。
 完全安装。
 自定义安装。
 升级安装。
客户机服务器软件的安装程序具备一组特定的测试用例。不同于基于主机的系
统，服务器和客户机上的安装程序是有所不同的。因而，安装测试应执行构成测
试目标的所有构件的安装，包括客户机、中间层以及服务器，这一点至关重要。
为其他非功能性测试生成测试用例
理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工
件的测试用例。不过，如果此时您需要补充已有的输入，那也不足为奇。
示例如下：
 操作测试（用以检验在某次故障发生后以及在下一次故障发生前“较长时间”内软件
的运行情况）的测试用例。
 对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例。
大多数情况下，您可以通过先前所确定的测试用例生成的某些测试用例来构建其
变体或聚合关系体，借此来查找测试用例。
为单元测试生成测试用例
单元测试要求既测试单元的内部结构同时还要测试其行为特征。测试内部结构要
求了解实施单元的方式，基于这种了解的测试被称为白盒测试。对单元行为特征
的测试侧重于从外部可观察的单元行为，而不需要了解或考虑其实施方式。基于
这种方法的测试称为黑盒测试。基于这两种方法所生成的测试用例的说明如下。
白盒测试
理论上，应通过代码测试每一条可能的路径。在所有这些非常简单的单元内实现
这样的目标是不切实际或几乎是不可能的。作为最基本的测试，应将每个决定到
决定路径（DD 路径）测试至少一次，这样可确保将所有语句至少执行一次。决
定通常是指if 语句，而DD 路径是两个决定之间的路径。
要达到这种程度的测试覆盖，建议您在选择测试数据时应使每个决定都可以用每
种可能的方法来评估。为达到上述目标，测试用例应确保：
 每个布尔表达式的求值结果为true和false。例如，表达式(a<3) OR (b>4) 的求值
结果为true/false的四种组合
 每一个无限循环至少要执行零次、一次和一次以上。
可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行白盒测试的同时应
进行可靠性测试。
示例：
假设您对类Set of Integers 中的member 函数执行结构测试。该测
试在二进制搜索的帮助下，将检查该集合是否包含了某个指定的整数。
成员(member) 函数以及相应的流程图。虚线箭头指示出如何通过采用两个测
试用例将所有语句至少执行一次。
理论上，对于彻底测试的某个操作，测试用例应遍历代码内路径的所有组合情况。
在member 函数的while-loop 中存在三个可选择的路径。测试用例可以多次遍
历该循环，或是根本就不遍历。如果测试用例根本就没有遍历循环，则在代码中
只能找到一条路径。如果遍历循环一次，您将发现有三条路径。如果遍历两次，
则您将发现存在六条路径，如此类推。因而，路径的总数应该是：
1+3+6+12+24+48+...，在实际情况中，这个路径组合总数根本无法无法处理。这
就是为什么必须选择所有这些路径的子集的原因。本示例中，可以采用两个测试
用例来执行所有的语句。其中一个测试用例中，您可以选择Set of Integers =
{1,5,7,8,11}，而且测试数据t = 3。在另一个测试用例中，您可以选择Set of
Integers = {1,5,7,8,11}，且t = 8。
有关其他信息，请参见指南：单元测试。
黑盒测试
黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下，对指定行为
进行验证。黑盒测试侧重并依赖于单元的输入和输出。
等价类划分是一种用来减少所需测试数量的技术。对于每一个操作都应确定参数
和对象状态的等价类。等价类是一组值的集合，对这组值来说，对象的行为应类
似。例如，一个集合可有三个等价类：空、若干元素以及满。
可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行黑盒测试的同时应
进行可靠性测试。
接下来的两个小节说明了如何通过选择特定参数的测试数据来确定测试用例。
基于输入参数的测试用例
输入参数是由某个操作使用的参数。对于以下每个输入条件，都应通过使用每个
操作的输入参数来编制测试用例：
 每个等价类的正常值。
 每个等价类的边界值。
 等价类之外的值。
 非法值。
请记住要将对象状态视作输入参数。例如：如果在对集合这个对象测试添加操作，
您必须使用集合内所有等价类的值来测试添加操作。所有等价类的值指的是：充
满元素的集合、有若干元素的集合、以及空集合。
基于输出参数的测试用例
输出参数是某个操作所改变的参数。某个参数既可以是输入参数也可以是输出参
数。根据以下每个条件选择输入，以便获得输出。
 每个等价类的正常值。
 每个等价类的边界值。
 等价类之外的值。
 非法值。
请记住将对象状态视为输出参数。例如，假设您对某个列表测试删除操作，您必
须选择输入值以便执行操作之后，列表为充满状态、具有若干元素或为空（采用
它的所有等价类的值进行测试）。
如果对象受状态控制（根据对象的状态产生不同的反应），您应利用状态矩阵，
如下图所示：
用于测试的状态矩阵。您可以在此矩阵的基础上测试激励和状态的所有组合。
有关其他信息，请参见指南：单元测试。
为产品验收测试生成测试用例
产品验收测试是部署软件前的最后测试操作。验收测试的目标在于核实软件是否
已经准备就绪，而且可以由最终用户按软件设计来执行功能和任务。产品验收测
试通常不仅涉及执行软件以确认其是否准备就绪，还涉及交付给客户的所有产品
工件，如培训、文档和包装。
为软件工件生成测试用例是按上文中说明的方式实现的。测试用例可与上面确定
的测试用例（正式）或某个子集（非正式）相同或类似，这取决于产品验收测试
的正式程度。不管测试用例的深度如何，应该在实施和执行产品测试之前对测试
用例和产品验收计划达成共识。
对非软件工件的评估将随着被评估工件的不同而相去甚远。请参见每个特定非软
件工件的指南以及核对清单，查看这些工件的评估内容和评估方式。
为回归测试编制测试用例
回归测试比较同一测试目标的两个工作版本或版本，并将差异确定为潜在缺陷。
据此可假定：新版本应该象早先版本一样操作，并确保并未因为版本的变化而带
来缺陷。
理想状态下，您可能希望一次迭代内的所有测试用例都能在后续迭代内使用。应
遵照下列指导原则来确定、设计并实施测试用例，这些测试用例可以最大限度地
发挥回归测试和复用的价值，同时将维护的成本减至最低：
 确保测试用例只确定关键的数据元素（创建/支持被测试的条件所需的数据元素）
 确保每个测试用例都说明或代表一个唯一的输入集或事件序列，其结果是独特的测
试目标行为
 消除多余或等效的测试用例
 将具有相同的测试目标初始状态和测试数据状态的测试用例组合到一起。