Jmeter超详细使用教程
参考资料：https://www.byhy.net/
文章目录
- 1.Jmeter性能测试理论
- 2.线程组与取样器
- 3.运行与监听器
- 3.1 运行
- 3.2 监听器
- 4.HTTP请求默认值设置
- 5.录制网站流量
- 6.模拟间隔时间
- 7.执行压力测试
- 8.统计报表与测试报告
- 8.1 统计报表
- 8.2 dashboard 产生图表
- （1）APDEX表格
- （2）JMeter 性能测试的统计报表
- （3）Charts
1.Jmeter性能测试理论
性能测试是：验证 在 各种性能负载场景下 ，系统的表现是否符合预期。
一个性能测试场景， JMeter称之为 test plan ，中文翻译为 测试计划 。
实际上，一个 JMeter的测试计划 对应 性能测试的一个场景，其实也就是一个 测试用例 。
应该先准备好 性能测试用例， 然后再用JMeter对应配置好一个测试计划来对应它。
每个测试计划都可以保存在一个单独的文件中。
JMeter的测试计划，具体里面的内容（怎么测），根据你设计好的测试用例，在这个下面添加相应子节点定义。
首先，必须定义用户访问的行为。 就是用户 先访问哪个网页，发出哪些HTTP请求，再访问哪个网页，发出哪些HTTP请求。
根据用例，往往需要模拟 多种 用户行为， 每种行为的用户有多少个。
JMeter 把一个用户的行为 用一个线程来执行。
JMeter 把同一种用户的行为和数量， 用线程组来定义，代表有一批用户，都是这样的行为。
JMeter 把每个节点称之为 element ，翻译为中文叫 元件 ，或者 元素
根据用例，往往需要模拟 多种 用户行为， 每种行为的用户有多少个。
JMeter 把一个用户的行为 用一个线程来执行。
JMeter 把同一种用户的行为和数量， 用线程组来定义，代表有一批用户，都是这样的行为。
JMeter 把每个节点称之为 element ，翻译为中文叫 元件 ，或者 元素
2.线程组与取样器
比如，现在我们要做的一个性能测试用例 需要模拟的行为 如下：
第1种行为(用户数量 5个)：
先访问首页，再访问 单课页 ，再访问 新闻页
第2种行为(用户数量 10个)：
先访问首页，再访问 专题页 ，再访问 新闻页
我们就要定义2个线程组，对应这两种行为的用户。
添加线程组：
线程组讲解：
这里我将线程组名称改为用户行为1
-
线程数：用户数量
-
Ramp-Up 时间意思是 所有用户上线的总时间，以秒为单位。比如5，就表示总共耗时5秒，如果是 5个用户，那就意味着 每隔1.25秒上线一个： 5秒/(5-1) = 1.25
-
循环次数意思是 每个用户 做线程组里面定义的动作行为多少轮。 缺省就做一轮。
现在定义每一个线程组中用户行为是什么
比如第一个行为先访问首页，再访问 单课页 ，再访问 新闻页，这个页面的访问怎么样用jmeter来模拟呢
前提：用户访问网页和在网页上这些操作实际上是对应了一个个的http的请求
jmeter工具就是模拟用户向网页发出一个一个的http请求，其中
**一个具体的请求，是通过 Sampler 取样器 来 定义的，**通常最常用的就是这个 HTTP请求取样器。
添加取样器：
结果
-
协议：http/https
-
服务器名称或者ip：就是在目标网页点击f12后显示的Remote Address地址
-
端口号：缺省值，不填默认就是80
-
路径：首页就是/，不带任何其他的
还有很多其他请求
此时的路径就是在后面加上url新的部分
这样一个一个请求的添加太过麻烦，后面会讲解录制的方法
3.运行与监听器
3.1 运行
接下来就可以运行一下看看。
注意，运行JMeter 有2种运行模式： GUI 图形界面模式 和 CLI 命令行模式
前者是开发调试用的，后者才是真正执行压力测试时用的
现在就是开发阶段，当然先使用 图形界面模式，等调试没有问题，再使用命令行模式
3.2 监听器
图形界面运行后你会发现什么也没发生，在图形界面中，
我们要查看结果，就是加 Listener 监听器 。
最常见的就是 ViewResultTree查看结果树 ，里面会显示HTTP请求具体的细节的信息。
结果树分析
结果有三个页面：取样器结果、请求、响应数据三个界面
取样器结果
- Thread Name:线程组名称
- Sample Start:开始执行时间
- Load time:从发出请求前 到 接收完所有响应的时间 如果是长消息， 往往时长 >= lantency，因为有多个响应
- Connect Time:jmeter 和 被测系统 建立 TCP 连接的时间，包括3路握手时间
- Latency:从发出请求前 到 接收完第一个响应的时间
- Size in bytes:整个响应消息的大小(字节)
- Sent bytes:发送请求大小(字节)
- Headers size in bytes:响应消息头大小(字节)
- Body size in bytes:响应消息体大小(字节)
- Sample Count:1
- Error Count:0
- Data type (“text”|“bin”|“”):text
- Response code:响应码
- Response message:状态码
请求
包含请求体和请求头
响应数据：服务端响应的数据
4.HTTP请求默认值设置
测试过程中，被测系统换了， 就要换配置的地址， 要手动修改 请求参数，请求取样器多了， 就非常麻烦了。
每个请求服务器地址之前是写死的，但它是会动态变化的，一个一个改实在太过麻烦，所以有一个配置元件：HTTP请求默认值来帮我们解决这个问题
根节点 - 添加 -配置元件 - HTTP请求默认值
协议和服务器名称如果用一样的话，可以取固定值即可，这样大家都是用这个协议和服务器
5.录制网站流量
一个一个复制请求的路径实在太过麻烦，这里
JMeter提供了录制浏览器的请求的方法，使用的是代理抓包的机制。
步骤：
-
确保
HTTP请求默认值里面的服务器IP 和录制的网址一致否则录制时，每个HTTP请求里面都会带上IP，还得手工修改删除，不利于统一使用
HTTP请求默认值里面的服务器IP。
-
在整个测试计划下面添加
HTTP代理服务器英文叫
HTTP(S) Test Script Recorder
翻译问题，我这里叫作HTTP(S)测试脚本记录器
步骤：
根结点 - 添加 - 非测试元件 - HTTP代理服务器
- 这里我们新开一个线程专门用来录制，后面复制粘贴给原线程组即可
- 在
新线程组里面 添加逻辑控制器 -> 录制控制器
-
设置
HTTP代理服务器- 分组 选项 选择：
将每个组放到新的事物控制器中
- 分组 选项 选择：
目的是将每个界面的操作分成一组一组的，使得结构更加清晰，且在指标中会将整个界面的指标一起计算
-
如果你需要录制时过滤掉一些请求
点击Request Filtering 配置页，
排除模式下 添加 你要 过滤掉 不抓取的 的类型资源 ，使用的是正则表达式
比如
(?i).*\.(bmp|css|js|gif|ico|jpe?g|png|swf|eot|otf|ttf|mp4|woff|woff2)就是排除 访问 所有上述扩展名的 HTTP请求。
detectportal\.firefox\.com.*就是排除 所有 访问
detectportal.firefox.com的请求。
-
点击代理服务器的启动按钮
权威认证，不用管
- 会弹出录制窗口
-
设置浏览器代理为 本机（localhost） 的 8888端口，进行对应的界面操作
应该发现抓到了相应的请求。
所以我们的浏览器要配置以后的http请求都发到本机的8888端口上
这里说一下Edge的配置浏览器代理
-
打开Edge浏览器的设置
-
左上角打开菜单栏找到扩展
-
-
搜索switchomega并下载插件
新建一个情景模式，更改代理协议为HTTP，代理服务器选择本机的一个ip地址即可
- 选择Disable cache每次刷新会自动清除缓存
-
继续其它场景的录制和拖动
-
结束录制，修改浏览器设置，取消代理
-
录制结果：
可以改名字以示区分：
- 接下来把每一组复制给我们最开始设置的线程组即可
- 录制完之后，接下来验证用户行为
用户行为1 - 验证 -查看结果树，可以把之前抓到的请求再发送一遍，看看对不对
6.模拟间隔时间
场景1中两组请求中间没有间隔，不符合实际情况。因为用户会在某个界面停留一段时间，不会立刻离开
怎么让它们有间隔呢？
可以使用 JMeter的 定时器 Timer
定时器 执行优先级高于 取样器， 会先暂停， 可以放在下一个消息的前面
也可以使用 取样器 里面的 测试活动 flow control action 取样器
正常在最后添加即可，意思是发完最后的请求会等待一段时间
7.执行压力测试
界面部分会消耗我们的性能，所以应该在命令行运行
真正实施性能测试应该在命令行模式下运行，命令格式如下：
d:\tools\apache-jmeter-5.4.1\bin\jmeter -n -t loadtest-case1.jmx -l log.jtl
-
注意JMeter的路径替换为你的安装路径
-
-n 代表是命令行运行，占用服务器 / 本地资源极少，支持长时间、高并发的性能测试（注意：如果不加
-n，会直接启动 JMeter 的图形界面，而非运行测试。） -
-t loadtest-case1.jmx：指定要运行的测试计划文件（.jmx 格式） -
-l log.jtl：指定测试结果的输出文件（.jtl 格式）
.jtl是 JMeter 默认的结果文件格式（本质是 CSV/XML 格式），后续可通过 JMeter 的图形界面（如 “聚合报告”“查看结果树”）导入该文件，生成可视化报表；
8.统计报表与测试报告
8.1 统计报表
将上面jtl格式文件改成csv文件，改的会比较清楚一点
- timeStamp：记录请求发起的时间
- elapsed：从发起请求到完全接受响应数据的总时间
- label：请求标签 / 名称。也就是Jmeter的采样器的名称，用于区分不同请求
- responseCode：响应状态码
- responseMessage：响应信息
- threadName：线程名称
- dataType：响应数据类型
- success：请求是否成功
- failureMessage：失败信息
- bytes：响应数据大小（接收字节数）
- sentBytes：请求数据大小（发送字节数）
- grpThreads：当前线程组活跃线程数量，记录该请求执行时，所属线程组的并发线程数（当前正在运行的线程数）
- allThreads:全局活跃线程数，记录该请求执行时，所有线程组的总并发线程数（全局并发量）
- URL：完整的请求目标地址（含协议、域名、路径、参数）
- Latency：从请求发起后，到首次接收服务器响应数据的时间
- IdleTime：线程发起该请求前的空闲时间（通常由 “定时器” 控制，如思考时间）
- Connect：建立网络连接（TCP 三次握手）的时间
8.2 dashboard 产生图表
d:\tools\apache-jmeter-5.4.1\bin\jmeter -g log.jtl -o report1
就会产生report1目录，里面的index.html 打开就是报告
注意 -o 后面的目录 一定要不存在，或者内容为空，否则会报错。
（1）APDEX表格
-
APDEX：用户满意度统计数据，应用性能指数，取值范围0-1。1 表示所有用户都满意，0 表示所有用户都不满意。
计算公式：
(满意样本数 + 容忍样本数/2) / 总样本数 -
T (Toleration threshold)，定义 “容忍响应时间” 的临界值。若请求响应时间≤T，用户满意；若 T < 响应时间≤F，用户容忍（体验有瑕疵但可接受）。
-
F (Frustration threshold)（挫败阈值），定义 “挫败响应时间” 的临界值。若请求响应时间 > F，用户挫败（体验极差，可能放弃操作）。
通常 F=4T（行业通用经验值）。
-
Label：对每一种请求都单独统计
其中 APDEX (Application Performance Index) 里面的 T (Toleration threshold) 和 F (Frustration threshold) 可以通过 JMeter 工具 bin 目录下面的 user.properties 配置文件里面 这两个选项来设置
jmeter.reportgenerator.apdex_satisfied_threshold
jmeter.reportgenerator.apdex_tolerated_threshold
（2）JMeter 性能测试的统计报表
从多个维度分析系统 / 接口的性能表现，以下是各列的详细解读：
| Label（请求标签） | 对应测试中每个请求的名称（如接口路径、资源名称），用于区分不同请求。 | 按标签可单独分析某一接口 / 资源的性能表现。 |
|---|---|---|
| #Samples（样本数） | 该请求的总执行次数。 | 反映请求的 “并发 / 调用规模”，结合其他指标判断高并发下的稳定性。 |
| FAIL（失败数） | 请求执行失败的次数。 | 直接体现系统稳定性，若数值 > 0 需排查错误原因（如接口报错、超时等）。 |
| Error %（错误率） | 失败数占样本数的百分比。 | 核心质量指标，0.00% 表示所有请求均成功，若 > 0 需重点关注。 |
| Average（平均响应时间） | 所有请求响应时间的平均值（单位：ms）。 | 性能核心指标之一，反映请求的 “平均耗时”，数值越小性能越好。 |
| Min（最小响应时间） | 所有请求中耗时最短的一次（单位：ms）。 | 体现系统的 “最优性能”，可辅助判断资源空闲时的响应速度。 |
| Max（最大响应时间） | 所有请求中耗时最长的一次（单位：ms）。 | 性能风险点指标，若数值过大，可能存在偶发的性能瓶颈（如资源争抢、超时）。 |
| Median（中位数响应时间） | 将所有响应时间排序后，位于中间位置的数值（单位：ms）。 | 比平均值更能反映 “中间水平” 的性能，避免极端值干扰。 |
| 90th pct（90% 百分位响应时间） | 90% 的请求响应时间≤该数值（单位：ms）。 | 关键用户体验指标，代表 “绝大多数用户” 的耗时上限，若过高则大部分用户会感知到慢。 |
| 95th pct（95% 百分位响应时间） | 95% 的请求响应时间≤该数值（单位：ms）。 | 比 90% 百分位更严格的用户体验指标，反映 “绝大多数 + 部分极端” 用户的耗时上限。 |
| 99th pct（99% 百分位响应时间） | 99% 的请求响应时间≤该数值（单位：ms）。 | 极端场景下的用户体验指标，代表 “几乎所有用户” 的耗时上限，若过高则少数用户会遭遇极慢体验。 |
| Throughput（吞吐量） | 单位时间内处理的事务数（通常以 “Transactions/s” 为单位）。 | 系统 “处理能力” 的核心指标，数值越大，系统吞吐量越强。 |
| Network Received（网络接收量） | 该请求接收的总数据量（单位：KB）。 | |
| Sent(网络发送量) | 该请求发送的总数据量（单位：KB）。 |
（3）Charts
响应时间随时间变化”（Response Times Over Time）图表
之前都是报表，Charts里面都是图，可以提供更直观的信息
- 横轴（Elapsed Time）：测试的 “流逝时间”，这里粒度是 1 分钟（granularity: 1 min），从 11:21:10 到 11:21:20，覆盖约 10 分钟的测试周期。
- 纵轴（Average Response Time in ms）：“平均响应时间”，单位是毫秒（ms），数值越小代表性能越好。
- 多条曲线：每条曲线对应不同请求或不同统计维度的响应时间变化（如不同接口、不同百分位的响应时间）。
活跃线程随时间变化”（Active Threads Over Time）图表
用于展示 JMeter 性能测试中并发用户数（活跃线程数）的动态变化过程，是分析 “并发策略执行情况” 和 “系统并发承载能力” 的关键可视化工具。
- 横轴（Elapsed Time）：测试的 “流逝时间”，粒度为 1 分钟（granularity: 1 min），时间范围从 11:21:10 到 11:21:20，覆盖约 10 分钟的测试周期。
- 纵轴（Number of active threads）：“活跃线程数”，即当前同时运行的并发用户数（线程数），数值越大代表并发压力越强。
- 黄色曲线 / 填充区域：代表 “用户行为 1” 这个线程组的活跃线程变化趋势，填充区域直观展示了不同时间点的并发量区间。
字节吞吐量随时间变化”（Bytes Throughput Over Time）图表
展示 JMeter 性能测试中数据传输速率的动态变化，是分析系统 “数据处理能力” 和 “网络传输效率” 的关键工具。
- 横轴（Elapsed Time）：测试的 “流逝时间”，粒度为 1 分钟（granularity: 1 min），时间范围从 11:21:10 到 11:21:20，覆盖约 10 分钟的测试周期。
- 纵轴（Bytes /sec）：“字节 / 秒”，即每秒传输的字节数，数值越大代表数据传输速率越高。
- 曲线与图例
- 黄色曲线：
Bytes received per second（每秒接收字节数），反映从服务器获取数据的速率； - 蓝色曲线（本图中未明显展示，可忽略）：
Bytes sent per second（每秒发送字节数），反映向服务器发送数据的速率。
- 黄色曲线：
