目录
[（3）在 "线程组" 下添加 "HTTP" 取样器](#（3）在 “线程组” 下添加 “HTTP” 取样器)
[（4）填写 "HTTP请求" 的相关请求数据](#（4）填写 “HTTP请求” 的相关请求数据)
[（5）在 "线程组" 下添加 "查看结果树" 监听器](#（5）在 “线程组” 下添加 “查看结果树” 监听器)
[（6）点击 "启动按钮"，查看接口测试结果](#（6）点击 “启动按钮”，查看接口测试结果)
[4、HTTP Cookie 管理器](#4、HTTP Cookie 管理器)
3、修改登录接口及其他涉及到username和password获取的参数
4、修改线程组中线程数，使得每次取到的username和password都不一样编辑
[3、Stepping Thread Group](#3、Stepping Thread Group)
[（1）Active Threads Over Time](#（1）Active Threads Over Time)
[（3）Response Times Over Time](#（3）Response Times Over Time)
[（4）Transactions per Second（TPS）](#（4）Transactions per Second（TPS）)
一、JMeter介绍
环境要求：使用JMeter要求Java 8或更高的版本。
Apache JMeter是Apache组织基于Java开发的压力测试工具，用于对软件做性能测试。
JMeter工作原理：
1、下载安装JMeter
官网地址：Apache JMeter - Download Apache JMeter
下载好后的路径：
2、打开JMeter
方式一：
下载好后打开bin目录下的 jmeter.bat 文件。双击
方式二：
配置系统环境变量，找到你下载jmeter的文件路径，添加路径，把你复制的路径粘贴上去。
配置好路径后，打开cmd控制平台，输入jmeter。
3、JMeter基础设置
找到 jmeter.properties 文件
把语言设置成中文，如图：
4、JMeter基本使用流程
（1）启动JMeter
（2）在测试计划下添加线程组
（3）在 "线程组" 下添加 "HTTP" 取样器
（4）填写 "HTTP请求" 的相关请求数据
（5）在 "线程组" 下添加 "查看结果树" 监听器
（6）点击 "启动按钮"，查看接口测试结果
5、JMeter元件作用域和执行顺序
在JMeter中，元件的作用域和执行顺序是非常重要的概念。
作用域：
JMeter元件的作用域主要由测试计划的树形结构 中的元件父子关系来确定。
执行顺序：
取样器（sampler）元件内组件不依赖其他元件就可以执行，因此取样器不存在作用问题。
元件作用域值对它的子节点有作用。
其他作用域默认根据测试计划中树形结构来定。
二、重点组件
1、线程组
控制JMeter将用于执行测试的线程数，也可以把一个线程理解为一个测试用户。
线程数：一个线程即一个测试用户，设置发送的请求次数。
Ramp-up时间（秒）：设置性能测试运行时间，单位为秒。
循环次数：
配置指定次数：控制脚本循环执行的次数。
配置循环永远:
需要调度器配置使用。
运行时间：脚本执行时间。
延迟启动时间：脚本等待指定时间才能运行。
2、HTTP取样器
添加必需的配置：
协议主机名/IP
端口：
协议端口号。
请求方法：
路径（目录+参数）。
内容编码（默认为ISO国际标准，但对中文支持不友好，可以使用utf-8）。
参数：
参数可以拼在路径里，也可以写在参数中。
POST参数要放到消息数据中{wd:test}。
3、查看结果树
取样器结果：统计请求相关的信息。
1、Thread Name：线程组名称。
2、Sample time：发送请求时间。
3、Load time：响应时间。
4、Response code：接口响应状态码。
请求 ：HTTP请求的请求头和请求体的详细信息。
响应 ：HTTP响应的响应头和响应体的详细信息。
4、HTTP Cookie 管理器
添加了HTTP Cookie管理器后，会自动存储并发生Cookie。
上面选项默认标准即可。
HTTP Cookie管理器像Web浏览器应用存储和发送Cookie。如果HTTP请求并且响应包含Cookie，则Cookie管理器会自动存储该Cookie，并将其用于将来对该特定网站的所有请求。每个JMeter线程都有自己的"Cookie存储区"。因此，正在测试使用Cookie存储会话信息的网站，每个JMeter线程都将拥有自己的会话。此类Cookie不会显示在Cookie管理器显示屏上，可以使用"查看结果树监听器"查看。
缓存配置可选择 standard（标准）或 compatibility（兼容的），当然也可以手工添加一些Cookie。
5、HTTP请求默认值
添加完后，输入默认请求的URL
这时候，把其他请求上的URL路径删掉，再次启动该请求，也不会保存，设置默认的URL，则会访问默认的URL。
博客中涉及到的接口协议、IP、端口号全都一样，可以单独抽取出来存放在默认值中，其他接口就可以省略不写协议、IP、端口号。
6、用户定义的变量
添加方式：线程组--->配置元件--->用户定义的变量
有时候我们想要在固定的场景里使用参数化，改动后不希望影响到其他的脚本。这时候就可以自定义变量。
使用方式 ：在HTTP请求的取样器中引入定义的变量。${参数名}。
适用场景：变量需要在多个脚本中使用，方便统一管理和修改。
7、CSV数据文件设置
以登录接口为例，当我们执行登录接口的性能测试时，手动配置了用户名和密码固定的username，然后实际使用中不可能只有一个用户登录，为了模拟更真实的登录环境，我们需要提供更多的用户username和password来实现登录操作。
添加方式：线程组--->配置元件--->CSV数据文件设置
操作步骤
1、CSV数据文件设置
文件名 ：填写CSV文件的路径。建议使用绝对路径。
文件编码 ：UTF-8。
变量名称 ：从CSV数据文件中读取的数据需要保存到变量名。有多个变量时用逗号分隔。
是否忽略首行 ：是否从CSV数据文件第一行开始读取。
分隔符 ：要求与CSV数据文件中多列的分隔符一致。
遇到文件结束符再次循环 ：若选择为True，当数据不够的时候会从头去。若选择False，则需要勾选下面的配置，遇到文件结束符停止线程，这里如果不勾选，请求将会报错。
2、编写test.csv文件
如图：
3、修改登录接口及其他涉及到username和password获取的参数
修改完该配置后，登录接口发起请求时将从CSV文件中获取配置好的username和password参数，获取顺序为从上往下依次获取获取。
4、修改线程组中线程数，使得每次取到的username和password都不一样
5、运行结果
8、JSON提取器
接口响应成功后，通过提取返回值对应字段，可以用于其他接口的参数配置。
（1）添加JSON提取器
针对某一个HTTP请求接口添加JSON提取器。
以博客列表页为例子：
JSON操作符参考
| Operator | Description |
|---|---|
| $ | 表示根元素 |
| @ | 当前元素 |
| * | 通配符。所有节点 |
| .. | 选择所有符合条件的节点 |
| .<name> | 子元素 |
| ['<name>'(,"<name>')] | 括号表示子元素或子元素列表 |
| [<number>(,<number>)] | 数组索引或索引列表 |
| [start:end] | 数组切片操作符 |
| [?(<expression>)] | 过滤器表达式。表达式必须评估为布尔值 |
参考文档：https://github.com/json-path/JsonPath
（2）添加JSON配置
我们在查看结果树里面，换成JSON Path Tester，可以测试我们的JSON表达式是否正确，如图：
添加表达式，如图：
（3）使用刚才的配置
在博客列表页的HTTP信息管理头中，选中从用户登录里拿到的token
（4）测试
这是再发起登录页和列表页中的请求，发现两者的token相同。
（5）分析
目录结构如下：
JSON提取器和登录页、列表页同级，所以会从这两个请求中获取 data 信息，把 data 的内容放进 token 中。
从上往下扫描，登录页扫描到data了，就提取出来，列表页就能拿到登录页返回的token了。
那如果登录页和列表页顺序反过来呢？
此时再发起请求，发现报错了，如图：发现列表页并没有拿到token
所以顺序不能变，JSON提取器是从上往下提取的。
我们把JSON提取器放进登录页中，目录结果如下：
也不能拿到token，发现请求的是从上往下执行的
把登录页放第一位就好了。
9、JSON断言
接口发送请求成功，响应码为200并不能完全代表接口请求成功，我们更多需要关注接口响应数据是否符合预期。这时就可以使用JSON断言了。
（1）添加断言
针对某个接口添加断言，如图：给登录接口进行断言
（2）添加JSON配置
正则表达式查询网站：正则表达式 -- 语法 | 菜鸟教程 (runoob.com)
注意：
1、若不选Additionally assert value，表示添加断言值，则可用来判断字段是否存在。
2、选择Additionally assert value，则必须添加 Expected Value 期望的断言值。
3、若不选 Match as regular expression 正则匹配，则 Expected Value 必须填写完整，少一个字符都会导致断言失败。
4、若选择 Match as regular expression 正则匹配，则 Expected Value 可以仅写上部分关键词，即可断言成功。
10、同步定时器
为了达到并发的效果，需要添加同步定时器。
没添加同步定时器前，有多个请求，只要这个请求准备好了，就发送。
添加同步定时器后，设置一个集合点，有多个请求，这几个请求要满足这个集合点的数量，一起发送请求。
同步定时器可以理解为过红绿灯，红灯的时候人都在等绿灯，绿灯后全部人都可以一起过马路了。
JMeter 同步定时器的作用主要在于模拟多用户并发访问的场景，确保多个线程能够同时执行某个操作，以达到真正的并发效果。
当多个线程同时启动时，它们可能会在不同的时间间隔内执行，这样就无法达到真正的并发效果。同步定时器的作用就是将这些线程的执行时间同步，使它们在同一时间点执行。它可以在多个线程之间制造一定的延迟，直到同时到达指定时间点，再同时执行后续的操作。
此外，同步定时器可以理解为集合点，当线程数量达到指定值后，再一起释放，可以瞬间产生很大的压力。这样，可以更好地模拟真实的用户并发访问场景，提高测试的准确性和可靠性。
在性能测试过程中，为了真实模拟多个用户同时进行操作，用来度量服务器的处理能力，可以使用同步定时器来设置集合点。不过，虽然通过加入集合点可以约束请求同时发送，但不能确保请求同时到达服务器，所以只能说是较真实模拟并发。
现在模拟5个请求同时并发执行。
执行顺序如图：
这里同步定时器设置模拟用户数量最好是和线程组里的线程数量相同，或者线程数量是模拟用户数量的整数倍（但线程循环要设为永远，指定时间循环），这样才不会导致有剩余的请求发送不出去（因为要等到达集合点的数量，才能把这些请求一起发送出去）。
11、事务控制器
JMeter 事务控制器的作用主要用于测试执行嵌套测试元素所花费的总时间。这相当于模拟用户进行一系列操作的测试。
在进行页面性能测试或API性能测试时，事务控制器是一个非常重要的工具。它可以帮助测试人员更准确地评估系统性能，尤其是在涉及多个接口或操作的复杂场景中。例如，在订单提交的过程中，可能需要调用多个接口，并且某些接口可能依赖于前一个接口的结果。在这种情况下，使用事务控制器可以将这些接口统一视为一个事务进行性能测试，从而得到更接近真实场景的性能测试结果。
若不添加事务控制器，则一个接口即一个事务。
添加了事务控制器后，可以将多个接口统一放到一个事务控制器下座位一个事务。
如图，把登录页和用户信息放到同一个事务中：
发起请求，查看聚合报告
发现原来的请求依然在，还多了个登录事务。
三、安装插件
地址：Install :: JMeter-Plugins.org
下载完成后把该文件放进lib/ext中，如图：然后再重启JMeter
经过上述操作后，就能发现我们JMeter右上角多了一个蝴蝶logo，如图：
点击蝴蝶logo，进行下述操作。
添加以下插件：
1、下载其他监听器
点击Apply Changes and Restart JMeter等待下载，下载完成后重启JMeter。
2、下载线程组插件
点击Apply Changes and Restart JMeter等待下载，下载完成后重启JMeter。
下载完成后可以看到多了许多配置，如图：
3、Stepping Thread Group
This group will start ：启动多少个线程，同线程组的线程数。
First，wait for ：等待多少秒才开始压测，一般默认为0。
Then start ：一开始有多少个线程数，一般默认为0。
Next，add ：下一次增加多少个线程数。
threads every ：当前运行多长时间后再次启动线程，即每一次线程启动完成之后的持续时间
using ramp-up ：启动线程的时间；若设置为1秒，表示每次启动线程都持续1秒。
thenhold loadfor ：线程全部启动完之后持续运行多长时间。
finally，stop/threadsevery ：多长时间释放多少个线程；若设置为5个和1秒，表示持续负载结束之后每1秒钟释放5个线程。
添加梯度线程组后，把这三个监听器加进去，然后测试上面添加的请求，如图：
启动这个梯度线程组。下面介绍这几个监听器
4、常见监听器
（1）Active Threads Over Time
表示运行的线程数，可以看到，随着时间的变化，线程数随之变多，每隔3秒，增加5个，直到线程数到20停止增长，到后面每隔1秒释放5个线程，和上面我们设置的阶梯线程组一样
（2）聚合报告
从聚合报告可以看到性能测试过程中整体的数据变化。如图：
| 指标 | 说明 |
|---|---|
| Samples | 发起的HTTP请求调用数 |
| Average | 平均响应时间，单位为毫秒 |
| Median | 请求调用响应时间的中间值，也就是50%请求调用的响应时间，单位为毫秒 |
| 90%Line | 90%请求调用的响应时间，单位为毫秒 |
| 95%Line | 95%请求调用的响应时间，单位为毫秒 |
| 99%Line | 99%请求调用的响应时间，单位为毫秒 |
| Min | 请求调用的最小响应时间，单位为毫秒 |
| Max | 请求调用的最大响应时间，单位为毫秒 |
| Error% | 调用失败的请求占比。调用失败一般指响应断言失败或者请求调用出错 |
| Throughput | TPS/QPS，每秒处理的事务数 |
| KB/sec | 每秒网络传输的流量大小，单位为KB。这个指标是以网络传输的大小来衡量网络吞吐量 |
（3）Response Times Over Time
Response Times Over Time 主要用于监听整个事务运行期间的响应时间。在测试过程中，它可以帮助测试人员观察并分析响应时间的实时平均值以及整体响应时间的走向。通过这一监听器，测试人员能够更直观地了解系统在不同时间点的响应性能，从而发现可能存在的性能问题或瓶颈。
Response Time Over Time的图形展示中，横坐标通常代表运行时间，而纵坐标则代表响应时间（单位是毫秒）。测试人员可以根据图形中的趋势线来判断响应时间的稳定性以及是否存在大的波动。例如：如果响应时间在某个时间点突然增加，这可能意味着系统在该时间点遇到了性能问题。
（4）Transactions per Second（TPS）
JMeter中的Transactions per Second（TPS）监听器是一个用于分析系统吞吐量的重要工具。TPS，即每秒处理的事务数，表示一个客户机向服务器发送请求后，服务器做出反应的过程。这个指标反映了系统在同一时间内处理业务的最大能力。TPS值越高，说明系统的处理能力越强。
在使用TPS监听器时，横坐标通常代表运行时间，而纵坐标则代表TPS值。通过监听器展示的图表，可以清晰地看到TPS值随时间的变化情况。在图表中，红色通常表示通过的TPS，而绿色可能表示失败的TPS。这有助于我们快速识别系性能的变化和瓶颈。
四、测试报告
JMeter 测试报告是一个全面而详细的文档，它提供了关于测试执行结果的详细信息，帮助用户全面评估系统的性能并进行性能优化。
生成性能测试报告的命令：Jmeter -n -t 脚本文件 -l 日志文件 -e -o 目录
-n：无图形化运行
-t：被运行的脚步
-l：将运行信息写入日志文件，后缀为 jtl 的日志文件
-e：生成测试报告
-o：指定报告输出目录
命令解析：先把指定的 jmx 文件执行一遍，再生成测试报告，放在当前路径first目录下（还有将运行信息写入日志文件，命名为 first.jtl）。
运行完脚本后，查看对应的文件目录，如图：
测试报告就在 index.html 文件下。
里面的相关数据，JMeter工具里有的，这个报告里面都有。
五、性能分析
通过三大指标来分析性能问题。
1、响应时间
如果响应时间超过了要求，代表系统到了瓶颈。
注意事项：分析在多少线程的情况下发送了超标。
响应时间变化的原因：
1、系统不稳定，有时快有时慢。
2、随着并发压力变大而慢慢变慢，响应时间变高。
2、错误率（可靠性）
高并发场景下，系统是否能够正常处理业务。
要求：99.99%可靠，99.999% (通常企业标准是4个9，军事标准为5个9）
错误率高的原因：
1、接口请求错误。
2、服务器无法继续处理，达到了瓶颈（代码写的不好，内存泄露，硬件资源等）。
3、后端系统限流（系统里配置了不能超过多少并发）、熔断、降级。
（熔断：防止系统因某个服务器的故障而整体崩溃。当电商平台上用户支付时，收银台发现某个支付渠道，如微信支付失败率突增，超时严重，那么就可以临时把这个支付方式熔断掉。
降级：主动关闭一些非核心功能，以确保核心功能的正常运行。某次腾讯视频挂了的时候，用户名称默认显示未腾讯用户，这也是一种降级方式，用兜底名称做展示。）
3、吞吐量
吞吐量越大，性能越好；吞吐量相对稳定或者变低，可能系统达到了性能瓶颈。
吞吐量变化规律：
波动很大：代表系统性能不稳定。
慢慢变高，在趋于稳定：和并发量相关。如果并发量小于吞吐量，慢慢增大并发量，吞吐量也会随之增加。
慢慢变低，并发量也减少了：要么性能测试要结束了，并发减少；也可能是系统变的卡顿，从而导致响应时间变慢，导致单个线程发起的并发量变少。