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

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

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

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

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