本篇文章主要介绍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测试报告是⼀个全⾯⽽详细的⽂档，它提供了关于测试执⾏结果的详细信息，帮助⽤⼾全⾯评估系统的性能并进⾏性能优化。这份测试报告也要交给我们的后端开发同学（如果有异常的话）
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）吞吐量
①吞吐量越大，性能越好；吞吐量稳定或者变低，可能系统达到了性能瓶颈。
②吞吐量变化的规律
吞吐量波动很大的话，说明我们系统的性能不稳定；
吞吐量如果是慢慢变大，再趋于稳定，说明我们的并发量在上升，和并发量是强相关的
如果吞吐量慢慢变低，我们的并发量也在慢慢变低，说明我们的测试>性能测试要结束了。
换一个角度，我们并发量在增，吞吐量变低，一般就是系统处理不过来这么多响应了，造成系统卡顿啊什么的。
![[mybatis]resultMap详解](/images/no-images.jpg)
