在测试设计任务中,确定并描述了两个重要的工件:测试脚本和测试用例。没有测试数据,就无法实施并执行这两个工件。如果没有具体的值对它们进行简要地标识,那么它们就仅仅是条件、场景和路径的描述。测试数据(虽然本身没有工件)对测试的成功与否有着显著的影响。没有测试数据,就无法实施和执行测试,因为测试数据对于以下几种情况是必需的:
-
作为创建条件的输入信息
-
作为评估需求的输出信息
-
作为支持(测试的前置条件)
因此,确定这些值是一项重要的工作,并且这项工作应在确定“测试用例”后完成(请参阅工作产品:测试用例和指南:测试用例)。
确定实际的测试数据时,应处理测试数据的四种属性:
-
深度 - 测试数据的数据量
-
宽度 - 测试数据的变化程度
-
范围 - 测试数据与测试对象的关联
-
体系结构 - 测试数据的物理结构
在下面的各章节中,对这些特征进行了更为详细的论述:
深度是指测试中使用的数据量。深度是一个重要的注意事项,因为数据过少可能无法反映现实情况,而数据过多则难以管理和维护。理想情况下,测试应从支持关键测试用例(通常是正测试用例)的一小组数据开始。随着测试过程中可信度的增加,测试数据也应增加,直到数据深度可代表所部署的环境(或合适并可行的情况)为止。
宽度指的是测试数据的变化程度。只需通过创建更多的记录即可增加测试数据的深度。尽管这经常是个很好的解决方案,但它并不解决我们期望在实际数据中所看到的真实数据变化。如果测试数据没有这些变化,我们可能无法确定缺陷(毕竟,不是每次都从 ATM
机中取出 50 美元)。因此,测试数据应反映在所部署的环境中发现的数据值,例如提款 10 美元或 120 美元。此外,测试数据应反映现实的信息,例如:
-
名称,包括标题、数字值、标点符号和后缀:
-
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 号
(整数)
|
帐户余额
(十进制数)
|
帐户类型
(字符串)
|
(S) 0812 0000 0000 至
0812 9999 9999
© 0829 0000 0000 至
0829 9999 9999
(X) 0799 0000 0000 至
0799 9999 9999
|
0000 至 9999
|
-999,999.99 至 999,999.99
|
S、C、X
|
记录 1
|
0812 0837 0293
|
8493
|
-3,123.84
|
S
|
记录 2
|
0812 6493 8355
|
3558
|
8,438.53
|
S
|
记录 3
|
0829 7483 0462
|
0352
|
673.00
|
C
|
记录 4
|
0799 4896 1893
|
4896
|
493,498.49
|
X
|
上面的矩阵包含了将实际地代表可接受数据值的记录的最小数目。就帐号而言,这三个范围各有一条记录,所有的 PIN
号均在指定的范围内,且存在几个不同的帐户余额(其中一个为负)以及对应每个不同帐户类型的记录。以上矩阵为最低限度的数据,而最佳实践将使用每个范围的极限数据值,以及该范围内的数据值(请参阅指南:测试用例)。
实际表示的优点在于:测试数据在大小方面有所限制,是可管理的,其重点(也是目标)是可接受的值。但缺点在于:现实的实际数据并不是完全随机的。 真实数据往往含有可能影响绩效的统计概要信息,使用实际表示时是观察不到这一点的。
测试数据统计性表示是指反映生产数据的抽样统计(相同的百分比)的测试数据。例如,使用上述的相同数据元素,如果我们分析了生产数据库并发现了以下情况:
-
记录的总数:294,031
-
帐户类型 S 的总数:141,135(总数的 48%)
-
帐户类型 C 的总数:144,075(总数的 49%)
-
帐户类型 X 的总数:8,821(总数的 3%)
-
账号和 PIN 号是平均分发的
基于统计抽样的测试数据将包括 294 条记录(与我们在上面提到的四条相比较):
|
测试数据(为生产的 0.1%)
|
记录的数目
|
百分比
|
记录的总数
|
294
|
100
|
账号
(S) 0812 0000 0000 至
0812 9999 9999
|
141
|
48
|
账号
© 0829 0000 0000 至
0829 9999 9999
|
144
|
49
|
账号
(X) 0799 0000 0000 至
0799 9999 9999
|
9
|
3
|
上面的矩阵仅针对了帐户类型。在逐步获取基于统计性表示的最佳测试数据的过程中,应包括重要的数据元素。在上例中,将包括反映实际帐户余额的数据元素。
统计性表示的缺点在于可能无法反映可接受值的完整范围。
确定测试数据的两种方法通常都用于确保测试数据涉及了所有的值和绩效/人数问题。
测试数据的宽度与作为输入信息和用于支持测试(在预先存在的数据中)的测试数据相关。
范围是测试数据与测试目标的关联,它与深度和宽度相关。大量数据并不意味着它们是合适的数据。就测试数据宽度而言,我们必须确保测试数据与测试目标相关,即,存在支持特定测试目标的测试数据。
例如,在下面的矩阵中,前四条测试数据记录说明了每个数据元素的可接受值。 但对于帐户类型 C 和
X,却没有任何记录的值为负余额。因此,尽管这些测试数据恰当地含有负余额(有效宽度),但下面的数据的范围却不足以支持使用每一帐户类型的负帐户余额所进行的任何测试。扩展这些数据以包括其他的记录,其中每个不同帐户类型的负余额对于处理这种疏忽是很有必要的。
|
账号(范围)
|
PIN 号
(整数)
|
帐户余额
(十进制数)
|
帐户类型
(字符串)
|
(S) 0812 0000 0000 至
0812 9999 9999
© 0829 0000 0000 至
0829 9999 9999
(X) 0799 0000 0000 至
0799 9999 9999
|
0000 至 9999
|
-999,999.99 至 999,999.99
|
S、C、X
|
记录 1
|
0812 0837 0293
|
8493
|
-3,123.84
|
S
|
记录 2
|
0812 6493 8355
|
3558
|
8,438.53
|
S
|
记录 3
|
0829 7483 0462
|
0352
|
673.00
|
C
|
记录 4
|
0799 4896 1893
|
4896
|
493,498.49
|
X
|
新记录 1
|
0829 3491 4927
|
0352
|
-995,498.34
|
C
|
新记录 2
|
0799 6578 9436
|
4896
|
-64,913.87
|
X
|
测试数据的范围与作为输入信息和用于支持测试(在预先存在的数据中)的测试数据相关。
测试数据的实际结构仅与测试目标用于支持测试的任何预先存在的数据(例如某一应用程序的数据库或规则表)相关。
测试并不是执行一次就完成的。测试是在迭代内和迭代之间重复进行的。为了一致、可信和高效地执行测试,测试数据必须回到测试执行之前的初始状态。当要使测试自动化时,尤其要做到这一点。
因此,为了确保测试的完整性、可信性和高效性,使测试数据不受任何外部影响,且其状态在测试执行开始时、过程中以及结束时都为人所知,这是至关重要的。为了实现该测试目标,必须处理两个问题:
这两个问题都将影响您管理测试数据库、设计测试模型以及与其他角色交互的方式。
测试数据可能会变得不稳定,这有以下原因:
-
与测试不相关的外部影响修改了数据
-
其他测试人员不知道哪些数据由其他人使用
要维护测试的可信性和完整性,应高度控制测试数据并将其与这些影响隔离。确保测试数据被隔离的策略包括:
-
实际地将测试环境(测试人员有自己的测试环境)与其他环境分开。测试人员不共享任何信息,即,他们有自己的测试目标和数据。如果(举例)每个测试人员都有自己的 PC,就可实现这一点。
-
使基于测试数据的实例(测试人员有自己的数据实例)避免所有其他影响。实际环境(可能甚至测试目标)是共享的,但由于每个测试人员都有自己的数据实例,所以损坏测试数据的风险极小。
-
测试数据/数据库划分 - 所有测试人员共享数据库且知道别人在使用的数据(避免使用其他测试人员的数据)。例如,某个测试人员可能使用记录 0 至 99,另一测试人员可能使用记录 100 至 199;或者某人使用以 Aa 至 Kz
开头的姓氏的客户,而另一测试人员使用以 La 至 Zz 开头的姓氏的患者。
必须处理的另一测试数据体系结构问题是测试数据在测试执行开始时的初始状态。当使用测试自动化时,尤其如此。就像测试目标必须在已知的、期望的状态下开始执行测试一样,测试数据也必须如此。这有助于使每个测试执行的可重复性和可信性均保持一致。
通常使用四种策略来处理这个问题:
每种策略都在下面有更为详细的描述。
使用的方法将取决于几个因素,包括数据库的实际特征、测试人员的技术能力、外部(非测试)角色的可用性和测试目标。
让测试数据回到其初始状态的最理想方法是“数据刷新”。该方法涉及到创建初始状态数据库的副本以及存储该副本。在测试执行完成后(或在测试执行之前),将测试数据库的归档副本复制到测试环境中以供使用。这就确保测试数据的初始状态与每个测试执行开始时的状态相同。
该方法的优点在于,可以用几种不同的初始状态将数据归档。例如,测试数据可以用一天结束时的状态、周末状态或月末状态等归档。这将为测试人员提供快速将数据刷新为给定状态以支持测试(例如月末用例测试)的一种方法。
如果无法刷新数据,第二好的方法就是通过某种计划性方法将数据恢复到初始状态。数据重新初始化依靠特殊用例和工具使测试数据返回为其初始值。
必须小心确保所有的数据、关系和键值都返回到其相应的初始值,以确保不会将任何错误引入数据。
该方法的一个优点在于它可支持对数据库中的无效值进行测试。正常情况下,将拦截无效数据值,不允许输入到数据中(例如,按客户端的验证规则进行)。但其他参与者可能会影响数据(例如其他系统的电子更新)。测试需要验证:无论无效数据如何出现,都适当地予以确定并处理。
使数据返回到其初始状态的一个简单方法是“撤消”在测试过程中对数据所作的更改。 该方法使用测试目标来输入撤消项,即,添加已删除的记录/值,还原修改过的记录/值以及删除已添加的数据。
但是,该方法具有相关的风险,包括:
-
所有操作都必须撤消,而不只是一部分
-
依赖于测试目标中的用例(必须先进行测试以验证正确的功能,然后才能将这些用例用于数据重新设置)。
-
可能无法或不能重新设置数据库键、索引和指针
如果这是测试环境中唯一可用的方法,则应避免使用数据库键、索引和指针作为验证的主要目标。即,(举例)使用“患者姓名”字段,而不是使用系统生成的患者标识号来确定患者是否已添加到数据库中。
数据前滚是处理测试数据初始状态的最不理想方法。事实上,它并没有真正解决问题。相反,测试执行完成时的数据状态成为了新的测试数据初始状态。通常,这需要修改用于输入的测试数据和/或用于评估结果的测试用例和测试数据。
在某些情况下,该方法是有必要的,例如在月末。如果在月末之前没有归档数据,则必须执行每天和每周的测试数据和测试脚本,以使数据“前滚”至月末处理测试所需的状态。
该方法的相关风险包括:
-
不能重新设置数据库键、索引和指针(也不能用于验证)
-
数据在不断变化
-
需要额外的工作来验证结果
|