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

实验18 JMeter脚本开发¶

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

18.1 实验目的¶

知识目标：理解性能测试"环境设计→场景设计→用例设计→脚本开发"的流程，理解 JMeter 测试计划四要素（测试计划、线程组、取样器、监听器）及各元件作用。
技能目标：能在 JMeter 中搭建"添加岗位"脚本，独立添加线程组、Cookie 管理器、HTTP 请求、默认值、察看结果树，并运用思考时间、检查点、参数化、关联、集合点、事务六大技巧完善脚本。
素养目标：养成"先设计后录制、用参数化/检查点保证脚本健壮性"的规范脚本开发习惯。

18.2 实验环境¶

操作系统：Windows 10 / Windows 11；
工具：JMeter（实验9 已装好），需 JDK；
被测系统：人力资源综合服务系统（http://192.168.X.XXX/suthr/logon）；
参数文件：title.dat（岗位名称数据，UTF-8 编码）。

18.3 实验重难点¶

重点：测试计划四要素；HTTP 请求各字段含义；断言（检查点）与参数化（CSV 数据文件设置、函数助手）。

难点：CSV 数据文件设置各选项（忽略首行、分隔符、共享模式）；正则表达式提取器做关联；自动重定向与跟随重定向的区别。

18.4 实验内容¶

18.4.1 性能测试设计与开发概述¶

1. 任务描述 理解测试开发前的三个设计环节。

性能测试开发流程像什么？

性能测试开发流程就像拍电影——先搭场景（环境/场景设计），再写分镜脚本（用例设计），最后实拍（脚本开发）。不先设计就录脚本，等于没剧本就开拍，拍出来也用不了。

2. 实验步骤

步骤 1：测试环境设计：
- 能力验证：保证测试环境与运行环境一致即可；
- 规划能力：设计一个基准环境；
- 性能调优：必须保持测试环境不变，用于衡量调优效果。
- 注意：数据环境很关键——5 万条数据的数据库和空数据库，响应时间完全不同。
步骤 2：测试场景设计：体现用户实际运行环境中有代表性的业务使用情况，包括业务、业务比例、指标目标、监控计数器。
步骤 3：测试用例设计：把场景细化为用例，一个业务描述为操作序列 + 判断成功的准则。例如登录用例：
- 进入登录页面；
- 输入正确的用户名和密码；
- 单击"登录"按钮；
- 登录成功判断：页面显示"欢迎您"文本。
步骤 4：脚本和辅助工具开发：脚本基于"录制"（用工具操作一遍业务），再用参数化、关联、检查点等技巧修改调试。

常见错误与排错

别跳过"环境/场景/用例设计"直接录脚本：没设计就录，后面场景跑偏了很难改；
数据环境要固定：5 万条数据的库和空库响应时间天差地别，设计阶段就要定好数据量。

18.4.2 认识 JMeter 测试计划要素¶

1. 任务描述 掌握 JMeter 测试计划的四个要素。

测试计划四要素像什么？

测试计划四要素就像一场演出的基本配置——一个舞台（测试计划）、一批演员（线程组）、一个动作（取样器）、一个记分牌（监听器），缺一样戏都唱不起来。

2. 实验步骤

步骤 1：启动 JMeter，认识工作区三部分：
- 区域①：目录树（存放测试元件）；
- 区域②：测试计划编辑区（用户定义的变量、线程组设置）；
- 区域③：菜单栏。

步骤 2：测试计划四要素：
1. 测试计划只有一个（根节点）；
2. 至少一个线程组（JMeter 负载靠线程组驱动，类似 LoadRunner 的虚拟用户数）；
3. 至少一个取样器（模拟用户请求，没有取样器脚本无意义）；
4. 至少一个监听器（查看结果、衡量性能）。

常见错误与排错

测试计划只能有一个根节点，多建会混乱；
没有取样器脚本无意义（线程组只发请求，没请求就不产生负载）；
监听器（如察看结果树）正式压测时一定要关，否则大量运行记录极耗机器资源。

1. 任务描述 搭建"添加岗位"脚本的基础骨架。

线程组和 Cookie 管理器像什么？

线程组就像一群"替身用户"——每个线程互相隔离、独立执行同一批任务，模拟多人同时操作。HTTP Cookie 管理器则像浏览器自动记 cookie，免得你每次手动带会话信息。

2. 实验步骤

步骤 1：添加线程组：右击"测试计划" → 添加 → Threads（Users）→ 线程组。
- 线程组相当于多个用户同时去执行相同的一批任务，每个线程互相隔离、互不影响。

步骤 2：添加 HTTP Cookie 管理器：右击"线程组" → 添加 → 配置元件 → HTTP Cookie 管理器（默认即可）。作用：自动记录 Cookie（模拟浏览器）。

步骤 3：添加 HTTP 请求：右击"线程组" → 添加 → Sampler → HTTP 请求。关键字段： | 字段 | 说明 | | --- | --- | | 协议 | HTTP / HTTPS（默认 HTTP） | | 服务器名称或 IP | 主机地址，不要加 http://（JMeter 自动加） | | 端口号 | 默认 80，有端口则填 | | 方法 | GET / POST 等 | | 路径 | 去掉主机地址后的访问链接 | | Content encoding | 编码，一般设 UTF-8 | | 自动重定向 | 只针对 GET/HEAD，不记录重定向过程内容 | | 跟随重定向 | 默认选项，记录重定向过程中的所有请求响应（可做关联） | | Parameters / Body Data | 请求参数，两者二选一 | | Files Upload | 配合 multipart/form-data 上传文件 |

步骤 4：添加 HTTP 请求默认值：右击"线程组" → 添加 → 配置元件 → HTTP 请求默认值。作用：把重复的协议、IP、端口等封装一次、多次使用。
步骤 5：添加察看结果树：右击"线程组" → 添加 → 监听器 → 察看结果树。作用：查看每次请求的取样器结果、请求、响应数据。

性能测试正式跑的时候，记得关掉察看结果树

察看结果树每次运行都记录，大量运行时非常耗费机器资源，正式压测时建议关闭。

18.4.4 实例：搭建"添加岗位"脚本¶

1. 任务描述 把"登录→人资工作台→岗位管理→添加岗位→保存"的操作步骤添加到 JMeter 脚本。

搭建实例像什么？

"添加岗位"实例就像按菜谱做一道菜——把"登录→工作台→岗位管理→添加→保存"一步步加进脚本，顺序不能乱，漏一步就跑不通。

2. 实验步骤

步骤 1：实例1——添加登录页面请求（GET）：
- http://192.168.16.161/suthr/logon 是登录页面，HTTP 请求 GET 方法。
步骤 2：实例2——添加登录请求（POST）：
- http://192.168.16.161/suthr/authenticate；
- 请求参数：username=hrteacher，password=123456。
步骤 3：实例3——完整业务：以人资管理员身份登录 → 人资工作台 → 岗位管理菜单 → 添加岗位按钮 → 输入内容 → 保存 → 返回岗位管理列表。
- 新建脚本 → 添加线程组 → HTTP Cookie 管理器 → HTTP 请求默认值（把协议、服务器 IP、端口号等重复信息放进去）；
- 依次添加各步骤的 HTTP 请求；
- 所有请求添加成功后，添加察看结果树，运行脚本查看。

常见错误与排错

HTTP 请求的"服务器名称或 IP"不要加 http://（JMeter 会自动加，加了反而重复）；
要做关联取动态值，记得用"跟随重定向"（默认项），它会记录重定向过程中的所有请求响应；
实例3 顺序不能错：先登录拿到 Cookie，后续添加岗位请求才能带上会话。

18.4.5 思考时间（定时器）¶

1. 任务描述 给脚本加入合理思考时间，模拟真实用户操作节奏。

思考时间像什么？

思考时间/定时器就像真人操作时的"发呆"——你填完表单总会停顿一下再点下一步，定时器就是模拟这个停顿，让脚本更真实、不会"快得像机器人"。

2. 实验步骤

步骤 1：固定定时器（Constant Timer）：右击 Sampler → 添加 → 定时器 → 固定定时器。
- 让线程按指定时间停顿；延时不计入单个 Sampler 响应时间，但会计入事务控制器时间。
- 对"Java 请求"相当于 LoadRunner 的 Pacing；对"事务控制器"相当于 Think Time。
步骤 2：高斯随机定时器（Gaussian Random Timer）：随机停顿，更接近真实。
- 偏差：浮动范围（毫秒）；固定延迟偏移：固定延迟时间。

步骤 3：定时器执行规则：定时器优先级高于 Sampler，在 Sampler 之前执行（无论位置前后）。
步骤 4：实例：在登录、添加岗位保存之前加上合理的思考时间。

常见错误与排错

定时器在 Sampler 之前执行（无论你把定时器放在请求的上面还是下面），别误以为位置不重要；
固定定时器的延时不计入单个 Sampler 响应时间，但会计入事务控制器时间——算 TPS/事务耗时时要心里有数。

18.4.6 检查点（断言）¶

1. 任务描述 用响应断言判断"登录是否成功"。

检查点像什么？

检查点/断言就像考试对答案——服务器返回 200 不代表业务成功（很多系统出错也返回 200，只是带个"网站忙"提示），断言去响应里找"欢迎使用本系统！"才算真成功。

2. 实验步骤

步骤 1：理解原理：断言组件获取服务器响应数据，按规则匹配；匹配到=正常（看不到提醒），匹配不到=请求失败（结果树中请求名变红色）。
步骤 2：添加响应断言：右击 Sampler → 添加 → 断言 → 响应断言。
步骤 3：关键配置：
- 要测试的响应字段：响应文本、响应代码（200=成功）、响应信息等；
- 模式匹配规则：包括（支持正则）、匹配、Equals、Substring、否（取反）、或者（多模式任一成功）；
- 要测试的模式：填入要匹配的字符串或正则。
步骤 4：查看断言结果：添加监听器 → 断言结果。通过只打印请求名；失败会打印失败原因。
步骤 5：实例：登录成功后页面显示"欢迎使用本系统！"，把它作为检查字段，判断登录是否成功。

常见错误与排错

别只靠 HTTP 200 判断成功：很多系统出错也返回 200，要用响应文本做检查点；
断言匹配不到=请求失败（结果树里变红），看清是"模式写错"还是"真业务失败"。

18.4.7 参数化（CSV 数据文件设置 / 函数助手）¶

1. 任务描述 把"添加岗位"的岗位名称参数化，用多组数据驱动。

参数化像什么？

参数化就像给每个人发不同名字的工牌——不做参数化，100 个线程都用同一个岗位名，会和"岗位名不能重复"冲突报一堆错；参数化让每人用不同数据，更真实地表达负载。

2. 实验步骤

方法一：CSV 数据文件设置

步骤 1：右击线程组 → 添加 → 配置元件 → CSV 数据文件设置。
步骤 2：关键配置：
- 文件名：参数文件路径；
- 文件编码：建议 UTF-8；
- 变量名称（逗号间隔）：与参数文件列对应；
- 忽略首行：跳过 CSV 第一行（标题）；
- 分隔符：默认逗号，Tab 分隔写 \t；
- 遇到文件结束符再次循环 / 停止线程；
- 线程共享模式：所有线程 / 当前线程组 / 当前线程。
步骤 3：查看参数取值：添加 Debug Sampler，在察看结果树中看参数取值。
步骤 4：实例1：创建 title.dat，将岗位名称通过 CSV 数据文件设置参数化。

方法二：函数助手

步骤 1：菜单"选项" → 函数助手，选择 _CSVRead。
步骤 2：配置 CSV 文件路径、文件列号（从 0 开始，第一列为 0）。
步骤 3：单击"生成"，得到函数字符串，复制到请求中引用。
步骤 4：实例2：存放岗位名称的文件通过函数助手 _CSVRead 参数化。

常见错误与排错

CSV "忽略首行"用于跳过标题行，文件第一行是标题才勾，否则会少一条数据；
分隔符默认逗号，用 Tab 分隔要写 \t，写错会导致整列读不出来；
线程共享模式要按场景选（所有线程/当前线程组/当前线程），选错会导致数据分配不对、并发数据重复。

18.4.8 关联（正则表达式提取器）¶

1. 任务描述 把"添加岗位"的岗位类别通过关联实现参数化（从上一个请求响应中提取动态值）。

关联像什么？

关联就像你每次进门都要刷的不同临时门禁码——Session ID 每次访问都重新生成，脚本里写死的旧码会被服务器拒绝，关联就是从上一个响应里动态提取新码再往下用。

2. 实验步骤

步骤 1：添加正则表达式提取器：右击 Sampler → 添加 → 后置处理器 → 正则表达式提取器。
步骤 2：关键配置：
- 引用名称：匹配结果通过此名称访问（${引用名称}）；
- 正则表达式：用于匹配的串；
- 模板： $1$ 第一个模板、 $2$ 第二个， $0$ 全文匹配；
- 匹配数字：0=随机；-1=取所有；
- 缺省值：没匹配到时的默认值。
步骤 3：提取单个字符串示例：匹配 name = "file" value = "readme.txt" 中的 readme.txt：
1 2
正则：name = "file" value = "(.+?)"> 模板：$1$
步骤 4：查看提取结果：添加 Debug Sampler。
步骤 5：实例：将岗位类别通过正则表达式提取器实现关联参数化。

常见错误与排错

正则提取器是后置处理器，必须放在"被提取的请求"之后，放前面取不到值；
模板 $1$ 取第一个分组， $0$ 是全文匹配，别写反；
左右边界区分大小写，写错大小写会匹配不到，提取结果为缺省值。

18.4.9 集合点与事务¶

1. 任务描述 加入集合点（Synchronizing Timer）实现并发同步，加入事务控制器衡量业务处理能力。

集合点和事务像什么？

集合点就像运动会百米起跑的发令枪——所有人（线程）在起跑线前等齐，枪一响同时冲，专门测"同一瞬间并发"。事务就像给一段操作掐表，算这段业务的总耗时。

2. 实验步骤

步骤 1：集合点：右击 Sampler → 添加 → 定时器 → Synchronizing Timer。
Number of Simulated Users to Group by：集合多少人后再执行（不能大于线程组线程数）；
Timeout in milliseconds：超时时间（0=无超时，一直等）。
实例：在"添加岗位保存"前加入集合点。
步骤 2：事务控制器：右击线程组 → 添加 → 逻辑控制器 → 事务控制器。
Generate parent sample：勾选后结果树既显示事务控制器又显示每个取样器；事务成功与否取决于子事务是否都成功（任一失败则事务失败）。
实例：加入"添加岗位"事务。

常见错误与排错

Synchronizing Timer 的"集合人数"不能大于线程组线程数，否则永远等不齐、卡死；
事务控制器勾选 Generate parent sample 后，子事务任一失败则整个事务失败，排查时别只看事务名。

18.5 实验总结¶

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

一是理解了性能测试"环境设计→场景设计→用例设计→脚本开发"的流程，以及 JMeter 测试计划四要素（测试计划、线程组、取样器、监听器）及各元件作用（对应知识目标）；
二是能在 JMeter 中搭建"添加岗位"脚本：独立添加线程组、Cookie 管理器、HTTP 请求、默认值、察看结果树（对应技能目标）；
三是会运用思考时间、检查点、参数化、关联、集合点、事务六大技巧完善脚本，养成"先设计后录制、用参数化/检查点保证脚本健壮性"的规范开发习惯（对应技能与素养目标）。这是性能测试执行（实验19 场景设计与运行）的前提。

18.6 作业提交¶

提交地点：吾爱作业网
提交资料：
"添加岗位"脚本的测试计划树截图；
察看结果树中登录请求成功（含检查点通过）截图；
参数化/关联运行结果截图。
不会做时填写"心得感悟"（1~50 字）。

18.7 知识检测¶

[ ] （填空）JMeter 测试计划四要素中，用来"模拟多个用户同时发请求"的元件是____。（线程组）
[ ] （填空）JMeter 中用来判断"登录是否成功"的检查点组件叫____（断言）。（响应断言）
[ ] （选择）下列关于 JMeter 定时器说法正确的是（）。
A. 定时器在 Sampler 之后执行
B. 定时器优先级高于 Sampler、在其之前执行
C. 定时器延时不计入任何时间
D. 高斯随机定时器是固定停顿

查看解析

正确答案：B。定时器优先级高于 Sampler，无论位置前后都在 Sampler 之前执行；固定定时器才是固定停顿，高斯随机定时器是随机停顿。

[ ] （选择）JMeter 中从上一个请求响应里提取动态值（如 Session ID）用到的元件是（）。
A. CSV 数据文件设置
B. 正则表达式提取器
C. 响应断言
D. 事务控制器

查看解析

正确答案：B。正则表达式提取器（后置处理器）用来做关联，从响应中提取动态值；CSV 是参数化、断言是检查点、事务控制器是掐表计时。

本课相关资源¶

序号	资源名称	类型	说明
1	任务2.1 性能测试设计与开发.pptx	课件	环境/场景/用例/脚本设计
2	任务2.3.1 JMeter脚本开发.pptx	课件	测试计划要素、工作区
3	任务2.3.2 JMeter脚本开发-脚本添加.pptx	课件	线程组/Cookie/HTTP请求/默认值/结果树
4	任务2.3.3 JMeter脚本开发-思考时间.pptx	课件	定时器
5	任务2.3.4 JMeter脚本开发-检查点.pptx	课件	响应断言
6	任务2.3.5 JMeter脚本开发-参数化.pptx	课件	CSV/函数助手
7	任务2.3.6 JMeter脚本开发-关联.pptx	课件	正则表达式提取器
8	任务2.3.7 JMeter脚本开发-集合点.pptx	课件	Synchronizing Timer
9	任务2.3.8 JMeter脚本开发-事务.pptx	课件	事务控制器

实验素材下载

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

实验18 JMeter脚本开发¶

18.1 实验目的¶

18.2 实验环境¶

18.3 实验重难点¶

18.4 实验内容¶

18.4.1 性能测试设计与开发概述¶

18.4.2 认识 JMeter 测试计划要素¶

18.4.3 添加线程组、Cookie 管理器、HTTP 请求¶

18.4.4 实例：搭建"添加岗位"脚本¶

18.4.5 思考时间（定时器）¶

18.4.6 检查点（断言）¶

18.4.7 参数化（CSV 数据文件设置 / 函数助手）¶

18.4.8 关联（正则表达式提取器）¶

18.4.9 集合点与事务¶

18.5 实验总结¶

18.6 作业提交¶

18.7 知识检测¶

本课相关资源¶