指南：测试数据

测试数据	测试数据是在测试中使用的实际值（集合）或执行测试需要的元素。测试数据创建要测试的条件（作为输入或预先存在的数据），并且用于核实特定的用例或需求是否已经成功得到实施（将实际结果和预期结果相比较）。

主题

• 解释
• 深度
• 宽度
• 范围
• 构架

解释

在测试设计活动中，需要确定和描述两个重要的工件：测试过程和测试用例。如果没有测试数据，这两个工件将无法实施和执行。它们只是对条件、场景和路径的一些说明，而没有具体的值用来简明地确定它们。测试数据虽然本身不是一个工件，但是它对测试的成败产生重要的影响。没有测试数据，将无法实施和执行测试，尤其当要求测试数据作为以下值时：

• 作为创建条件的输入
• 作为评估需求的输出结果
• 作为支持（作为测试的前置条件）

因此，确定这些值是一个重要的工作，并且这项工作在确定测试用例后完成。（请参阅工件： 测试用例和指南：测试用例）。

确定实际的测试数据时，必须说明处理测试数据的四个属性：

• 深度 - 测试数据中数据的容量或数量
• 宽度 - 测试数据中数据的变化程度
• 范围 - 测试数据与测试目标的相关性
• 构架 - 测试数据的物理结构

上述每个特征都将在以下部分进行更详细的说明：

深度

深度是在测试中所使用数据的容量或数量。深度是一个需要考虑的重要事项，因为数据太少可能无法反映现实生活的条件，而数据太多将难以管理和维护。理想条件下，测试应首先使用一个小的支持关键测试用例的数据集（通常为正面测试用例）。随着测试过程中信心不断增强，应该增加测试数据，直到数据深度完全体现出部署环境（或适当可行的范围）为止。

测试数据深度与用作输入和用于支持测试（在预先存在的数据中）的测试数据相关。

宽度

宽度是指测试数据值变化的程度。创建更多的记录就可以增加测试数据的深度。虽然这通常是一个好的解决方法，但是它无法解决我们期望在实际数据中看到的数据真实变化的问题。如果在测试数据中没有这些变化，我们可能无法确定缺陷（毕竟，不是每次从 ATM 提取的款项都是 50.00 美元）。因此，测试数据值应该反映在部署环境内找到的数据值，例如提取 10.00 美元或 120.00 美元。另外，测试数据应该反映现实世界的信息，例如：

• 包括头衔、数值、标点符号和后缀的名字：
  • Dr. James Bandlin、Ms. Susan Smith 和 Rev. Joseph P. Mayers
  • James Johnson III、Steven Wilshire 3rd 和 Charles James Ellsworth, Esq.
  • Ellen Jones-Smythe、Brian P. Tellstor
• 带有多地址行的地址，例如：
  • 6500 Broadway Street
    Suite 175
  • 1550 Broadway
    Floor 17
    Mailstop 75A
• 真实相符的城市代码（和国家代码）和电话号码
  • Lexington, MA, USA + 01 781 676 2400
  • Kista, Sweden +46 8 56 62 82 00
  • Paris, France +33 1 30 12 09 50

为获得足够的数据宽度，测试数据值既可以是物理方式表示的真实数据，也可以是统计方式表示的真实数据。这两种方法都具有使用价值，推荐使用它们。

为创建利用物理方法表示部署数据的测试数据，需要确定部署数据库中每个数据元素所允许包含的值（或范围），并确保在每个数据元素中，测试数据至少有一个记录包含每一个允许值。

例如：

以上矩阵包含了可以用物理方法表示可接受数据值的记录的最小数量。对于帐号，在以上三个范围中每一个范围都有一个记录，所有的 PIN 号都在指定的范围内，几个帐户余额各不相同，其中包括一个负余额，并且每一个不同的帐户类型都存在相关记录。以上矩阵对应最小的数据，最佳方案是使用每个范围界限上以及该范围内的数据值（请参见指南： 测试用例）。

物理表示法的一个优点是，测试数据在数量和可管理性上都有限制，重点及导向目标是可接受值。它的缺点是实际的、现实世界的数据并不是完全随机的。 真实数据往往具有可能影响性能的统计曲线，在采用物理表示法时将不会观察到这些特征。

统计测试数据表示法是指反映了生产数据（在相同百分比下）统计抽样的测试数据。例如，使用和以上相同的数据元素，如果我们分析该生产数据库，将发现以下事实：

• 总记录数：294,031个
• 帐户类型为 S 的总数：141,135 个（占全部数量的 48%）
• 帐户类型为 C 的总数：144,075 个(占全部数量的 49 %)
• 帐户类型为 X 的总数：8,821 个(占全部数量的 3%)
• 帐号和 PIN 号均匀分布

基于统计抽样的测试数据包括 294 个记录（与上面提到的四项相比较）：

以上矩阵只说明帐户类型。为了开发最佳的基于统计表示法的测试数据，您最好要将重要的数据元素包括在内。以上示例中，包括反映了实际帐户余额的重要数据元素。

统计表示法的一个缺点是可能无法反映可接受值的整个范围。

通常情况下，同时使用确定测试数据的两种方法，确保测试数据涵盖所有值并解决性能/填充问题。

测试数据宽度与用作输入的测试数据以及用于支持测试（在预先存在的数据中）的测试数据相关。

范围

范围是测试数据与测试目标之间的关联关系，它和测试深度和测试宽度相关。具有许多数据并不意味着其数据一定正确。与处理测试数据的宽度一样，我们必须确保测试数据和测试目标相关，也就是说，需要有支持特定测试目标的测试数据。

例如，在以下矩阵中，最初的四个测试数据记录说明了每个数据元素的可接受值。然而，用于评估帐户类型 C 和 X 负余额的记录却没有。因此，尽管该测试数据正确地包含了一个负余额（有效的宽度），以下的数据在其范围内不足以支持采用每个帐户类型的负余额进行的任何测试。扩展此数据以包括更多的记录，并将各个不同帐户类型的负余额包括在内，这些操作对于处理这类疏忽是很有必要的。

测试范围和用作输入的测试数据以及用于支持测试（在预先存在的数据中）的测试数据相关。

构架

测试数据的物理结构仅与测试目标用于支持测试的任何预先存在的数据相关，例如某个应用程序的数据库或规则表。

测试执行不是一劳永逸的。测试将需要在迭代中以及各个迭代之间重复执行。为统一、有效、有把握地执行测试，测试数据应在测试执行前返回其初始状态。在自动执行测试时，这一点尤其重要。

因此，为了确保测试的完整性、把握性和有效性，测试数据不受外部的任何影响，并且了解测试执行在开始、期间和结束阶段的状态，这两点异常重要。为了达到测试目标，必须处理两个问题：

• 不稳定性/隔离 - 隔绝测试数据的外部影响
• 初始状态 - 了解数据的特定初始状态以及返回此状态的能力

这两个问题都将影响您管理测试数据库、设计测试模型以及与其他角色交互的方式。

不稳定性/隔离

测试数据可能由于以下原因而变得不稳定：

• 外部的、与测试无关的影响修改了该数据
• 其他的测试角色不知道别人正在使用的数据

为维护测试的把握性和完整性，测试数据需要进行高度控制并与这些影响隔绝。确保测试数据被隔绝的策略包括：

• 分离测试环境 - 每个测试角色有自己的测试环境，在物理上和其他角色分离。测试员没有共享的内容，也就是说，他们有自己的测试目标和数据。例如，每个测试角色都有自己的个人计算机就可以实现此策略。
  
• 分离测试数据基础实例 - 每个测试角色有自己的数据实例，也就是说，它隔离了其他所有的影响。尽管物理环境，也许甚至还有测试目标都是共享的，但是每个测试员有自己的数据实例，这种情况下，测试数据干扰的风险几乎不存在。
  
• 测试数据/数据库分区 - 所有的测试角色共享一个数据库，而且知道其他角色正在使用的数据（避免使用其他角色的数据）。例如，一个测试员使用 0 到 99 的记录，而另一个测试员使用 100 到 199 的记录，或有人使用姓为 Aa 到 Kz 的客户记录，而另一个测试员使用名字从 La 到 Zz 的病人记录。

初始状态

必须解决的另一个测试数据构架问题是，在开始执行测试时测试数据的初始状态。当使用自动测试时，这个问题尤其重要。正如测试目标必须以一个已知、预期的状态来开始一个测试的执行过程，这个要求对于测试数据也是一样的。 由于每一测试执行过程与上一测试执行过程相同，所以这种做法可以提高可重复性和把握性。

以下是解决这一问题的四个常用策略：

• 数据更新
• 数据重新初始化
• 数据重置
• 数据前滚

以上各项都将在以下详细说明。

采用何种方法将取决于几个因素，包括数据库的物理特征、测试角色的技术能力、外部（非测试的）角色的可用性以及测试目标。

数据更新

将数据返回其初始状态的最理想的方法是数据更新。这个方法包括创建初始状态下该数据库的一个备份，并将其保存。在测试执行完成之后（或执行测试之前），将该测试数据库的存档副本复制到测试环境内使用。这确保了在每次测试执行开始时，测试数据初始状态都是一样的。

这种方法有一个优点，即数据能够以几个不同的初始状态进行存档。例如，测试数据可以按日末状态、周末状态、月末状态等等进行归档。这样，测试者就可以将测试数据快速刷新到给定状态，以便进行测试。例如月末用例的测试。

数据重新初始化

如果数据无法刷新，那么次佳的方法是通过一些编程手段，将数据恢复到它的初始状态。数据重新初始化依赖于特殊的用例和工具返回测试数据的初始值。

采用这一方法必须小心，保证所有的数据、关系以及关键值都返回到它们适当的初始值状态，以确保没有在数据中引入任何错误。

该方法的一个优点是它可以支持数据库内无效值的测试。在正常条件下，无效数据值将被俘获而不允许进入到数据中（例如利用客户机上的一个确认规则）。然而，另一个主角可能会影响该数据（例如，另一个系统的电子更新）。测试需要在独立于无效数据产生方式的基础上，验证无效数据是否得以确定并进行了适当的处理。

数据重置

将数据恢复到它的初始状态的一个简单方法是“撤消更改”，即撤消在测试期间对数据的更改。此方法依赖于使用测试目标来输入撤消条目，即添加被删除的记录/值、恢复被修改的记录/值以及删除已添加的数据。

然而，这种方法还存在有一些风险，包括：

• 必须撤消所有的操作，而不只是一部分
• 依赖于测试目标中的用例（这些用例在用于数据重置之前，必须进行测试以核实其正确的功能性）
• 数据库关键字、索引以及指针不可以或不能重置

如果这是在您的测试环境中唯一可用的方法，则避免使用数据库关键字、索引和指针作为核实的主要目标。 也就是，例如采用 Patient Name 字段来确定该病人是否已经添加到数据库中，而不是使用系统生成的 Patient ID 号。

数据前滚

数据前滚是最不理想的处理测试数据初始状态的方法。事实上，它并没有真正地解决问题。相反，数据状态在完成执行测试时将变成测试数据新的初始状态。一般情况下，这要求修改用于输入和（或）测试用例的测试数据以及用于评估结果的测试数据。

有时候必须采用这种做法。例如，月末。如果在月末之前该数据没有归档，则必须执行每一天和每个星期的测试数据和测试过程以将数据“前滚”到月末处理的测试所需的状态。

该方法具有的风险包括：

• 数据库关键字、索引和指针不能重置（且不能用于核实）
• 数据经常改变
• 需要更多的工作来证明结果的核实情况

© 1987 - 2001 Rational Software Corporation。版权所有。

Rational Unified Process