一、性能测试数据准备

铺底数据准备

铺底数据有目的: 铺底数据的首要目的是让性能测试环境与线上保持一致，或者说接近线上真实情况。一个是保证待测系统有一定的规模，比如半年或一年后的用户规模。另一个是为压测做准备，准备每个要压测的请求需要使用到的数据，这部分数据涉及到具体的业务，对性能测试结果影响比较大，具体说明可参考“参数化数据准备”章节。

根据以上两点，将铺底数据划分为两块：

只做铺底，在压测中不会访问到的数据，这部分数据是为了使数据库达到一定的规模，以发现数据库查询、更新等性能瓶颈，如忘记建立索引，查询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请求传入参数的数据量多少

一个常见的读请求定义为：

"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等请求，也即是向服务端提交数据的请求类型。一般情况下写请求对服务端造成的压力会大一些，因为涉及到数据更新，如数据库更新、缓存更新等。因此，写请求的数据量，对数据库的压力等都是影响性能的条件。写请求关注几点：

写请求对热点数据的更新

写入数据量大小和分布

一个常见的写请求定义如下：

该接口是写请求，目的是设置设备的概要信息。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;
--跳转标志符，名称自己指定
        o_result:=1;
--捕获异常
exception
    when no_data_found
        result := 2;
    when dup_val_on_index
        result := 3;
    when others
        result := -1;
end proc_trade;

//获取连接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(); //获取返回值