我们要怎样准备数据要和看真实用户的使用场景，也就是说要和具体的业务相结合。
1）假设所测试业务是边生产边消耗，比如购买商品的业务，下单会产生一个订单号，付款会消耗掉一个订单号，那么脚本中应该同时录制生产和消耗的业务
2）假设所测试的业务是只消耗不生产，比如删除账号，很明显用户使用的过程，注册用户和删除用户不是一起使用的，所以像假设1）在脚本中同时录制注册和删除账号的业务不符合用户使用场景，用这种方式边生产边消耗不可取
a、考虑是否可以测算出场景跑的这段时间内需要多少账号，先给数据库中预置上这些账号。
比如测试删除账号场景跑5分钟，1000人并发，运行5分钟脚本要删除20w个账户，那我们需要给数据库中预置20w个账号
这样又会带来一个问题：假设线上真实用户注册量是1w，我们要考虑从20w数据量的表中删除数据和从1w数据量表中删除数据效率是否一样
如果效率相差很大，那就不能给数据库预置20w个账号来进行测试。因为这种方式不是用户真实使用场景
如果效率相差不太大，那么可以考虑这种方式
怎么判断1w数据量和20w数据量效率相差大不大？
可以在1w数据量的时候记录下响应时间，然后在20w数据量的时候再记录个响应时间，两个时间比较。相差时间大不大与表的结构，查询字段是否添加索引，以及开发在代码中写的sql都有关系。不同系统会有不同的数据。
b、以上a方法中 给数据库预置20w个账号来进行测试，效率相差很大，不能事先预置数据了。那我们就考虑边产生数据边消耗数据。又因为2）的假设，不能直接调用业务接口产生数据，那我们就考虑通过sql语句去产生数据
可以通过python代码去执行注册账号的sql的语句，但是这种方式产生数据的效率不好控制，可能python代码执行太快，已经产生了很多账号，但是执行loadrunner脚本慢一些，消耗的慢，时间长了，数据库中也会累积很多数据，影响响应时间。可能python代码执行太慢，但是loadrunner脚本快一些，需要消耗的数据还没有产生出来，删除账号是又会报错，所以个人觉得这种方式不可取
通过loadrunner工具直接调用数据库，执行注册账号的sql的语句。每个用户每次删除账号之前去数据库中插入一个账号。这样做能使生产和消耗数据达到平衡。但是也会带来一个问题，每个虚拟用户都会连接一次数据库，增加了数据库的开销，严重时甚至会使数据库连接池满，影响正常删除用户的业务不能连接数据库，还需要权衡数据库连接池够不够，但是这种方式对服务器的资源消耗影响最小，也能保证业务消耗数据，所以个人觉得这种方式好一些
综上所述，做性能测试时不管是设计场景，还是准备测试数据，都尽量要遵守用户实际使用场景，不能脱离实际，尽量选择一个对服务器影响最小的方式进行测试
