关于如何准备性能测试数据，相信不少性能测试人员也踩过不少坑：比如数据量不足，导致性能表现非常好，忽略了一些潜在性能问题；数据分布不合理，导致测试结果与线上差异较大，又要推到重来。经过n多次被坑之后，总结下经验。我们把测试数据准备分为两类数据：铺底数据和参数化数据。
什么是铺底数据？一般情况下，产品上线后，数据量是不断增加和累计的过程。刚上线时，数据量较少，数据库查询及更新速度快，服务响应及时性较好。随着数据量的累积，数据量不断增加和膨胀，系统的操作响应时间会随着数据量的不断增加而变得越来越长。所以，在性能测试模拟时，要考虑一定规模数据量情况下的性能是否能满足预期，比如考虑半年或一年的业务量。
什么是参数化数据？在压力测试时，通常模拟不同的用户行为，或者业务行为，从系统所提供的API来看，我们需要参数化用户账号等数据，如考拉海淘产品，压测下单场景时，我们要参数化用户数据，哪些用户进行下单；参数化商品数据，这些用户购买什么产品等。
一、性能测试数据准备
铺底数据准备
铺底数据有目的: 铺底数据的首要目的是让性能测试环境与线上保持一致，或者说接近线上真实情况。一个是保证待测系统有一定的规模，比如半年或一年后的用户规模。另一个是为压测做准备，准备每个要压测的请求需要使用到的数据，这部分数据涉及到具体的业务，对性能测试结果影响比较大，具体说明可参考“参数化数据准备”章节。
根据以上两点，将铺底数据划分为两块：
- 只做铺底，在压测中不会访问到的数据，这部分数据是为了使数据库达到一定的规模，以发现数据库查询、更新等性能瓶颈，如忘记建立索引，查询SQL不合理等问题。只为铺底，压测时不会用到的这部分数据，在预设的过程中就比较随意了，不用考虑数据是否合理，也不用考虑业务关联关系，只要符合数据库设计规则，能插入数据库即可。
- 另一部分数据是在压测时要用到的数据，比如API要传参过去的数据，或者请求响应数据。这部分数据在铺底的时候就要精细化的设计，包括数据大小，数量，分布等。
铺底数据量多少合适？ 这个完全根据产品的规模来预估，比如产品预计半年后注册用户数达到100w，则铺底的时候需要铺底100w用户账号。如果是已上线产品，根据线上数据库数据量进行预估，可以根据用户规模的比列进行铺底，如线上注册用户数一千万，线下铺底注册用户数100w，则总体数据规模为线上的十分之一左右。实际情况下，这里会略微复杂，比如还要考虑线上数据库集群和测试集群的硬件差异等，需做适当的调整。
参数化数据准备
如果我们从系统接口调用角度来看的话，参数化数据包括两类：一类是我们要传参给接口调用的数据，比如用户账号ID，商品ID等。 另一类是接口返回的结果数据，如获取商品详情时，需要返回商品的数量、颜色、描述信息等，这些数据必须是事先准备好的。
在进行参数化数据准备时，对于已经上线的产品，可以统计不同铺底数据的分布规律。从网易宝和之前的timeline的两个产品的数据统计来看，大多数数据的分布接近2/8原则。比如活跃用户数占注册用户数的比例为20%，非活跃或者欠活跃的用户占比为80%左右。针对具体业务，80%的业务是由20%的活跃用户产生，20%的业务是由80%的非活跃用户产生。所以参数化测试账号时，对这20%的用户账号需要进行精心铺底。
测试账号准备
注册用户数是产品用户规模的衡量指标，一般会先铺底一定规模的用户账号。
铺底多少测试账号？根据产品本身的特点、参考竞品的用户量、以及产品的推广计划，预估半年后要推广到100w用户。那这100w是指注册用户数。一般互联网产品活跃用户是注册用户的10%~20%，不同类型的产品略有差异。那么我们在准备数据的时候，会考虑铺底100w用户，其中80%左右的用户是非活跃用户，用户相关数据会比较随意的铺底，保证铺底主表及关联表即可；其中20%左右的用户是活跃用户，是压测时要用到的数据，这20%的用户信息，比如好友关系、发表的微博数量等，都需要设计进行铺底。
读请求数据准备
读请求一般即为GET请求，影响GET请求性能的主要有两部分：
- 一是GET请求返回的数据量的多少
- 一是GET请求传入参数的数据量多少
一个常见的读请求定义为：
URI：/video/details?deviceId=123456 Method：GET Reurn：{ "message": "success", "timeline": { "list": [ { "from": -23261042219000, "to": -23261042199000 }, { "from": 1388523600000, "to": 1388523921000} ]}, "code": 200 }
其中，deviceId是接口调用时要传的参数，这里是指设备Id；Reurn是指该接口的返回数据，返回数据内容为该设备的详情信息。那么在铺底数据的时候，我们要铺底deviceID来虚拟出若干设备出来，同时这些设备的详情信息不能为空，也需要进行铺底；这就涉及到接下来要介绍的，读请求返回数据量准备和传入参数deviceId的数据量准备。
读请求返回的数据量准备
读请求返回的数据量大小要与实际情况基本一致，返回数据量不能太大，太大会偏离实际情况，增加数据库压力，网络传输时延等，导致测试结果比实际情况差的多；返回数据量不能太小，比如获取一篇博文，博文不能全部返回空，会比实际情况好，导致遗漏一些性能风险点。如示例中的RETRUN内容为2条信息左右，通常情况下用户的设备详情信息在2~10条左右，这里铺底就要考虑铺底随机2~10条。
返回数据量的多少，取决于预设的数据量，例如测试活动页的性能，预设10个商品和200个商品时，得到的性能测试数据不一样，发现的问题点也可能不一样：10个商品时，性能开销在memcached网络IO上；200个商品时，发现性能开销在返回数据的序列化上。再比如，获取博客详情信息，博客长度为几百字和几千字的性能也是会有差异的，体现在从缓存或者数据库中获取数据量多少时的性能差别等。
方法：预设这部分数据时，需要了解返回数据的上限是多少，即找相关开发了解一个活动页面最多会有多少数据，分别测试常规情况下活动页的性能以及极限情况下活动页的性能。
另外返回数据量的多少可能会使得网络带宽首先成为瓶颈点，当返回的数据量过多时，应该通过分页等策略限制返回数据量的大小。
传入参数的数据量准备
传入参数的数据量是指，GET请求中需要的参数从多少数据量中获取，例如获取博客详情接口，给定的参数可以是一个博客地址，不停的获取该博客的内容，也可以是10w个博客地址，随机的获取这些博客的性能。如示例中的deviceId在压测中会从10w个设备中随机选择进行测试，也就是我们要在测试前铺底10w个设备。
这种情况下，需要找开发确认，代码实现中是否有缓存相关操作，如果热点博客会被缓存住，那一个博客的情况下，测试的是全部被缓存住的性能，10w个博客，根据缓存大小的不同，可能会测试到不同情况下的性能。
对于有热点缓存的情况，建议可以测试下把缓存关掉时的性能，发现极端情况无缓存时，是否存在性能问题。
读请求的传入参数与返回数据量两者结合
有些时候，以上两种情况都需要考虑，即：传入参数的数据量以及返回的数据量，例如获取博客的评论信息接口：基于80/20原则，20%的博客为热点博客，这20%的博客的评论数量较多，另外80%的博客为非热点博客，评论数较少。为了得到更真实的性能结果，我们需要把这多种情况都考虑进去。
写请求数据准备
写请求，一般情况下指POST、PUT等请求，也即是向服务端提交数据的请求类型。一般情况下写请求对服务端造成的压力会大一些，因为涉及到数据更新，如数据库更新、缓存更新等。因此，写请求的数据量，对数据库的压力等都是影响性能的条件。写请求关注几点：
- 写请求对热点数据的更新
- 写入数据量大小和分布
一个常见的写请求定义如下：
URI: /public/setAsPublic Method：POST Body：{ "deviceId": "111", "description": "this is my device", } Return: { "message": "success", "result": { "deviceId": "111", "onlineNumber":0 }, "code": 200 }
该接口是写请求，目的是设置设备的概要信息。deviceId是设备Id，description描述信息。deviceId是参数化数据，需要提前进行铺底的数据。description是描述信息，是文本信息，设置多少字节？需要根据实际情况预设。
写请求对热点数据的更新
写请求有若干种情况，更新单个数据，批量更新多个数据，多个用户同时更新同一个数据等，针对不同类型的写请求，对资源的更新、竞争会造成不同的压力。热点数据更新，是指对该数据有资源竞争的情况，典型的场景例如电商的秒杀场景，大量用户同时抢购同一件商品；例如社交类的热点微博，大量用户同时评论同一个微博；大量用户同时关注同一个明星账号等。测试对热点数据竞争时的性能问题和数据库锁竞争问题等。
所以在准备这部分数据时，即需要准备批量的数据，测试随机购买、随机评论的性能，也需要准备少量的热点数据，测试对热点数据竞争时的性能。
写入数据量大小和分布
当压测写请求时，是需要提交数据到服务端，然后会写入缓存或者写入数据库的，这部分数据量的大小及分布会对性能结果影响比较多，数据量的大小会影响网络传输时间，会影响数据库更新时间，一般情况下，数据量越大，响应延迟会越高。所以，写请求传参的数据量要尽可能符合实际的用户行为，最好统计线上真实数据，博客的长度一般在多少字以内，微博的长度一般在多少字左右等。
二、性能测试数据准备方法
从线上数据库导入真实数据
从线上数据库或者备库导入数据，最大的优势是数据真实性高，数据分布合理，业务压力点及瓶颈点能和线上保持一致，这样测试出的结果与线上实际情况表现会比较接近。比自己模拟数据要可靠的多。
但是，缺点是用户数据需要进行脱敏，而且也要考虑用户的数据是否能直接拿来用，比如用户的手机号，需要脱敏掉，涉及到短信通知等业务需要进行一定的处理，或者mock掉等。
从线上导入数据库推荐准备过程：
- 先从基础表导出数据，可以全部导出，也可以部分导出
- 从基础表的数据出发，导出关联表的数据
- 数据导出后，对敏感的数据进行处理，即按一定的规则进行更新
根据业务规则构造模拟数据
模拟数据优点：符合自己定义的规则，便于使用，比如测试账号可以自己进行编号，参数化使用时方便。
缺点也比较明显：
- 模拟数据需要大量的梳理工作，要梳理数据库表，理清哪些是基础表，表与表之间的关联等；
- 要充分把握产品业务，比如社交类产品，要统计和分析用户的好友关系，每个用户的好友个数分布，每个好友发布的微博梳理分布等，这样测试结果才能趋于线上一致。
使用接口进行预设数据
使用接口进行数据预设，需要先根据产品的业务特征来梳理数据的分布规律。针对产品业务抽取要铺底的数据，对该铺底数据进行特征提取，如某电商产品需要整体性能压测，主要业务包括商品浏览、商品购买、订单查询等业务
- 首先要铺底测试账号，测试账号有多种特征，是否绑定银行卡，是否绑定支付宝，是否绑定其他支付渠道等；
- 铺底商品信息，根据不同的地区商品信息略有差异，北京商品数量和分布；杭州商品数据量和分布等；
- 铺底订单信息，多少用户没有下过单，多少用户有0~10单，多少用户有10~100订单等具体分布情况。
针对以上某一项数据可以抽取A、B、C、D、E共5种特征，比如测试账号，A是绑定银行卡的，B是绑定支付宝支付的，C是绑定网易宝支付，D是同时绑定银行卡和支付宝的账号等5类特征，根据线上数据统计5类特征所占的比例。调用注册账号的接口按照各特征所占比例进行生成数据分布。使用接口预设数据相对比较耗时。
使用存储过程预设数据
除了用应用接口进行数据预设以外，也可以通过存储过程进行数据预设。使用存储过程的时候，需要梳理基础表，以及表和表之间的关联。使得一次存储过程的调用，插入数据库中的数据和进行一次业务操作插入的数据要一致。这一点需要开发配合梳理。有了存储过程，可以自己写程序直接调用存储过程插入数据。
如铺底订单信息，针对部分用户铺底订单，订单状态包括30%已完成支付、50%未支付订单、20%取消订单案例，通过以下方式准备：
a.创建存储过程
CREATE OR REPLACE procedure proc_trade( v_trade_id in number, --交易id v_third_ip in varchar2, --第三方ip v_third_time in date , --第三方完成时间 v_trade_state in number , --订单状态，0未支付；1已支付；2取消 o_result out number, --返回值 o_detail out varchar2 --详细描述 )as-- 定义变量 v_error varchar2(500); begin --对变量赋值 o_result:=0; o_detail:='验证失败'; --业务逻辑处理 if v_tradeid >100 then insert into orders(id, third_ip, third_time, trade_state, result, detail) values(v_trade_id, v_third_ip, v_third_time, v_trade_state, o_result, o_detail); commit; elsif v_tradeid < 100 and v_tradeid > 50 then insert into orders(id, third_ip, third_time, trade_state, result, detail) values(v_trade_id, v_third_ip, v_third_time, v_trade_state, o_result, o_detail); commit; else goto log; end if; --跳转标志符，名称自己指定 <<log>> o_result:=1; --捕获异常 exception when no_data_found then result := 2; when dup_val_on_index then result := 3; when others then result := -1; end proc_trade;
b.Java调用存储过程
//获取连接connConnection conn = datasource.getconnection();//创建并初始化CallableStatementCallableStatement cs = null; cs = conn.prepareCall("{call proc_trade(?,?,?,?)}");//设置参数trace_id，third_ip，third_time，trade_state，这些值预先设置好//并且trade_state符合分布比例：30%已完成支付、50%未支付订单、20%取消订单 cs.setString(1, traceid); cs.setString(2, third_ip); cs.setString(3, third_time); cs.setString(4, trade_state); //获取返回值，o_result cs.registerOutParameter(5, Types.BIGINT); //执行存储过程 cs.executeUpdate(); //获取返回值
