本篇文章告急先容Jmeter中下载插件（Jmeter Plugins）
怎样利用监听器插件，线程组插件，梯度压测线程组
测试陈诉必要去关注的数据，怎么看测试陈诉图表
目次
一：插件下载
1：下载地点
2：插件下载
3：下载两个插件
（1）监听器插件
（2）线程组插件
4：下载乐成的标志
二：梯度压测线程组（Stepping Thread Group）
1：This group will start
2：First waitfor
3：Then start
4：Next add
5：thread severy
6：using ramp-up
7：Then hold load for
8：Finally , stop
9：threads every
三：测试陈诉 告急数据
1：TPS吞吐量
2：相应时间
四：运行效果图
1：启动运行
2：退出阶段
五：全局观明确测试图
六：出具测试陈诉
1：测试陈诉
2：测试陈诉分析
（1）相应时间
（2）错误率（可靠性）
（3）吞吐量
一：插件下载
1：下载地点
Install :: JMeter-Plugins.org 附上下载链接地点
在压测场景中，我们通常为⼀点⼀点的徐徐增长线程数，因此必要安装新的插件来⽀持线程数的设置。
通过插件管理⼯具下载其他插件：将该jar文件放到exe文件夹中后，此时我们的Jmeter工具就支持安装插件了，重启
2：插件下载
下载乐成的标志，可以看到这个像蝴蝶一样的图标
3：下载两个插件
（1）监听器插件
点击Available
（2）线程组插件
这里临时修改了一下界面颜色，玄色太高冷了，阿华是屌丝
4：下载乐成的标志
我们的监听器中多了许多选项
我们的线程组中多了许多的选项
二：梯度压测线程组（Stepping Thread Group）
重点明确图上三个打圈的参数 这里指的是 这个线程组中有20个线程，等待0秒后开始压力测试，一开始有0个线程，每3秒，增长5个线程进来，这5个线程必要在1s内启动完毕，
以上图数据为例
1：This group will start
启动多少个线程，同线程组中的线程数
2：First waitfor
等待多少秒才开始压测，⼀般默以为0
3：Then start
⼀开始有多少个线程数，⼀般默以为0
4：Next add
指的是下一次要额外增长的线程数量。比方，当前有 10 个线程在运行，设置 Next add 为 5，那么下一次线程数量会增长到 15 个。
5：thread severy
一组线程（5个）实验完之后，等待3秒后再启动下一组线程
指的是在一组线程实验完之后，等待多长时间再启动下一组线程。也就是相邻两组线程启动之间的时间隔断。
6：using ramp-up
这一组（5个）线程，在1秒内匀称的启动
设置为 1秒，体现在 1 秒的时间内匀称地启动指定命量标线程。比方，设置线程数为 10 个，ramp-up period 为 1 秒，那么 Jmeter 会在 1 秒内徐徐启动这 10 个线程，匀称每秒启动 10 个线程
7：Then hold load for
20个线程启动完成后，不停运行60s
8：Finally , stop
9：threads every
解读——每隔1s，竣事5个线程，可以看到这边是直降，与左边是有区别的
三：测试陈诉 告急数据
1：TPS吞吐量
全称Transactions per Second
2：相应时间
这里通常是一个折线图
逆天，偶然候并发数大概太多，造成莫名其妙的报错，那就在run一次
四：运行效果图
1：启动运行
活泼的线程数折线图
相应时间——由低变高
吞吐量——团体比力安稳
2：退出阶段
活泼的线程数，徐徐降落
相应时间——中心部门比力高
吞吐量 老样子 四平八稳
五：全局观明确测试图
对应过来就是下面这条蓝色的线。
看第一个赤色方框——我们的相应时间低落，吞吐量就上升了
再看第二个赤色方框——我们的相应时间增大的时间，吞吐量就降落了。
这里着实可以得出——我们的相应时间和吞吐量出现负相干的关系
这里仔细的老铁会发现末告终束的的时间，为什么相应时间反而激增了呢？这是由于我们有一个线程哀求不停没有得到相应，我们观察聚合陈诉，列表页，有一个最大的哀求时间为59s，图标中的绿色最高峰也可以看出来。
六：出具测试陈诉
1：测试陈诉
JMeter测试陈诉是⼀个全⾯⽽详细的⽂档，它提供了关于测试执⾏效果的详细信息，资助⽤⼾全⾯评估体系的性能并进⾏性能优化。这份测试陈诉也要交给我们的后端开发同砚（如果有非常的话）
1：⽣成性能测试陈诉的下令
Jmeter -n -t 脚本⽂件 -l ⽇志⽂件 -e -o ⽬录
-n ： ⽆图形化运⾏ （可以明确成背景运行，有 点像Linux中的nohup操纵！）
-t ： 被运⾏的脚本
-l ： 将运⾏信息写⼊⽇志⽂件，后缀为jtl的⽇志⽂件
-e ： ⽣成测试陈诉
-o ： 指定陈诉输出⽬录
举例：
开始实验——等待大概1min左右竣事
末了天生一个first.jtl日志 文件，这个不是重点
重点去我们创建的first文件中检察测试陈诉
双击index.html
静态数据，着实可以明确成我们的聚合陈诉
这里尚有许多数据展示，在左边的菜单栏睁开。
总结：我们测试职员，做出来测试陈诉本质上是从宏观角度去测试项目，去发现题目，但是不能排查题目，详细去办理题目还是我们后端开发职员去做。
2：测试陈诉分析
我们测试职员告急去干的事变还是要从这三方面举行分析
（1）相应时间
如果相应时间凌驾了哀求，代表体系到了瓶颈，相应时间发生变革的缘故起因——我们的体系不稳固啊，偶然快偶然慢，随着并发压力变大而逐步变慢，相应时间变高
（2）错误率（可靠性）
高并发场景下，体系能否正常处置处罚业务
要求：99.99%可靠 99.9999%（也就是我们常说的4个9——10w次哀求只能出现一次错误）
错误率高的缘故起因：
①接口哀求错误
②服务器无法继承处置处罚哀求，到达了瓶颈
③后端体系限流
④熔断
表明：防止由于某个服务的故障而团体瓦解。可以明确成实时止损——比如说给一个场景，电商用户付出场景，忽然微信付出失败率激增，超时严峻，此时我们就先临时把微信付出这个方式先熔断掉，先包管我们团体的这个服务还是齐备的（先保大头）
⑤降级
主动关闭一些非焦点功能，以确保焦点功能正常运行。比如说，某次大型直播，那么直播间体现的用户名称给成一个同一默认的名字
（3）吞吐量
①吞吐量越大，性能越好；吞吐量稳固大概变低，大概体系到达了性能瓶颈。
②吞吐量变革的规律
吞吐量颠簸很大的话，阐明我们体系的性能不稳固；
吞吐量如果是逐步变大，再趋于稳固，阐明我们的并发量在上升，和并发量是强相干的
如果吞吐量逐步变低，我们的并发量也在逐步变低，阐明我们的性能测试要竣事了。
换一个角度，我们并发量在增，吞吐量变低，一样寻常就是体系处置处罚不外来这么多相应了，造成体系卡顿啊什么的。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
发表于 2025-10-14 21:42:26