【性能测试】构造性能测试的数据

关于如何准备性能测试数据，可能出现不少的问题，比如：

数据量不足
导致性能表现非常好，忽略了一些潜在性能问题
数据分布不合理
导致测试结果与线上差异较大，又要推到重来

总结下经验，把测试数据准备分为两类数据：铺底数据和参数化数据

什么是铺底数据？
一般情况下，产品上线后数据量是不断增加和累计的过程。刚上线时，数据量较少，数据库查询及更新速度快，服务响应及时性较好。随着数据量的累积，数据量不断增加和膨胀，系统的操作响应时间会随着数据量的不断增加而变得越来越长。所以，在性能测试模拟时，要考虑一定规模数据量情况下的性能是否能满足预期，比如考虑半年或一年的业务量
什么是参数化数据？
在压力测试时，通常模拟不同的用户行为，或者业务行为，从系统所提供的API来看，需要参数化用户账号等数据，如考拉海淘产品，压测下单场景时，要参数化用户数据，哪些用户进行下单，参数化商品数据，这些用户购买什么产品等

一、铺底数据准备

1.1 铺底数据有目的

铺底数据目的是让性能测试环境与线上保持一致，或者说接近线上真实情况

保证待测系统有一定的规模，比如半年或一年后的用户规模
为压测做准备，准备每个要压测的请求需要使用到的数据，这部分数据涉及到具体的业务，对性能测试结果影响比较大

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

只做铺底，在压测中不会访问到的数据

这部分数据是为了使数据库达到一定的规模，以发现数据库查询、更新等性能瓶颈，如忘记建立索引，查询SQL不合理等问题

只为铺底，压测时不会用到的这部分数据，在预设的过程中就比较随意了，不用考虑数据是否合理，也不用考虑业务关联关系，只要符合数据库设计规则，能插入数据库即可
在压测时要用到的数据

比如API要传参过去的数据，或者请求响应数据。这部分数据在铺底的时候就要精细化的设计，包括数据大小，数量，分布等

1.2 铺底数据量多少合适

完全根据产品的规模来预估

比如产品预计半年后注册用户数达到100w，则铺底的时候需要铺底100w用户账号

如果是已上线产品，根据线上数据库数据量进行预估，可以根据用户规模的比列进行铺底，如线上注册用户数一千万，线下铺底注册用户数100w，则总体数据规模为线上的十分之一左右

实际情况下，这里会略微复杂，比如还要考虑线上数据库集群和测试集群的硬件差异等，需做适当的调整

二、参数化数据准备

如果从系统接口调用角度来看的话，参数化数据包括两类：

一类是要传参给接口调用的数据

比如用户账号ID，商品ID等
一类是接口返回的结果数据

如获取商品详情时，需要返回商品的数量、颜色、描述信息等，这些数据必须是事先准备好

在进行参数化数据准备时，对于已经上线的产品，可以统计不同铺底数据的分布规律

从网易宝和之前的timeline的两个产品的数据统计来看，大多数数据的分布接近2/8原则。比如活跃用户数占注册用户数的比例为20%，非活跃或者欠活跃的用户占比为80%左右。针对具体业务，80%的业务是由20%的活跃用户产生，20%的业务是由80%的非活跃用户产生。所以参数化测试账号时，对这20%的用户账号需要进行精心铺底

2.1 测试账号准备

注册用户数是产品用户规模的衡量指标，一般会先铺底一定规模的用户账号

铺底多少测试账号？根据产品本身的特点、参考竞品的用户量、以及产品的推广计划，预估半年后要推广到100w用户。那这100w是指注册用户数。一般互联网产品活跃用户是注册用户的10%~20%，不同类型的产品略有差异。那么在准备数据的时候，会考虑铺底100w用户，其中80%左右的用户是非活跃用户，用户相关数据会比较随意的铺底，保证铺底主表及关联表即可，其中20%左右的用户是活跃用户，是压测时要用到的数据，这20%的用户信息，比如好友关系、发表的微博数量等，都需要设计进行铺底

2.2 读请求数据准备

读请求一般即为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的数据量准备

2.2.1 读请求返回的数据量准备

读请求返回的数据量大小要与实际情况基本一致：

返回数据量不能太大

太大会偏离实际情况，增加数据库压力，网络传输时延等，导致测试结果比实际情况差的多
返回数据量不能太小

比如获取一篇博文，博文不能全部返回空，会比实际情况好，导致遗漏一些性能风险点

如示例中的RETRUN内容为2条信息左右，通常情况下用户的设备详情信息在2_{10条左右，这里铺底就要考虑铺底随机2}10条

返回数据量的多少取决于预设的数据量

例如测试活动页的性能，预设10个商品和200个商品时，得到的性能测试数据不一样，发现的问题点也可能不一样：

10个商品时，性能开销在memcached网络IO上
200个商品时，发现性能开销在返回数据的序列化上

再比如：

获取博客详情信息，博客长度为几百字和几千字的性能也是会有差异的，体现在从缓存或者数据库中获取数据量多少时的性能差别等

方法

预设这部分数据时，需要了解返回数据的上限是多少，即找相关开发了解一个活动页面最多会有多少数据，分别测试常规情况下活动页的性能以及极限情况下活动页的性能

另外返回数据量的多少可能会使得网络带宽首先成为瓶颈点，当返回的数据量过多时，应该通过分页等策略限制返回数据量的大小

2.2.2 传入参数的数据量准备

传入参数的数据量是指，GET请求中需要的参数从多少数据量中获取

例如：

获取博客详情接口，给定的参数可以是一个博客地址，不停的获取该博客的内容，也可以是10w个博客地址，随机的获取这些博客
示例中的deviceId在压测中会从10w个设备中随机选择进行测试，也就是要在测试前铺底10w个设备

这种情况下，需要找开发确认，代码实现中是否有缓存相关操作，如果热点博客会被缓存住，那一个博客的情况下，测试的是全部被缓存住的性能，10w个博客，根据缓存大小的不同，可能会测试到不同情况下的性能

对于有热点缓存的情况，建议可以测试下把缓存关掉时的性能，发现极端情况无缓存时是否存在性能问题

2.2.3 读请求的传入参数与返回数据量两者结合

有些时候，以上两种情况都需要考虑，即：传入参数的数据量以及返回的数据量

例如获取博客的评论信息接口：基于80/20原则，20%的博客为热点博客，这20%的博客的评论数量较多，另外80%的博客为非热点博客，评论数较少。为了得到更真实的性能结果，需要把这多种情况都考虑进去

2.3 写请求数据准备

写请求，一般情况下指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

deviceId是参数化数据，需要提前进行铺底的数据
description描述信息

description是描述信息，是文本信息，设置多少字节？需要根据实际情况预设

2.3.1 写请求对热点数据的更新

写请求有若干种情况，更新单个数据，批量更新多个数据，多个用户同时更新同一个数据等，针对不同类型的写请求，对资源的更新、竞争会造成不同的压力

热点数据更新，是指对该数据有资源竞争的情况。典型的场景例如：

电商的秒杀场景，大量用户同时抢购同一件商品
社交类的热点微博，大量用户同时评论同一个微博
大量用户同时关注同一个明星账号

测试对热点数据竞争时的性能问题和数据库锁竞争问题等

所以在准备这部分数据时，即需要准备批量的数据，测试随机购买、随机评论的性能，也需要准备少量的热点数据，测试对热点数据竞争时的性能

2.3.2 写入数据量大小和分布

当压测写请求时，是需要提交数据到服务端，然后会写入缓存或者写入数据库

这部分数据量的大小及分布会对性能结果影响比较多，数据量的大小会影响网络传输时间，会影响数据库更新时间，一般情况下，数据量越大，响应延迟会越高。所以，写请求传参的数据量要尽可能符合实际的用户行为，最好统计线上真实数据，博客的长度一般在多少字以内，微博的长度一般在多少字左右等