最后更新：2026-09-04 01:19

实验19 JMeter场景设计与运行¶

难度：★★☆　|　预估时长：__ 分钟

19.1 实验目的¶

掌握 JMeter 线程组场景设计的核心参数（线程数、Ramp-Up、循环次数、调度器）；
掌握出错处理策略（继续 / 停止线程 / 停止测试 / Stop Test Now）；
了解 Ultimate Thread Group 与 Stepping Thread Group 高级场景设计；
掌握 JMeter 场景运行的两种方式：GUI 运行与非 GUI（命令行）运行；
掌握 JMeter 常用监听器（Summary Report、聚合报告）与 Dashboard 报告查看。

19.2 实验环境¶

操作系统：Windows 10 / Windows 11；
工具：JMeter（实验9 已装好）+ JMeter Plugins（jpgc-Standard Set、PerfMon）；
被测系统：人力资源综合服务系统（http://192.168.X.XXX/suthr/logon）；
前置：实验18 的"添加岗位"脚本。

19.3 实验重难点¶

重点：线程组场景参数的含义与搭配；GUI 与非 GUI 运行的命令；聚合报告各列含义。

难点：Ramp-Up 与线程数的关系；出错处理策略的选择；非 GUI 运行生成 Dashboard 报告。

19.4 实验内容¶

19.4.1 线程组场景设计¶

1. 任务描述 掌握 JMeter 线程组（Thread Group）的场景设计参数。

2. 实验步骤

步骤 1：理解线程组本质：JMeter 建立一个线程池，一个线程对应一个模拟用户，模拟虚拟用户的发起点。

步骤 2：取样器错误后要执行的动作（异常处理）： | 选项 | 含义 | | --- | --- | | 继续 | 请求出错后继续运行（推荐，大量并发时个别错误正常，可作性能问题依据） | | Start Next Thread Loop | 出错后余下请求不执行，重新开始下一轮 | | 停止线程 | 出错则停止当前线程（会导致负载不足，一般不设置） | | 停止测试 | 出错则停止所有线程（执行完当前迭代后停止） | | Stop Test Now | 出错立即停止整个测试 |
步骤 3：线程数：运行的线程数，一个线程 = 一个模拟用户。
步骤 4：Ramp-Up Period（秒）：所有线程在多长时间内启动完毕。例如 50 线程 + 10 秒 → 每秒启动 5 个；设为 0 则立刻全部启动。
步骤 5：循环次数：请求重复次数；勾选"永远"则一直运行直到停止。
步骤 6：调度器：勾选后可设置：
- 持续时间（秒）：测试计划持续多长时间；
- 启动延迟（秒）：启动场景后延迟一段时间再运行线程。

线程数和 Ramp-Up 像什么？

50 个线程就像 50 位演员，Ramp-Up 设 10 秒就像"10 秒内分批进场"（每秒进 5 位），而不是一窝蜂冲上舞台；设为 0 则 50 人同时挤上台（瞬间全部启动）。

常见错误与排错

"取样器错误后要执行的动作"别选"停止线程"：出错就停线程会导致负载不足，一般推荐"继续"（大量并发时个别错误正常，可作性能问题依据）；
循环次数勾了"永远"却没有配合调度器设置持续时间，测试会一直跑不会停，别以为程序卡死了。

19.4.2 高级场景设计（插件）¶

1. 任务描述 用 JMeter Plugins 的 Ultimate / Stepping Thread Group 设计浪涌等复杂场景。

2. 实验步骤

步骤 1：安装插件：
1. 下载 Plugins-manager.jar（https://jmeter-plugins.org/install/Install/）；
2. 放到 %JMETER_HOME%\lib\ext 目录；
3. 重启 JMeter，选项菜单最下方出现"Plugins Manager"；
4. 在 Available Plugins 勾选 jpgc-Standard Set，单击 Apply Changes and Restart JMeter。
步骤 2：Ultimate Thread Group：可设置多条线程作业计划（Start Threads Count / Initial Delay / Startup Time / Hold Load For / Shutdown Time），适合浪涌场景（波浪状多波峰）和稳定性测试。
步骤 3：Stepping Thread Group：设置更简单（先启动 N 个线程，然后每隔 N2 秒加 N1 个线程，运行后每隔 N2 秒停 N1 个），适合阶梯递增场景。

浪涌和阶梯场景像什么？

Ultimate Thread Group 的浪涌场景像海浪——一波用户涌上来、退下去，再来一波，适合模拟多波峰；Stepping Thread Group 的阶梯场景像上楼梯——一层一层加人，再加到顶后一层一层下人，适合模拟逐步加压。

常见错误与排错

安装插件后必须重启 JMeter 才能生效（选项菜单最下方出现"Plugins Manager"才算装好）；
插件要去官方站下载 Plugins-manager.jar 并放到 %JMETER_HOME%\lib\ext，放错目录重启后看不到 Plugins Manager。

19.4.3 实例：为"添加岗位"脚本设计场景¶

1. 任务描述 按课件要求为添加岗位脚本配置场景。

2. 实验步骤

步骤 1：在"取样器错误后要执行的动作"选择继续；
步骤 2：线程数：50；
步骤 3：Ramp-Up Period（in seconds）：10；
步骤 4：循环次数：永远；
步骤 5：Delay Thread creation until needed：不勾选；
步骤 6：调度器：勾选；
步骤 7：持续时间（秒）：300；
步骤 8：启动延迟（秒）：10。

常见错误与排错

循环次数选"永远"+ 调度器持续时间 300 秒是"组合拳"：想跑 5 分钟就停，两者必须一起设，漏了持续时间脚本就停不下来；
"Delay Thread creation until needed"按实例要求不勾选，勾了会延迟创建线程，启动节奏与设计不符。

19.4.4 GUI 方式运行场景¶

1. 任务描述 在 JMeter 图形界面中启动/停止测试计划。

2. 实验步骤

步骤 1：单击"运行" → "启动"（或快捷菜单栏的启动图标），开始运行测试计划（运行中"启动"会置灰）。
步骤 2：终止测试两种方式：
- 停止：立即停止所有线程；
- 关闭：线程在当前工作完成后停止（不中断取样器，对话框保持激活直到全部停止）。

GUI 方式适合调试

GUI 可视化、鼠标点控、方便实时查看运行状况，适合调试脚本；但正式压测不建议用 GUI（见下节）。

19.4.5 非 GUI 方式运行场景¶

1. 任务描述 用命令行非 GUI 方式运行，并生成 HTML Dashboard 报告。

2. 实验步骤

步骤 1：理解原因：GUI 界面 + 监听器动态展示很消耗负载机资源，大并发下会影响负载量生成（如非 GUI 100 线程能产生 100 TPS，GUI 只产生 80 TPS）。推荐用非 GUI 方式运行。

为什么正式压测不用 GUI 方式？

GUI 界面和监听器的动态刷新本身也要"吃"负载机的资源——就像跑步机上再站几个围观的人，机器分心去画图，真正发给服务器的压力就打了折扣（100 线程可能只压出 80 TPS）。所以调试用 GUI、压测用命令行。

步骤 2：查看参数说明：执行 jmeter --?。

步骤 3：非 GUI 运行命令示例：

jmeter -n -t D:\Dpan\jmeter\jmeter_scripts\1x\添加岗位.jmx ^
  -l D:\Dpan\jmeter\jmeter_scripts\1x\gw01.csv ^
  -e -o D:\Dpan\jmeter\jmeter_scripts\1x\gw01

参数说明： - -n：非 GUI 模式； - -t：指定测试计划脚本（.jmx）； - -l：结果日志文件（.csv/.jtl）； - -e：生成 Dashboard 报告； - -o：报告输出目录。

步骤 4：运行结束后，报告目录下会生成 content、index.html 等文件，用浏览器打开 index.html 查看。

19.4.6 JMeter 结果监听器¶

1. 任务描述 掌握 Summary Report 与聚合报告的字段含义。

2. 实验步骤

步骤 1：Summary Report（添加：右击测试计划/线程组 → 添加 → 监听器 → Summary Report）： | 字段 | 含义 | | --- | --- | | Label | 取样器别名（不同取样器不要取相同名字，否则统计到同一行） | | #Samples | 取样器运行次数 | | Average | 平均响应时间（毫秒） | | Min / Max | 最小 / 最大响应时间 | | Error % | 出错率 | | Throughput | 吞吐量（TPS） | | Received/Sent KB/sec | 每秒接收/发送流量 |
步骤 2：聚合报告（Aggregate Report）——JMeter 最常用的监听器： | 字段 | 含义 | | --- | --- | | Median | 中位数，50% 的请求不超过该时间 | | 90% / 95% / 99% Line | 90% / 95% / 99% 的请求不超过该时间 | | Error % | 出错率 = 错误请求数 / 请求总数 |
步骤 3：开源监听器（需装 jpgc-Standard Set / PerfMon 插件）：
Transactions per Second：每秒事务数（TPS），X 轴时间、Y 轴事务数；
Response Times Over Time：响应时间过程图；
PerfMon Metrics Collector：监控服务器 CPU、内存、磁盘、网络。注意：被监控服务器上需安装并启动 ServerAgent（默认端口 4444）。
步骤 4：Dashboard 报告（非 GUI 运行生成）关键内容：
APDEX：应用程序性能指数；
Requests Summary：成功/失败请求占比；
Statistics：每个事务的指标摘要（含百分位数）；
Errors / Top 5 Errors：错误及占比、各取样器前五个错误；
Charts：Over Time / Throughput / Response Times 三类图表。

为什么除了平均值还要看 90% Line？

平均值会被少数特别慢的请求"拉平"，看不出多数人的真实体验；90% Line 告诉你"90% 的请求都没超过这个时间"，更能代表大多数用户的感受——就像班级平均分掩盖了两极分化，看"中位数/百分位"才知道大多数人考得怎么样。

常见错误与排错

不同取样器的 Label 不要取相同名字，否则统计会合并到同一行，结果没法区分业务；
用 PerfMon 监控服务器资源时，被监控服务器上必须安装并启动 ServerAgent（默认端口 4444），不启动则监控图没有数据。

19.4.7 实例：运行并查看结果¶

1. 任务描述 运行"添加岗位"测试计划并查看各类结果。

2. 实验步骤

步骤 1：实例1：运行测试计划，添加 Summary Report，查看运行结果；
步骤 2：实例2：添加聚合报告，查看运行结果；
步骤 3：实例3：添加 Transactions per Second、Response Times Over Time、PerfMon Metrics Collector（监控负载机 localhost），运行并查看结果。

图 19-2：jp@gc Transactions per Second 监控图

19.5 实验总结¶

本次实验掌握了以下要点：

一是掌握了 JMeter 线程组场景设计的核心参数（线程数、Ramp-Up、循环次数、调度器）与出错处理策略，会用 Ultimate / Stepping Thread Group 插件设计浪涌/阶梯高级场景（对应实验目的 1、3）；
二是掌握了 JMeter 场景运行的两种方式：GUI 适合调试、非 GUI（命令行 -n -t -l -e -o）是正式压测的推荐方式，并会生成和查看 HTML Dashboard 报告（对应实验目的 4）；
三是掌握了 Summary Report、聚合报告各列含义与 Transactions per Second、Response Times Over Time、PerfMon（ServerAgent）等监听器/监控手段（对应实验目的 5）。

19.6 作业提交¶

提交地点：吾爱作业网
提交资料：
线程组场景设计参数截图；
非 GUI 运行命令行与生成的 Dashboard 报告（index.html 浏览器打开）截图；
聚合报告 / TPS 图截图。
不会做时填写"心得感悟"（1~50 字）。

19.7 知识检测¶

[ ] （填空）50 个线程、Ramp-Up 设 10 秒，则每秒启动 5 个线程；Ramp-Up 设为 0 则立刻全部启动。
[ ] （填空）非 GUI 运行命令中，表示"非 GUI 模式"的参数是 -n。
[ ] （选择）线程组"取样器错误后要执行的动作"，大量并发场景一般推荐选（）。
A. 继续　B. 停止线程　C. Stop Test Now　D. Start Next Thread Loop

查看解析

正确答案：A。大量并发时个别错误属正常现象，选"继续"可继续运行并把错误作为性能问题依据；"停止线程"会导致负载不足，一般不设置。

[ ] （选择）用 PerfMon Metrics Collector 监控服务器 CPU / 内存 / 磁盘 / 网络，需在被监控服务器上安装并启动（）。
A. ServerAgent（默认端口 4444）　B. Plugins Manager　C. Debug Sampler　D. 察看结果树

查看解析

正确答案：A。被监控服务器上必须安装并启动 ServerAgent（默认端口 4444），PerfMon 才能采集到数据。

[ ] （选择）聚合报告中"90% Line"的含义是（）。
A. 90% 的请求响应时间不超过该值
B. 出错率为 90%
C. 90% 的线程已启动
D. 吞吐量达到 90%

查看解析

正确答案：A。90% Line 表示 90% 的请求响应时间不超过该值，比平均值更能反映大多数用户的真实体验。

本课相关资源¶

序号	资源名称	类型	说明
1	任务2.3.9 JMeter-场景设计.pptx	课件	线程组、插件场景
2	任务2.3.10 JMeter-场景运行-GUI运行.pptx	课件	GUI 运行
3	任务2.3.11 JMeter-场景运行-非GUI运行.pptx	课件	命令行运行、Dashboard
4	任务3.1 基于JMeter结果分析.pptx	课件	Summary Report、聚合报告、监控

实验素材下载

点击下方链接获取本节课全部资源（含课件、任务清单、安装包等）： 🔗 夸克网盘