接上一篇
要求具备测试数据，以确保每个系统层次的需求都得以测试和验证。审查测试数据需求可以解决许多数据关注的事情，如下面所列举的，而且以手动方式进行这些审查都是不可行的。这就是自动化测试数据生成的回报。
深度
测试团队必须考虑为了支持测试所需的数据库记录的量或规模。他们需要确定一个数据库或特定表格中的10条记录是否足够，或是否有必要使用10 000条记录。在生命周期早期的测试，如单元测试或构建验证测试，应该使用手动创建的小数据库，这样可以提供最大的控制粒度和最小的干扰。在不同测试阶段和不同类型测试过程中，数据库应该增长到一定规模，以适合特定的测试。比如，当产品环境数据库会包含1 000 000条记录时，针对只包含100条记录的数据库进行性能及容量测试是没有意义的。
广度
测试工程师需要考察数据值的变体（比如，10 000个不同的账户和大量不同类型的账户）。设计良好的测试将包括各种测试数据的变体，而且对所有类似的数据进行的测试生成有限的结果。例如，测试时可能需要考虑账户余额为负的账户、余额非常低的（$100）、中等范围的（ $1 000）、大范围的（$100 000），以及非常大范围（$10 000 000）的账户。同时测试还应该反映平均水平的数据。对于银行账户来说，客户账户可以按不同方式归类，包括按储蓄、支票、贷款、学生、联名和商业。所有数据类别都需要考虑。
范围
测试团队需要调查数据的相关性。测试数据的范围与数据的准确性、相关性和完整性相关。比如，当测试用于确定各种类型的银行账户的查询（根据账户余额是否多于100美元）时，不仅要考虑到满足这一标准的账户数量，而且该测试还应反映出额外的数据，例如原因代码、联系历史和账户所有者的人口统计数据。完整的测试数据集包括的东西能使测试程序充分验证和使用系统，支持对结果的评估。测试工程师同样需要验证，作为一个查询的结果返回的记录对特定目的仍然有效（如超过90天逾期），且该记录不是遗失或不适当的价值的结果。另一个关键是，对业务逻辑或最终用户的权利和特权，需要不同类型的数据不同路径模拟。
测试执行数据完整性
测试团队需要考虑测试数据的另一方面是在执行测试时需要维护数据的完整性。测试团队需要能够分开数据，修改所选择的数据，并在测试操作后将数据库恢复到初始状态。测试团队需要确保当多个测试工程师同时执行测试时，一个测试不会对其他测试需要的数据产生不利的影响。比如，当测试团队的某个成员正在运行一个查询时，另一个成员修改了数据值，这样查询的结果可能不是期望的，因为记录被其他测试人员修改了。为避免一个测试人员的测试过程影响其他测试人员的测试结果，应给测试人员分配不同的测试任务，要求每个测试人员关注功能的特定方面，不与其他测试人员的工作重叠。使用自动测试脚本可以简化这一过程并使得数据自动保持完整。
条件
应该创建能反映应用领域的特定“条件”的数据集，意思是数据的某种模式只能通过单次执行或随时间推移多次执行后才能获得。例如，金融系统通常执行年终处理（year-end closeout）。以年终条件方式存储数据，使得测试小组可以测试系统的年终状态，而不需要进入全年的数据。有了这些已创建的数据，并准备投入测试，可简化测试工作，因为这种情况下只是简单地载入测试数据，而不是执行许多操作来获得数据的年终状态。同样，自动测试工具可以在这里发挥作用。
作为确定测试数据需求过程的一部分，开发一个包含一列测试过程列表和一列测试需求列表的矩阵是非常有益的。前面已经提到过，小的数据子集对于功能测试足够了，而性能测试则需要一个产品规模的数据库。如果手动建立数据库很可能要几个月的时间。自动化测试则能快速填充测试数据库。
一旦提出了测试数据的需求，测试团队还需要对获取、生成、开发测试数据和刷新测试数据库到原始状态的方法做出计划，以便进行所有测试活动，包括回归测试。这个时候就需要自动化的方法。
测试之前通常需要提前准备好数据。数据准备包括原始数据或文本文件的处理、一致性检查以及对数据元素的深度分析（其中包括根据测试用例标准定义数据，解释数据元素的定义，确定主键，以及定义可用的数据参数）。测试团队需要获得并修改任何测试数据库，这一数据库是执行软件应用程序和开发环境安装脚本和测试台脚本中所必需的。
理想情况下，可利用已有的客户或系统数据，这些数据包括了实际的数据场景的组合和变体（假设数据已经清理过，移除了所有私有的或个人的信息）。客户数据同样包括测试团队没有考虑到的有些组合或使用模式，因此，测试过程中使用已有的真实客户数据对于应用来说是一个非常有用的实际检验。
手动生成测试数据将很繁琐、费时且易出错。
【编辑推荐】
