12丨性能场景：做参数化之前，我们需要考虑什么？
下载APP
关闭
渠道合作
推荐作者
12丨性能场景：做参数化之前，我们需要考虑什么？
2020-01-10 高楼 来自北京
《性能测试实战30讲》
课程介绍
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="1142" height="640"><rect fill-opacity="0"/></svg>)
讲述：高楼
时长20:22大小18.60M
在性能测试中，我们要关注的数据主要有以下几类，分别是参数化数据、监控数据和基础铺底数据。
我们今天先描述第一种参数化数据，在后面的文章中再描述其他数据。
首先我们需要了解，为什么要关注性能场景中的参数化数据呢？我以下面的两个例子说明一下。
在我的工作经历中，见过很多初级性能测试工程师不知道如何设置合理的参数化数据，以至于数据会出现这两种情况。
1. 数据不均衡
有些人直接用同一个数据执行混合场景测试，在这种情况下对服务器的压力和真实环境下的完全不一样。有时我们不得不造很多参数化数据，也有很多工程师不考虑数据库表中的数据直方图，就直接在少量的参数化数据中创建了大量的相关记录。比如说，在电商系统中造出大量的购买记录；在银行系统中造出大量的个人流水记录。
这些都不能满足真实用户场景的需要，导致的结果就是整个测试结果都毫无意义。
2. 参数化数据量不足
有时候，如果我们选择用非常少量的数据运行大量业务操作的场景，就会导致压力和真实生产环境完全不一致。比如说，用 100 个数据运行出上万甚至上亿的业务操作。
那么到底该怎样才能合理地设置参数化数据呢？
参数化数据的疑问
根据我的经验，在参数化测试数据的获取和考虑上，我们一般会有以下四个常见的疑问。
参数化数据应该用多少数据量？
参数化数据从哪里来？
参数多与少的选择对系统压力有什么影响？
参数化数据在数据库中的直方图是否均衡？
接下来，我们对这些问题一一做出解答。
参数化数据应该用多少数据量？
首先，参数化数据要用到多少取决于场景，举例来说，对一个压力工具线程数为 100，TPS 有 1000 的系统，如果要运行 30 分钟，则应该取得的参数化数据是下面这样的。
数据类型、限制条件和数据量计算的方式如下表所示：
从技术角度看，根据数据类型就可以确定应该用多少条参数化数据了。但是这样考虑就够了吗？当然是不够的。因为除了技术的限制之外，还有业务场景的需求。
根据业务场景计算参数化数据量
在性能场景中，我们需要根据实际的业务场景来分析需要用到什么样的数据，以便计算数据量。这里的数据类型包括可循环使用的数据和不可循环使用的数据。用户登录是一个在各行业中几乎都会遇到的事务，我们拿它来举例说明，下面这张图是一个用户登录的界面。
这里需要用到两种数据，一个是帐号，一个是密码。帐号和密码一定是可以真实登录到系统的，不然无法完成后续的业务。很显然对于登录来说，不同的人一定是用不同的用户登录的。
场景一
首先我们来看下场景一。有时候我们做脚本时考虑的是，有多少线程（Thread）就配置多少用户，让每个线程在同一个用户上循环执行。
如下图所示：
需要注意的是，在本文中，每一个“—user1→”代表一次脚本完全的迭代。
这样的用户参数化配置，只能满足一些比较特定的场景。比如说，用户在早上登录系统之后，一直在系统中带着登录 session 做业务操作，并且不会退出，只有在下班时才退出系统。
当我们要模拟一天中的业务峰值时，可以像上面这样配置。登录一次，循环使用同一用户的 Session 信息。这就是前面提到的部分可循环数据。
在这样的场景中，有多少线程就需要准备多少用户数据。即：
场景二
但在有些场景中，这是完全错误的配置方式。比如说电商系统，用同一个用户账号不停循环购买商品，就是不符合真实场景的。
这时侯怎么办？我们可以用在压力测试工具中模拟出来的线程的每一次迭代来代表一个用户，如下所示：
这就是不可循环使用的数据。在这样的场景中，就需要考虑场景的 TPS 和持续时间了。用户数据的计算方法是：
我们举个例子，假如有一个 100TPS 的场景，持续 30 分钟。那么计算方式如下：
场景三
但是还有一种情况，就是在一个线程之中，可以循环使用固定条目的数据。如下所示：
在这种情况下，我们就需要根据实际的业务场景判断了。在 100 压力线程的场景中，如果准备了 1000 条数据，就可以让每个线程用 10 个不同的数据。
这样的场景没有固定的条数限制，只能根据实际的业务判断。
所以在配置参数之前，我们需要先判断这个参数是什么类型的数据。
如果是可循环使用的数据，那么它在真实的性能场景中非常少，也就是说只使用一条或几条测试数据的真实业务场景是非常少的。
参数化数据从哪里来？
计算了参数化数据量之后，还有一个重要的问题需要解决，就是参数化数据从哪里来呢？这一步的目的是要确保参数的有效性。
参数化数据从大体上划分，主要有两个来源。
第一类
用户输入的数据在后台数据库中已存在，比如我们上面示例中的用户数据。这类数据的特点是什么呢？
存在后台数据库中；
需要用户主动输入；
用户输入的数据会和后台数据库中的数据做比对。
这类数据必须查询数据库之后再参数化到工具中。
第二类
用户输入的数据在后台数据库中不存在。在业务流中，这些数据会 Insert 或 Update 到数据库中。这类数据的特点是什么呢？
数据库中原本不存在这些数据；
在脚本执行成功后会将这些数据 insert 或 update 到数据库中；
每个用户输入的数据可能相同，也可能不同，这取决于业务特点。
这类数据必须通过压力工具做参数化，同时也必须满足业务规则。
我同样用前面的用户参数为例，由于用户登录的时候一定要和数据库中的用户数据做比对，只有用户名密码都完全正确的情况下才可以成功登录，所以这样的用户参数一定要从后台数据库中查询得到。
在本例中，通过后台数据库用户表的查询真实可用的用户数共有 10 万。
如果在业务场景中，是不可循环使用的用户数据，那么很显然，在可以支持 100TPS 并发的系统中，这些用户数量只够使用 16.67 分钟。
总之，参数化时需要确保数据来源以保证数据的有效性，千万不能随便造数据。这类数据应该满足两个条件：
要满足生产环境中数据的分布；
要满足性能场景中数据量的要求。
参数取多与少对系统压力有什么影响？
根据上文中的第二个条件，这里就要说一下数据量的要求了。
从经验上判断，对一个系统来说，获取的参数化数据是否合理，会直接影响压力测试的结果有没有意义。
我们根据下面这张图来理解一下数据在系统中的流转。
这张图中，绿色部分代表数据在各系统中的正常大小，而黑色部分代表压力工具中使用的数据量大小。如果压力工具使用的数据量少，那么应用服务器、缓存服务器、数据库服务器，都将使用少量的缓存来处理。
显然图中所示的黑色部分是很少的，完全不能把后端各类服务器的缓存占用到真实场景中应该有的大小，所以在这种状态之下是测试不出来真实场景下的压力的。
对数据库连接的存储设备来说同样也有影响。如果数据量少，则相应的存储的 I/O 使用就少。对于一个没有被 Cache 的数据来说，首次使用肯定会触发 I/O，也就是会产生寻址、PageFalut 等情况。
参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。
参数化数据在数据库中的直方图是否均衡？
对于参数化数据来说，如果数据取自于数据库，我们通常要检查一下数据库中的数据直方图。 对于直接从生产上拿的数据来说，数据的分布更为精准。但是对于一些在测试环境中造的数据，则一定要在造数据之后，检查下数据分布是否与生产一致。
我们以一个案例开始。
在性能场景执行过程中，有一个业务的 TPS 如下图所示：
很明显，图中 TPS 中间掉下来的情况是非常不合理的。
为什么会导致这个情况呢？在这个示例中，这种现象是由抽取的数据量不合理导致的，我们来看一下数据分布。
显然通过统计之后，我们可以发现客户的流水记录数是完全不均衡的，而这个业务脚本是会返回客户的流水记录的。当用到记录数多的客户 ID 时，就会导致 TPS 严重下降，这是因为这些数据都要从存储设备中获取，一旦数据量多，就会导致一系列的资源开销；而用到记录数少的客户 ID 时，TPS 就很高。
那么针对这种情况，我们该怎么处理呢？
首先分析业务逻辑，确认客户流水是否应该这么多。在这个场景中，我们分析过业务，客户的流水通常情况下都会在 100~200 之间，这是合理的情况，而上万的数据量就是完全不合理的。
然后我们过滤掉不合理的数据即可。
这样得到的参数化数据就符合真实场景了。
总结
在今天的文章中，需要你领悟到的是，参数化数据的合理性对性能场景有着举足轻重的作用。通常，我们在做参数化数据之前，需要先分析实际业务的逻辑。比如说：
什么数据是唯一的？什么数据是可重复使用的？
数据是客户主动输入，后端只保存即可，还是客户输入后，后端需要比对？
这些都是我们在做参数化之前要分析的部分。而参数化的数据量的重要性，不仅和业务需求相关，也和数据存储和查询的方式相关。这个话题我们在后面也会讨论到。
思考题
如果你吸收了这篇文章的内容，不妨思考一下下面这两道题：
参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？
参数化数据的来源和获取要符合哪些规则？当不符合获取规则时，会产生什么问题？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流学习一下。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享赞 7
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
11丨性能脚本：用案例和图示帮你理解HTTP协议
下一篇
13丨性能测试场景：如何进行场景设计？
精选留言(29)
zuozewei2020-01-22小结一下，在性能测试中，我们关注的参数化数据主要有以下几个方面： 1）参数化数据应该用多少数据量？ 我们需要保证测试时间足够长、满足测试的负载请求需求，根据「目标tps x 持续时间（秒级）」可以计算出参数化数大概的量级。 2）参数化数据从哪里来？ 大概分为两大类型： - 死水数据，即out-of-box（事先创建测试数据），数据存在后台的数据库中； - 活水数据，即On-the-fly（实时创建），数据库不存在这些数据，构造参数化数据需要符合业务特点。 构造测试数据通常有以下两种方法： - 通过 API 调用生成测试数据； - 通过数据库操作生成测试数据。 3）参数多与少的选择对系统压力有什么影响？ 满足测试的负载请求足够多和数据足够多样化，从而最大限度地减少或者掩盖缓存等其他因素的影响。参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。 4）参数化数据在数据库中的直方图是否均衡？ 参数化数据需要符合真实业务数据分布情况，这样更符合业务真实场景。展开作者回复: 总结的很好。
21
律飛2020-01-101.参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？ 分析重点是获知数据量。一是通过业务模型分析计算，获得初步的数据量要求；二是根据限制条件和业务场景，确定数据类型；三是结合上述两点，最终确定参数化数据的数据量。 不同场景中，数据使用对业务的完成是不一样的，比如某一场景中数据可以反复出现，不影响业务，自然能实现预期的场景；而另一场景中，反复出现的数据却不能多次实现同一业务，这种情况下，当时无法实现预期的场景。 2.参数化数据的来源和获取要符合哪些规则？当不符合获取规则时，会产生什么问题？ 参数化时需要确保数据来源以保证数据的有效性，千万不能随便造数据。这类数据应该满足两个条件：要满足生产环境中数据的分布；要满足性能场景中数据量的要求。 产生的问题：1.不合理的数据分布，会干扰测试结果，增加后续分析和测试的工作量；2.数据取得过多，对系统的压力就会大；数据取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。展开作者回复: 理解的很对。这样下去，看完专栏就超过我了。
13
bolo2021-02-251、参数化数据的分析重点是哪些？ 在不同的场景中为什么参数化数据有如此大的差异？ 参数化的数据量。 具体还是要结合具体的业务来进行分析，是否可以重复使用数据 如果仅仅是一个查询接口，没有涉及缓存，每次都是走一个DB的查询，那这样的话可以使用重复数据。 如果这个接口设计了读写，并有缓存，就要分开来进行考虑了。 2、参数化数据的来源和获取要符合哪些规则？ 当不符合规则时，会产生什么问题？ a）、数据来源尽可能贴近生产环境的业务逻辑 b）、满足生产的数据分布（分库分表..） 当不符合规则是，会导致性能测试意义变得不大。因为没有模拟生产的用户业务操作。 举个栗子： 一个接口是用来获取用户的VIP的状态的？ 当用户符合条件，需要将用户的状态置为VIP（一次update操作），同时设置缓存。当下次查询的时候，就会直接命中缓存。 如果采用的同一个数据，只有第一个请求，会走到所有的逻辑判断，后续的请求就会直接命中缓存，TPS很高，响应时间很短。给人一种错觉，接口的性能很好，其实并不是符合实际需要的。 这是我们就需要采用参数化的不循环逻辑，构造大量的符合条件的参数化用户来进行测试。展开作者回复: 写得太好了。真正的理解了我要表达的内容。
共 2 条评论10
小呀么小二郎2020-03-23今日思考题： 参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？ 参数化数据分析时的重点是业务逻辑，比如数据量、数据来源、参数的多少以及数据分布是否与生产一致。 参数化数据要根据具体的场景来进行分析，比如有些数据可以重复使用，此场景中的参数化数据量就会少一些；而有些数据只能使用一次，此时就需要根据性能场景要求配置足量的数据。归根结底还是业务逻辑不同。 参数化数据的来源和获取要符合哪些规则？当下不符合获取规则时，会产生什么问题？ 数据的来源和获取要满足生产环境中数据的分布，以及性能场景中数据量的要求。参数过多，会对系统造成过大的压力；参数过少，不符合真实场景，无法测出系统真实的压力。 这节的内容很重要，所谓“磨刀不误砍柴工”，必须要花时间搞清楚业务逻辑，这样才能保证最基本的数据没问题。如果连数据都没弄明白，后面的一切都是徒劳呀！展开作者回复: 你这是要上天了。理解的全对！
5
人心向善2020-10-09那老师登录的点来说，如果被测系统即使允许同一个用户名反复登录系统，当只用一个用户名去模拟并发需求时数据库始终是对这一条数据进行查询，如果用数据库大量的用户去参数化模拟登录，数据库除了先查询第一个，还会去先查询其它用户名是否存在，这个时候数据库的压力和查询一个用户名的压力是完全不一致的。 带来的测试结果就是这并不符合实际场景的需求 更通俗的来举个例子，外卖小哥长期对一个地址送餐，如果在这一条线上必然已轻车熟路，因为他知道哪里是哪里，如果去一个新地址送餐，压力、时间消耗自然就比以前的多得多了展开作者回复: 这个比喻好恰当！
5
月亮和六便士2020-01-16老师，怎么看数据库中数据分布直方图？作者回复: 根据关键列做groupby。
4
善行通2020-01-10参数化数据应该用多少数据量？ 1、之前做性能测试，不会计算使用多少数据，反正找几千条数据做性能测试，如果可以重复使用，就用几个用户做压测。经过老师这样讲解，1、循环场景使用【用户数据=线程个数】2、不可循环使用的数据Tps * 持续时间如【100（pts）x30*60(时间)=180000（条用户数据】 ；明白（配置参数之前，我们需要先判断这个参数是什么类型的数据） 参数化数据从哪里来？ 1、后台数据库中； 2、在脚本执行成功后会将这些数据 insert 或 update 到数据库中； 3、通过模拟业务接口把数据跑进去； 明白：参数化时需要确保数据来源以保证数据的有效性。 参数多与少的选择对系统压力有什么影响？ 1、明白：如果压力工具使用的数据量少，那么应用服务器、缓存服务器、数据库服务器，都将使用少量的缓存来处理，相应消耗资源比较少，测不实际效果； 2、如果压力工具使用的数据量少，那么应用服务器、缓存服务器、数据库服务器，都将使用少量的缓存来处理，导致命中率高，响应实际块； 3、参数取得过多，对系统的压力就会大； 4、参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力 感谢老师总结：对一个系统来说，获取的参数化数据是否合理，会直接影响压力测试的结果有没有意义。 参数化数据在数据库中的直方图是否均衡，这一层学到【如果数据取自于数据图，我们通常要检查一下数据库中的数据直方图。 对于直接从生产上拿的数据来说，数据的分布更为精准。】性能测试，性能测试数据之间影响测试结果。 感谢老师总结的【参数化数据的合理性对性能场景有着举足轻重的作用。通常，我们在做参数化数据之前，需要先分析实际业务的逻辑】 参数化数据的分析重点是哪些？ 1、参数化数据的分析重点是业务逻辑,只有符合逻辑的参数化，对性能测试结果会之间影响。 在不同的场景中为什么参数化数据有如此大的差异？ 1、电商下单压测，如果用重复数据，完全不符合实际业务情况，会导致大量缓存，结果不真实； 2、如果是登录后操作其他业务，就可以用几个用户登录后，进行其重复业务操作压测 参数化数据的来源和获取要符合哪些规则？ 1、通过数据库之间查出来做参数文件 2、通过接口把数据跑出来这样不会破坏表，更真实 当不符合获取规则时，会产生什么问题？ 1、压测结果不真实； 2、影响压测判断；展开作者回复: 觉得真传！！
5
Geek_vivian2020-05-071、参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？ 重点有三个方面：业务逻辑、数据量、数据分布（数据质量） 理解业务逻辑，确定所需数据的类型、数据的数量。在参数化时，数据类型决定了哪些数据可以重复使用，哪些不可以，要根据业务逻辑尽量的接近现实情况，这样才会测试出上线后真实的情况。根据数据类型、TPS、运行时间，才能算出一个至少要准备的数据量。在准备数据时，也要考虑数据分布的直方图，这也需要对业务逻辑进行分析。比如一个搜索引擎的测试，我们需要考虑在多大的数据池中搜索，比如在全国范围内搜索和在一个城市范围内搜索这个数据的直方图不是一个级别的。同样在一个城市范围内搜索，在北京、上海搜索与在地广人稀的城市搜索也是不同的。这就说明了业务逻辑分析的重要性，业务逻辑分析的结果决定了数据量、数据分布的质量。 场景不同，数据量也不同、TPS也不同；比如，设置一个搜索范围为北京的场景，基础数据池为百万级别，TPS假设在500/秒，如果我们要运行场景10分钟，搜索关键词不能重复，我们至少需要准备500*10*60=300000个关键词，多了不限。设置一个搜索范围的基础数据为10万级别的城市，TPS假设在1000/秒，如果我们运行场景10分钟，搜索关键词不能重复，我们至少需要准备1000*10*60=600000个关键词。这仅仅是数据量的说明，还需要考虑关键词的命中率。 2、参数化数据的来源和获取要符合哪些规则？当不符合获取规则时，会产生什么问题？ 个人觉得最主要的规则是尽量靠近上线系统真实情况。不无限靠近系统的真实情况时，可能会造成两种情况，一是上线后宕机，引起经济损失；二是花了重金保证了不宕机，但性价比太悬殊。其实这又回到了测试的价值上，我们是要找到一个性价比的平衡点，还是要找出所有的bug？我觉得可能在工作中，我会出于安全考虑，设置一个业务逻辑上更接近真实情况的场景、一个在接近真实情况场景上再加一定百分比的压力（最后上线的应该是这个）。【我感觉这个问题回答的有点跑偏了，但是确实是想到了这些。】展开作者回复: 想得很好，有扩展就是有更好的理解。
2
Geek_0813772020-03-2610万参数化数据都放在文件里，可能的风险是，参数化文件过大、压测工具加载文件性能差，设置无法成功读取文件，这个问题有同学留言过，老师回答是“放在放数据库或者放redis里”，但是又有一个问题，跑脚本时候怎么读取到里面的数据呢？作者回复: redis和数据库 里都可以。 jmeter中写代码去取就行了，也有相应功能可以用。网上有很多这样做的示例。
共 2 条评论2
赵娜2020-03-21当不知道tps情况下，如何确定参数化的数据量以及设定线程数啊作者回复: 这里面有一个探测尝试的阶段。不知道时就加随意加，再分析出数据量的影响，然后修正场景。
3
新思维2020-01-10请问在性能测试过程中对验证码如何处理？开发屏蔽调还是写成固定值？作者回复: 写成固定值，不还是开发要改代码的吗？ 我通常是把校验去掉或加万能验证码。
2
一步
2021-01-03总的来说：参数化的数据 要尽量和真实业务场景的数据一致，不仅包括数据量大小，数据的分布，数据是否可以循环使用作者回复: 正解。
1
啊啊2020-03-13铺底数据量的计算，在这个系列课程中有介绍吗？作者回复: 生产数据量就是标准。
共 2 条评论1
风中之心2020-03-08但是，由又有一个问题，怎么测试在线用户呢？作者回复: 用模拟真实用户的场景就行了。这个动作之前需要先判断用户的操作习惯和时间间隔。要做的动作还是比较多的。
2
麦兜布熊2020-02-20请问老师，10万参数化数据都放在文件里，可能的风险是，参数化文件过大、压测工具加载文件性能差，设置无法成功读取文件，这种情况怎么办呢作者回复: 放数据库里呗。或者放redis里。
2
小老鼠2020-01-11参数化直方图📊介绍下，本章讲得很好共 1 条评论1
A周黑鸭2020-01-10怎么去测量一个接口的tps是多少？比如登录接口 我要知道这个接口的tps是多少才知道要使用多少参数化数据吗？老师作者回复: 这是个反复验证的过程。看测试的阶段和目标。
2
汐度清风2022-05-09有个疑问，望老师解答：如果压力工具使用的数据量少，那么应用服务器、缓存服务器、数据库服务器，都将使用少量的缓存来处理。 所以，这里不循环使用数据，以免走缓存，测不出来实际压力。但网上也有些做性能的文章说到，在执行性能测试前，会先做数据预热。预热是合理的吗？作者回复: 预热是为了线上稳定运行，是合理的。 预热和使用多少数据来做参数化并不冲突。
- Geek_697d332022-04-27高老师，还有个问题。接口中传参有很多，如何判断哪些参数需要做到参数化呢？？拜托，麻烦看到后一定回复下
作者回复: 每次在真实场景下请求时会变化的数据都是要参数化或者关联的。
- 章鱼2022-03-241、不会参数化导致：数据不均衡、参数化数量不足 2、应该用多少数据量：首先要看这个数据是否可以重复、数据一定要符合生产的分布、数据要真实 3、[目标tps x 持续时间（秒级）」可以计算出参数化数大概的量级。可以根据数据库现有的数据来倒推持续的时间【现有数据/tps/60s = 持续的分钟数】 4、数据种类：存量数据、增量数据 5、构造测试数据的方式：调用API生成、操作数据库生成 6、参数多少的影响：参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。 7、参数化数据：需要符合真实业务数据分布、符合业务场景；要满足性能场景中数量的要求 8、对于业务逻辑：必须要多花时间在业务逻辑上面，要把数据弄明白，否则后面的压测结果会出现偏差，不满足性能要求，一切都是徒劳 9、查看数据库分布直方图：根据关键列做groupby 10、如果有大量的参数数据放在参数化文件里面，参数化文件过大、压测工具加载文件性能差，设置无法成功读取文件，如10万，20万，可以将数据放到：数据库、Redis里面动态获取 11、当不知道tps情况下，如何确定参数化的数据量以及设定线程数：通过探测尝试阶段，分析数据量后，再修正场景 12、铺底数据量的计算：生产数据量就是标准展开
作者回复: 总结的不错哦，加油。
