业务配比 ‖ 性能测试脚本编写

性能测试脚本不同设计可能带来不同的系统表现，性能数据可能不能准确衡量系统性能表现，导致性能测试效果不佳。笔者工作中经常遇到被测试系统功能点较多的情况，这些功能点体现在性能脚本上就是几个、几十个请求，那是不是说每次发起压力就是同时几个或者几十个请求按照录制时请求顺序或者随意顺序一起去对系统施加压力呢，当然不是。

实际做法是性能测试工程师在接收到性能测试需求后需要去做详细的需求调研，其中就涉及到被测试系统的业务模型，这个业务模型一般就是决定几个需要测试的功能点，然后看这些功能点的业务逻辑有没有关联的地方。比如一个P2P投资网站必须是所有人先进到首页，然后一部分人可能没有账号，他需要在首页点击注册按钮去注册然后再返回登录，另一部分人登录后可能选择去投标，也可能在浏览查找合适自己的投资标的的情况。调研了需要性能测试的功能点，剩下的就是和项目组确定业务配比了，一般都是几个人商量后 “拍 脑 袋” 决定的。

需求调研内容明确

我们知道了该系统性能测试时的业务模型，那么现在假设每个功能点就是一个请求，为了根据不同的业务流量去对系统施加压力，在jmeter测试工具上我们有如下两种做法：

随机数设置截图

控制注册和登录比例设置截图

控制登录后投标和查询标的请求比例设置截图

正式压测之前先按照循环次数调试了两次，大家可对比下：

下图为两种实现在10并发和20并发线程数下数据统计：

20并发线程数时压测截图：

上图数据大体相同，但左下位置线条表现不一致，再来个局部的：

多线程组形式实现下的业务模型与单线程组+如果（if）控制器和随机数形式实现的业务模型相比，多线程组实现下注册请求TPS明显比单线程组下的注册请求TPS高，同时根据上述表格中数据可知，在多线程组下注册和登录比基本是在0.5，而单线程组+如果（if）控制器和随机数形式实现下注册和登录比基本在0.25，实际业务模型中约定注册和登录比应为0.25。多线程组下注册与登录比不符合业务模型预期。此数据与预期模型出入的原因欢迎各位一起探讨

但是，相同并发下的两种实现形式，除注册请求外其它请求表现均趋于一致，每次压测的响应时间与Total Throughput也无太大差别。

从脚本编写上来看，多线程组实现显得简洁很多，这也与另一款商业性能测试工具Loadrunner百分比模式下的做法一致，但是目前数据来看，不能精准控制各请求比例；单线程组+如果（if）控制器+随机数实现脚本略复杂，有点绕，但是能做到精准控制请求比例。

tips:本例中投标和查询标的的业务配比是50%：50%，像这种1:1的请求，我们可以借助逻辑控制器中的随机控制器来实现，不需要再弄一个Random Variable来实现。我们假设一个功能点只有一个请求，实际项目中一个功能点会存在多个请求，我们可以用事务控制器包括每一个功能点中的所有请求，然后控制事务控制器比例就行。

本次实践受限于例子中的请求，未体现服务器监控部分，相信实际工作中压测，如果应用均为微服务，相信监控上也能体现出不一样的数据。

本例中讲述了两种在jmeter中实现业务配比的方式，至于到底应该选取哪种方式去实现业务配比，请大家自行选择吧。