测试数据管理框架

　　Sven Borghers和Wim Demey都有进30年的测试经验。近期，他们都在比利时CTG公司担任测试顾问，帮助顾客处理他们的测试难题。他们最近在CTG实验室开发测试数据管理框架。

　　Sven Borghers是一名测试顾问，在测试所有方面都经验丰富。他对多次不同的测试执行，测试分析，缺陷管理，测试协调。测试数据管理，测试流程改进，实施测试方法做出了贡献。除了他的顾问工作，因为他的经验和真实的生活实例，他也是一名极受尊敬的培训师和导师。Sven 也是STBoX（基于经验的软件测试）——CTG的已证测试方法的推动者。

　　Wim Demey是一名多才的测试顾问，带着学习新事物的雄心担任过各种角色。这使得Wim纵览全局地去执行，正如与客户及项目团队探讨（技术）细节的最低水平。这些年，他一直是国内国际会议/研讨会上的发言人，还在国际测试杂志上写文章。他还创立了博客：infrastructuretesting.wordpress.com。

　　如果所有的测试员都有一个共同的难题，那大概就是管理他们的测试数据了。无论你在测试中扮演什么角色或你是哪种类型的测试员，要使得你的测试数据正确还蛮难的。已经做过不少不同领域的项目，我们总结：没有一个单独的解决方案可以管理测试数据。事实上，甚至没有这样一个单独的测试数据管理问题。理由很简单：测试数据应该要满足你的（基于你的业务，规章，结构及可用环境等因素的）特定测试需求。所以，从测试数据管理的角度，没有哪两个情况是一样的。

　　你该如何管理测试数据？
　　测试是在压力下进行的，因为迭代开发模型被更频繁地使用，且改变的时间一直在减短。结果，让你的测试数据恰当的可用时间也在压力之下，于是对恰当测试数据管理的需求不断在增加。另一方面，我们注意到在我们的日常工作中，越来越多的公司开始寻找方法解决他们的测试数据管理问题。但是，另一方面，我们又不得不意识到，接受这一挑战时，我们并没有什么可做的。我们不能求助于一个覆盖测试数据管理所有方面的文件程序。我们也不能使用一个测试数据管理工具应对测试数据管理的所有方面。这是不可能的，因为这种流程或工具不存在。顶多现存流程和工具只覆盖一些测试数据管理问题。那么，下一个题就是：“如何缩小这个差距？”我们能创建一个仪器来把测试数据管理作为一个整体来解决而不论准确情况吗？或者换句话说，我们能创建一个对实际帮助我们解决测试数据管理问题来说足够具体且同时被应用于任意（测试）项目的工具吗？
　　我们已经确定，寻找一个通用的解决方案并不可取。于是我们就想到或者我们不应该一开始就找解决方案，而应该试着把重点放在该如何更好地理解手边的测试数据管理问题。理想情况下，加强了理解，最后就可以想出一个按部就班的设计并实施既定测试数据管理问题的解决方案的方法。
　　创建一个测试数据管理框架的想法诞生了。因为该框架并不明确限定于任何特定的测试数据管理解决方案，所以它应该适用于任何给定情况。

　　测试数据管理框架详解
　　测试数据管理框架需要包含两大部分。一部分记录一个开发组织对测试数据管理的需求，另一部分创建一幅满足那些需求的测试数据管理实践的路线图。图1列出了测试数据管理框架的要素。

图1. 测试数据管理框架详解

　　测试数据管理框架的第一部分叫做需求框架。它由测试数据管理的一系列要求组成，且能让你证明并引出一个组织的需要用来管理测试数据的准确需求。测试数据管理框架的第二部分被称为提升周期。它由一个周期的按部就班的用以设计并实施测试数据管理提升的方法组成。框架的两部分紧密合作。需求框架允许你决定目前的测试数据管理实践及偏好，提升周期允许你去设计并实施可以导致期待情况的测试数据管理提升。或者，反之亦然，当引入了测试数据管理提升，需求框架就可以对所实现的提升结果进行评估。
　　更具体点儿，测试数据管理框架包含三个子框架。
　　 ?需求框架明确区分测试数据本身的实际需求及实际管理测试数据的需求。这就生成两个子框架。
　　 ?测试数据需求子框架专注于测试数据的特性。它以一种测试数据应该是怎么样的通用方法表现。相对地，测试数据管理需求子框架再一次以一种通用方法专注于测试数据该如何管理。
　　 ?最后，测试数据管理提升周期子框架要看一个组织该怎样决定其当前测试数据管理实践，其期待（将来）测试数据管理实践，及一个线路图的。接下来，我们详细说说每一个子框架吧。

　　借用“销售渠道”说明
　　我们将借用一个假定的“销售渠道”应用来说明测试数据管理框架，考虑以下假设：
　　 ?客户驻留在一个SQL2008R2数据库，机会和员工驻留在一个Oracle11g数据库。

图2. “销售渠道应用”的数据模型

　　?生产表中当前记录的数量
　　 ?客户：1000
　　 ?机会：6700
　　 ?员工：60
　　 ?过去测试“销售渠道”会导致客户数据隐私的重大问题，结果，管理决定当所有客户数据从生产环境中选择并被加入任何开发或测试环境中时必须被隐藏。

　　测试数据需求
　　测试数据需求子框架注重测试数据本身的特性。它包括另外四个解释适当测试数据应该遵循的需求的子框架，需求框架简单列出了一些基本使用于（测试）项目且是测试数据需求子框架重点的通用测试数据需求。通用测试数据需求为评估一个组织的测试数据需求提供指导。一些需求或许不适用于某特定情况。如果是这样，那么它们很容易被忽视。如果不是，，它们就应该由将要设计的测试数据管理解决方案来实现。定义框架，质量框架和规章框架分别提供现存不同种类测试数据及测试数据应该遵循的质量与规章标准的更深入的信息。它们提供解释需求框架中通用测试数据需求所需的背景信息。

图3. 测试数据需求子框架

　　测试数据管理是个复杂的任务且当试着满足测试数据需求时可以想出许多不同的测试数据策略。制定一个关于与手头（测试）项目相关的每个（测试）数据需求的单独测试数据策略大概太耗时了。因此，我们希望能够为更大的（测试）数据组选择测试数据策略。这样我们就需要一个机制来定义可以以同样方式对待的（测试）数据组。定义框架或测试数据分类系统提供了这个机制且是建立在以下三方面上的：
　　 ?测试数据特性（例如测试数据类型，生产相似性，一致性，统一性，数量）
　　 ?测试目标（组件测试，系统测试，验收测试）
　　 ?测试环境（DTAP模式）

　　借用“销售渠道”说明
　　对于一个单元测试，开发人员只需要一些来自每个表格的记录（比如：10名员工，100次机会，100名客户）以充分覆盖代码。但是对于测试性能，环境必须是类似生产的，这意味着在一个专门环境中照搬所有表格。对验收测试业务，测试数据（如：外国客户，不同状态下的机会（打开的/关闭的），不同国家的员工）中包含所有不同种类的情况也很重要。无论哪个测试环境，有一致的测试数据意味着你不能只选一个表格获取数据的。在我们的例子里，客户和员工都与机会相关联，所以所有这些表格中的记录都要被挑选。最后，在每个（测试）项目里建立测试数据是一项很重要的活动。没有恰当的测试数据，就无法执行一个单独的测试用例。
　　但是接下来又有问题了。什么是恰当的测试数据？什么时候我们用的测试数据质量够了？质量框架来回答。框架里，当测试数据满足以下需求时，我们觉得测试数据适合测试目的（且是高质量的）：
　　 ?测试数据符合适用于你公司内的通用数据质量属性（如：准确性，完整性，可达性等）
　　 ?测试数据覆盖测试需求
　　 ?测试数据反映真实生活数据
　　每个公司都要处理他们以安全方式处理的数据。根据法律，个人数据必须受到保护而不被无意使用，被认为机密的非个人数据不该泄漏出去。无论这个责任最初目的是什么（国际立法或仅仅是出于自身利益），公司受到的来自暴露出去的敏感数据的伤害都相当大。规章框架解答了该如何管理测试数据（和测试环境）以满足相关测试数据安全需求。理想情况是，该政策可以成为公司安全政策，测试政策或质量政策的一部分。

　　借用“销售渠道”说明
　　可以用三种方法按要求隐藏客户数据：
　　 ?搞乱基于模式的公司名（比如用Ｘ或Ｙ代替特性）
　　 ?用不乱但虚构的数据（如John Tester， Teststreet 10 in 1000 Testland）替代敏感数据
　　 ?在像东大街一样的地方加入任意数量
　　 ?基于计算程序用自己的数据代替现存数量

　　测试数据管理需求
　　测试数据管理需求子框架解释该如何管理测试数据。其结构与测试数据需求子框架很相似。它也包含四个子框架。需求框架相似地列出了一些通用测试数据管理需求。流程框架，组织框架和基础设施框架各自提供关于专门用于测试数据管理背景的典型管理方面（流程，人，技术）的更深入信息。他们提供解释需求框架中通用测试数据管理需求所需的背景信息。

图4.　测试数据管理需求子框架

　　管理你的测试数据是必须包含在你的整个测试流程中。因此流程框架简化了这整个流程及在其之中执行的不同测试活动的测试数据生命周期（定义，建立，使用，净化等）。从管理的角度，这可以确保测试数据管理活动在恰当的时间执行。包含测试数据也可以让你更轻松地定义关于测试数据管理活动的恰当职责。组织框架放大了这些职责。框架内，开发出了组织测试数据管理职责的不同方法。有不同的组织类型，范围从每个负责自己测试数据的测试员到一个提供测试数据服务的中心测试数据单元。基础设施框架专注于你测试数据管理活动的技术方面。它概述了有哪些测试数据管理工具以及它们如何支持你。基础设施框架内，一个测试数据管理工具的定义被很广泛地使用。不仅专门的测试数据管理工具，用于测试数据管理设置的测试自动化工具还有其他可以有所帮助的工具在这儿都可以被考虑。

　　借用“销售渠道”说明
　　为了在恰当的时间准备测试环境，包含一个模板的测试策略中加了一段。测试经理不得不用他的特定测试数据需求来完成这个模块。DBA团队全权负责创建子集并将它们操纵调动到如模块所示的环境中。此外，无论需求是否与已被呈现在环境和/或其他测试数据需求中的数据冲突，DBA都会检查。增加了这一步，测试数据准备更高效了。

　　测试数据管理提升周期
　　测试数据管理提升周期子框架评估当前测试数据管理实践以基于线路图设计将来的实践。子框架定义一个包含留个六个连续步骤的重要周期。每一个提升周期都要过一遍这六个步骤且第一步都是“生成意识”。这是测试数据管理提升的一个通用方法，比如它只说采用什么步骤但实际上不告诉你要提升什么。

图5. 测试数据管理提升周期子框架

　　1.生成意识
　　这个步骤就是识别并定义测试数据管理提升的机会。提升测试数据管理实践的需求应该让所有的利益相关者一目了然。利益相关者也应该同意测试数据管理框架作为使用的参考模型。

　　2.评估当前测试数据管理实践
　　通过使用测试数据管理框架作为一个参考模型分析当前测试数据管理实践。这就决定了当前实践的优缺点，确定的缺点的原因是被研究了，并与测试流程提升中确定的机会相关联。

　　3.定义将来的测试数据管理提升
　　该步骤主要是决定测试数据管理实践将来想达到的的状态。提升目标被设定，实现提升目标的解决方案也被制定了。

　　4.定义提升线路图
　　实现这些目标并实施前一步中所确定的解决方案的一个策略已设计好了。资源定好了，行动计划也制定好了。

　　5.实施
　　现在提升线路图已被执行。确定的提升和解决方案已被实施。测试人员受过培训，试点项目已正式拉开序幕。简而言之，新测试数据管理实践已开始投入使用且固定在公司企业中。

　　6.评估
　　最后但并非最不重要，评估已实现的提升。目标是否被实现，实施的解决方案是否进行地不错都被证明了。如果利益相关者对结果很满意，那么测试数据管理提升在这里可以停止了，否则就可以在测试数据管理提升周期中制定一个新的途径。评估步骤的结果就被用来生成新想法。

　　借用“销售渠道”说明
　　多个测试人员在相同的环境中测试时，存在使用彼此测试数据的风险。也就是说，必须建能影响/推迟测试执行的额外测试数据。这点可以通过采用一些规则避免并改善。
　　 ?添加测试员首字母作为测试数据的前缀（例：雇员），这样谁可以使用这个测试数据就一目了然。
　　 ?分开不同测试员可使用的测试数据（例：所有英国顾客数据由测试员A使用，所有荷兰顾客数据由测试员B使用）
　　 ?选择并提取所有所要求测试数据的额外份额（例：10%）以保存。

　　总结
　　测试数据管理框架给任一愿意处理测试数据管理问题的测试专家或项目经理提供帮助。不要死盯着一个（我们觉得无法发现的）通用的测试数据管理解决办法，测试数据管理框架提供方法理解一个组织的测试数据管理需求并设计和实施这些需求的正确解决方案。由于框架的目标不是找出一个通用解决方法，所以框架可以被广泛用于帮助参与测试数据管理的任何人。

　　注意点
　　 [1]这个数据模式是基于MS Access 2010中的样本模板。
　　 [2]测试数据策略：你管理（加入测试数据到测试环境，整合测试数据以便下回使用，从测试环境中移除测试数据，维护测试数据）测试数据以便满足这些测试数据的需求。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。