前面几篇文章已经介绍完一个电商从注册登录到购物下单的典型场景的 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
t
RegisterLogin
.
jmx
2）在grafana中查看运行数据
从数据中简单的分析，可以看到：
线程数在设定的120秒时间内均匀的从0递增至20
错误率在38分30秒的时候出现剧增，而这个时候的线程数为5，说明在 ActiveUser达到5的时候系统出现了问题造成错误率陡增。
从错误率和响应时间来看，结果较差的接口主要集中在下单流程这块，而首页的响应时间也很大，很可能是因为首页相关的表数据是和订单的表数据有关联的，因而订单的响应时间增加也会造成首页的耗时增加。
- 插件添加后在如下位置选择
打开后的面板如下：
现在可以设置当平均响应时间大于200ms持续10秒，平均延迟时间大于300ms持续10秒或者错误率大于1%持续5秒时测试停止。
可以看到当我们的响应时间持续10秒超过200ms时，测试自动停止了。
总结
客户端方面的电商压测实战学习暂时到这里了，后面如果还想继续深入学习就需要关注服务端的指标了，依然可以结合 docker+grafana+prometheus的方式来监控服务端的各项指标进行分析。
关于更多服务端性能监控与分析接口自动化测试，这里推荐霍格沃兹测试学院出品的 《测试开发从入门到高级实战》系统进阶班课程。可能是业界最具深度、最贴近大厂一线实践的测试开发课程。
4 个月由浅入深，强化集训，测试大咖思寒领衔亲授，通过 8+ 企业级项目实战演练，带你一站式掌握 BAT 测试开发工程师必备核心技能（对标阿里巴巴P6+，挑战年薪50W+）！学员直推 BAT 名企测试经理，普遍涨薪 50%+！
往期回顾
- 实战 | JMeter 典型电商场景(下单/支付)的性能压测
- 实战 | 基于JMeter 完成典型电商场景(首页浏览)的性能压测
- 实战 | Docker+Jmeter+InfluxDB+Grafana 搭建性能监控平台
- 实战 | 电商业务性能测试(二): Jmeter 参数化功能实现注册登录的数据驱动
- 实战 | 电商业务的性能测试(一): 必备基础知识