说明
文章内容来源 高楼老师-极客时间-《性能测试实战30讲》
怎么设计参数化
参数化数据的疑问根据我的经验，在参数化测试数据的获取和考虑上，我们一般会有以下四个常见的疑问。
- 参数化数据应该用多少数据量？
- 参数化数据从哪里来？
- 参数多与少的选择对系统压力有什么影响？
- 参数化数据在数据库中的直方图是否均衡？
参数化数据量
根据高老师的文章，
1、数据量的多少可以先自己做一次基准测试，根据对应的tps来进行估算：例如tps=100，如果测试的场景是需要运行5min，且每个请求的参数不可重复，那需要的数据量为：560100 = 30000；
若数据部分可重复，就需要看我们测试过程中，线程组和循环的设计了：
图片来源：高老师极客时间《性能测试实战30讲》
以上仅仅为技术层面的评估，在真实进行测试时，我们还需要参考业务场景，综合设计。以下业务场景内容来源：
高老师极客时间《性能测试实战30讲》
场景一：
用户在早上登录系统之后，一直在系统中带着登录 session 做业务操作，并且不会退出，只有在下班时才退出系统。当我们要模拟一天中的业务峰值时，可以这样配置：
在这样的场景中，所需要的数据量就等于线程数量。
参数化数据量=线程数
场景二：
电商中，用户购买商品。
在常见的促销活动中，用户购买商品，很少会有一个用户不停的循环购买商品，这个时候，就需要按照业务处理能力来进行估算数据量了。
在这种场景中，用户是不允许重复的，所需要的数据量就等于请求量。
参数化数据=TPS请求时间（单位s）*
参数化数据来源
参数化数据的来源，有些是数据库有保存的，比如一些查询操作，我们可以直接从数据库取出（根据业务来判断是否需要脱敏），将其放入到参数化文件中；
有些数据是数据库不存在的，比如一些新增操作，这时需要我们自己通过工具进行数据的生成，并将数据放入到参数化文件中，用于测试。
以下为高老师对数据来源的说明：
参数化数据从大体上划分，主要有两个来源。
第一类用户输入的数据在后台数据库中已存在，比如我们上面示例中的用户数据。
这类数据的特点是什么呢？
* 存在后台数据库中；
*需要用户主动输入；
*用户输入的数据会和后台数据库中的数据做比对。
这类数据必须查询数据库之后再参数化到工具中。
第二类用户输入的数据在后台数据库中不存在。
在业务流中，这些数据会 Insert 或 Update 到数据库中。
这类数据的特点是什么呢？
*数据库中原本不存在这些数据；
*在脚本执行成功后会将这些数据 insert 或 update 到数据库中；
*每个用户输入的数据可能相同，也可能不同，这取决于业务特点。
这类数据必须通过压力工具做参数化，同时也必须满足业务规则。
总之，参数化时需要确保数据来源以保证数据的有效性，千万不能随便造数据。
这类数据应该满足两个条件：
*要满足生产环境中数据的分布；
*要满足性能场景中数据量的要求。
参数化数据的多与少对系统的影响
关于数据量的多少，会影响到测试结果，同时测试结果一定要表明是基于多少的数据量，得出当前的测试结果。
参数取得过多，对系统的压力就会大； 参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。
参数化数据是否均衡
数据是否均衡，主要是关于业务相关的数据，我们需要明确客户的业务获取真实的数据。
比如我们在将某id值设置为10000，而实际情况下，此id值大多为300左右，此时就会影响到系统的处理能力，最终的TPS就会有偏差。
在涉及到业务处理操作时，对数据进行参数化之前，先看一下数据库，已有的数据分布是怎样的。如果是一个新的系统，可同产品等业务人员进行确认，而后进行数据设计。如果时间允许，可分别设计不同的参数，进行压测，统计后作为此次测试的结果。
