前面几篇文章已经介绍完一个电商从注册登录到购物下单的典型场景的 Jmeter 压测脚本，具体可参考前期文章：基于电商模式的性能测试(五)-基于 Jmeter 完成一次日常典型电商场景的压测(下单-支付)。在实际压测前，我们还需要对场景做适当的调整。从 ThreadGroup 中看，我们的 Thread 会在某个时间点同时起多个，而日常场景中我们需要的可能是一个递增的梯度加压的方式。

为了实现梯度递增，我们就需要借助于插件 UltimateThreadGroup 先看下 UltimateThreadGroup 插件的面板信息，如下：

• 参数解释：

• 
  

• StartThreadsCount：当前行启动的线程总数

• InitialDelay/sec：延时启动当前行的线程，单位:秒

• StartupTime/sec：启动当前行所有线程达峰值所需时间，单位:秒

• HoldLoadFor/sec：当前行线程达到峰值后的稳定加载时间，单位:秒

• ShutdownTime：停止当前行所有线程所需时间，单位:秒

• 文字的描述还是稍显晦涩， UltimateThreadGroup 插件有个很好的地方就是下方的图表，它会根据你的设定而展示出趋势图，那么现在我们设定如下参数：

• StartThreadsCount：100

• InitialDelay/sec：10 秒

• StartupTime/sec：200 秒

• HoldLoadFor/sec：100 秒

• ShutdownTime：10 秒从插件的趋势图我们可以看到在延迟 10 秒后 100 个线程在 200 秒时间内逐步从 0 递增至 100，然后持续 100 秒的时间，最后在 10 秒的时间内有逐步从 100 递减到 0。当然你还可以继续添加 ThreadSchedule,趋势图会帮你绘制出综合的线程运行趋势：

1） 选择插件 UltimateThreadGroup

2）将写好的 Jmeter 脚本整体移至 UltimateThreadGroup 下

3）现在我们需要的场景是：

• 开始我们需要在 60 秒的时间内起是 10 个 thread，然后保持运行

• 接着我们继续在 60 秒的时间内再起 10 个 thread，然后和开始的 10 个线程一起保持运行 100 秒后结束

  
  

  具体设置如下：

1）命令启动，实际运行脚本期间会用命令行的方式，减少客户端自身运行性能造成的测试影响 1.$ jmeter

n

tRegisterLogin.jmx2）在 grafana 中查看运行数据

从数据中简单的分析，可以看到：线程数在设定的 120 秒时间内均匀的从 0 递增至 20

错误率在 38 分 30 秒的时候出现剧增，而这个时候的线程数为 5，说明在 ActiveUser 达到 5 的时候系统出现了问题造成错误率陡增。

从错误率和响应时间来看，结果较差的接口主要集中在下单流程这块，而首页的响应时间也很大，很可能是因为首页相关的表数据是和订单的表数据有关联的，因而订单的响应时间增加也会造成首页的耗时增加。

• 插件添加后在如下位置选择

打开后的面板如下：

现在可以设置当平均响应时间大于 200ms 持续 10 秒，平均延迟时间大于 300ms 持续 10 秒或者错误率大于 1%持续 5 秒时测试停止。

可以看到当我们的响应时间持续 10 秒超过 200ms 时，测试自动停止了。总结客户端方面的电商压测实战学习暂时到这里了，后面如果还想继续深入学习就需要关注服务端的指标了，依然可以结合 docker+grafana+prometheus 的方式来监控服务端的各项指标进行分析。

点击下方链接免费领取：性能测试+接口测试+自动化测试+测试开发+测试用例+简历模板+测试文档

http://qrcode.testing-studio.com/f?from=infoQ&url=https://ceshiren.com/t/topic/22265