指南： 测试用例

测试用例	测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

主题

• 解释
• 从用例中生成测试用例
• 从补充规约中生成测试用例

  • 为性能测试生成测试用例
  • 为安全性/访问控制测试生成测试用例
  • 为配置测试生成测试用例
  • 为安装测试生成测试用例
  • 为其他非功能性测试生成测试用例

• 为单元测试生成测试用例

• 白盒测试
• 黑盒测试

• 为产品验收测试生成测试用例
• 为回归测试编制测试用例

解释

要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

确定测试用例之所以很重要，原因有以下几方面。

• 测试用例构成了设计和制定测试过程的基础。
• 测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
• 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。
• 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
• 测试设计和开发的类型以及所需的资源主要都受控于测试用例。

测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：

• 一个测试用例用于证明该需求已经满足，通常称作正面测试用例；
• 另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

从用例中生成测试用例

用于功能性测试的测试用例来源于测试目标的用例（请参见工件：用例）。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。  

例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。 基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。

用例的事件流示例

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景： 

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

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

例如，假定上图描述的用例对备选流 3 规定如下：

“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。”

据此，可以开始确定需要用来执行备选流 3 的测试用例：

注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。 

下面是一个由用例生成测试用例的更符合实际情况的示例。

示例：

一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流：

可以从这个用例生成下列场景

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

对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。 例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

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

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

• 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。
• 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
• 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

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

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。有关详细信息，请参见检查点： 测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据（关于测试数据的详细信息，请参见指南： 测试数据）。

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

• 场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用
• 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款
• 场景 7 - 帐户余额不足：请求的金额超出帐面金额

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

• 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
• 无法读卡（读卡机堵塞、脱机或出现故障）
• 帐户已消户、冻结或由于其他方面原因而无法使用
• ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）
• 无法联系银行系统以获得认可
• 银行网络离线或交易过程中断电

在确定功能性测试用例时，确保满足下列条件：

• 已经为每个用例场景确定了充足的正面和负面测试用例。 
• 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。
• 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。
• 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。

关于测试数据的其他信息，另请参见指南：测试数据。

从补充规约中生成测试用例

并不是所有的测试目标需求都将在用例中有所反映。 非功能性需求（如性能、安全性和访问控制）以及配置要求等将会说明测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。

关于如何生成这些其他测试用例的指南说明如下：

• 为性能测试生成测试用例
• 为安全性/访问控制测试生成测试用例
• 为配置测试生成测试用例
• 为安装测试生成测试用例
• 为其他非功能性测试生成测试用例

为性能测试生成测试用例

性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见工件： 补充规约）。为性能测试生成测试用例时，请使用下列指南：

• 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。
• 对每个关键用例，都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工件：工作量分析文档）。

与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例，还有一个测试用例高于阈值。

除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：

• 数据库的大小 - 存在多少个记录？
• 工作量 - 同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和类型
• 环境特征（硬件、网件以及软件配置）

将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。

关于测试数据的其他信息，另请参见指南：测试数据。

以下是各种性能测试的一些示例：

对于负载测试：

对于强度测试：

为安全性/访问控制测试生成测试用例

主角和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定主角生成测试结果。复杂系统包含许多主角，所以我们编制测试用例时必须确保只有指定执行用例的主角可以进行此操作，这一点非常关键。在基于主角类型的用例事件流存在差别时，尤其如此。

例如，在 ATM 用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个 ATM 机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该 ATM 不支持的银行卡，则将对该主角“银行客户”执行不同的用例事件流。

对于功能性测试用例，请同样遵循上面列举的指南。

关于测试数据的其他信息，另请参见指南：测试数据。

关于安全性和访问控制测试用例的示例：

为配置测试生成测试用例

在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合。为了核实测试目标在不同的配置情况下（如不同的操作系统、浏览器或 CPU 的速度）能否正常工作或执行，应该对此进行测试。此外，测试还应涵盖构件的组合，以便检测在不同构件的交互中产生的缺陷。例如，确保由应用程序安装的 DDL 版本不会与另一个应用程序需要的相同 DDL 的版本发生冲突。

采用下列指南来生成用于配置测试的测试用例：

• 确保对每个关键配置，应至少存在一个测试用例可用于对其进行确定。这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。应确保最先测试最常见的配置，包括：
  • 打印机支持
  • 网络连接 - 局域网和广域网
  • 服务器配置 - 服务器驱动程序、服务器硬件
  • 台式机和/或服务器上安装的其他软件
  • 所有已安装软件的软件版本
• 确保对于每个可能有问题的配置至少存在一个测试用例。这些配置可能包括：
  • 具有最低性能的硬件。
  • 历史上存在兼容性问题的共驻内存的软件。
  • 通过最慢的 LAN/WAN 连接访问服务器的客户机。
  • 资源不足（缓慢的 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。

有关其他信息，请参见指南：单元测试。

黑盒测试

黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下，对指定行为进行验证。 黑盒测试侧重并依赖于单元的输入和输出。

等价类划分是一种用来减少所需测试数量的技术。对于每一个操作都应确定参数和对象状态的等价类。等价类是一组值的集合，对这组值来说，对象的行为应类似。例如，一个集合可有三个等价类：空、若干元素以及满。

可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行黑盒测试的同时应进行可靠性测试。

接下来的两个小节说明了如何通过选择特定参数的测试数据来确定测试用例。

基于输入参数的测试用例

输入参数是由某个操作使用的参数。对于以下每个输入条件，都应通过使用每个操作的输入参数来编制测试用例： 

• 每个等价类的正常值。
• 每个等价类的边界值。
• 等价类之外的值。
• 非法值。

请记住要将对象状态视作输入参数。例如：如果在对集合这个对象测试添加操作，您必须使用集合内所有等价类的值来测试添加操作。所有等价类的值指的是：充满元素的集合、有若干元素的集合、以及空集合。

基于输出参数的测试用例

输出参数是某个操作所改变的参数。 某个参数既可以是输入参数也可以是输出参数。根据以下每个条件选择输入，以便获得输出。

• 每个等价类的正常值。
• 每个等价类的边界值。
• 等价类之外的值。
• 非法值。

请记住将对象状态视为输出参数。例如，假设您对某个列表测试删除操作，您必须选择输入值以便执行操作之后，列表为充满状态、具有若干元素或为空（采用它的所有等价类的值进行测试）。

如果对象受状态控制（根据对象的状态产生不同的反应），您应利用状态矩阵，如下图所示：

用于测试的状态矩阵。您可以在此矩阵的基础上测试激励和状态的所有组合。

有关其他信息，请参见指南：单元测试。

为产品验收测试生成测试用例

产品验收测试是部署软件前的最后测试操作。验收测试的目标在于核实软件是否已经准备就绪，而且可以由最终用户按软件设计来执行功能和任务。产品验收测试通常不仅涉及执行软件以确认其是否准备就绪，还涉及交付给客户的所有产品工件，如培训、文档和包装。 

为软件工件生成测试用例是按上文中说明的方式实现的。测试用例可与上面确定的测试用例（正式）或某个子集（非正式）相同或类似，这取决于产品验收测试的正式程度。不管测试用例的深度如何，应该在实施和执行产品测试之前对测试用例和产品验收计划达成共识。

对非软件工件的评估将随着被评估工件的不同而相去甚远。请参见每个特定非软件工件的指南以及核对清单，查看这些工件的评估内容和评估方式。

为回归测试编制测试用例

回归测试比较同一测试目标的两个工作版本或版本，并将差异确定为潜在缺陷。据此可假定：新版本应该象早先版本一样操作，并确保并未因为版本的变化而带来缺陷。

理想状态下，您可能希望一次迭代内的所有测试用例都能在后续迭代内使用。应遵照下列指导原则来确定、设计并实施测试用例，这些测试用例可以最大限度地发挥回归测试和复用的价值，同时将维护的成本减至最低：

• 确保测试用例只确定关键的数据元素（创建/支持被测试的条件所需的数据元素）
• 确保每个测试用例都说明或代表一个唯一的输入集或事件序列，其结果是独特的测试目标行为
• 消除多余或等效的测试用例
• 将具有相同的测试目标初始状态和测试数据状态的测试用例组合到一起

Rational Unified Process