问题描述：在测试中我们经常需要大量的历史数据或者测试用的数据来验证系统能否正确的执行，少量的数据我们可以通过手工来实现，但是如果我们需要构建大量的（几年的历史数据）测试数据，应该如何处理呢？
　　既然提到这个话题，就一定有构建大量测试数据的需求——我们团队常把这一类测试叫做“大数据量测试”。从过去的项目情况来看，我们仅有大概20%项目需要这做方面的测试，且侧重于产品。扯远了。
　　开篇说到，构造海量数据来验证系统是否能正确执行。怎样才算正确的执行呢？定义一个清晰的、可测量的标准很重要。在进行大数据量测试之前，首先对测试需求做清晰的分析。我们一般很少从功能评价的角度进行这项测试，更多的时候是考查系统性能和效率。假设一个本科院校的学籍管理系统，主要是用来管理学生的，学生在系统中的生命周期一般是4年，根据学校现有的在校生数以及未来五年每年的招生数据，基本上可以分析出需要构造的各个学年下的学生数。这样一来，原来在单个学期能正确执行的功能（功能、性能、效率都满足需求，这个需求可以作为大数据量测试时的参考标准），在处理4个学年的数据（8个学期）时，各个业务的功能、服务器性能、业务执行效率（如查询、统计、数据挖掘等）还能满足需求吗？根据业务特点，数据在系统中总是有一个相对确定的生命周期的，我们需要构造的往往是这些全生命周期的数据，注意不同的业务模块生成的数据量是不一样的。没有必要去构造不符合实际情况，数量级过大的测试数据。
　　对测试需求做了准确清晰的分析之后，接下来对输入的测试数据进行分析。一方面，我们要求测试数据要尽可能的与生产环境数据一致，尽可能是有意义的数据，可以通过分析使用现有系统的数据或根据业务特点构造数据。另一方面，我们要求测试数据输入要满足输入限制规则，尽可能覆盖到满足规则的不同类型的数据。我们遇到最多的还是在数据库中构造的测试数据，也包括磁盘文件（附件）。
　　最后一步就是生成测试数据了。生成测试数据的方法无外乎编写sql脚本（存储过程）在数据库端直接生成、编写程序代码生成（实际上也是要写sql）、使用批量数据生成工具（DataFactory、PL/SQL Developer、TOAD等都可以）、使用工具录制业务参数化之后长时间运行来生成（如4楼的仁兄所说）。不过个人觉得使用sql来做是最灵活的，尤其是涉及到业务数据相互转换需要充分考虑到内部处理逻辑及约束时。
　　补充一点，大数据量测试同时也是检测服务器性能的好时机（例如执行数据转换、统计分析的业务过程），包括磁盘的I/O性能、内存、CPU等，甚至也是对数据增长预测的一个验证。