性能测试数据准备

方法一：编写存储过程，用SQL脚本方式，插入测试数据

这个方式有几个前提条件：

1-需要对该业务下所有关联的表结构非常熟悉

2-需要对整个业务也非常熟悉

这时需要开发协助编写测试脚本或者向他们学习业务和关联的表结构，自己编写脚本；但是信息来源不全的情况，需要不断尝试，不断调试才能够准备出符合要求的测试数据。

优点是非常直接有效的方法，比较灵活，量和业务需求都是可控的；

缺点就是需要搞清表间关系，精 通业务流程，脚本也需要经常维护。

方法二：通过业务的方式去产生测试数据

当然不是手工去一个一个添加，如果量很大，势必需要依靠自动化工具来实现。这种情况下，测试人员只需要了解业务的操作流程，然后采用LoadRunner能通过业务大量生成数据。

优点：这样的数据一般都是合法可用的，能够确保之后的性能测试的质量。

缺点也很明显，需要开发额外的测试脚本，要花费额外的时间和人力。

方法三：采用生产数据

在有现成数据并且数据保密性要求不高的情况下，可以采用这种方法，毕竟生产数据是原原本本的用户行为所产生的数据。

缺点，量不可能控，可能某些业务的数据量少了，不符合性能测试的需求；生产数据也会有脏数据的产生，会因为系统架构的调整，表结构的变化等等诸多因素产 生脏数据，而这些数据是不具备业务意义的；多数情况下，生产数据一般不会被用于测试。

综上所述，方法一最直接有效，但需要对测试场景下所有关联的表结构和业务非常熟悉；方案二的数据合法可用，但需要开发额外的测试脚本，要花费额外的时间和人力；方法三最最省时省力，但是某些测试场景下的数据量可能不满足并发，也会有脏数据存在，一般不用采用方法三。