4、压测脚本编写（JMeter篇）：线程组配置、Sampler、Listener、断言、参数化、关联
好，咱们进入JMeter脚本编写的环节。说实话，很多刚入行的同学觉得JMeter就是点点点，拖几个组件就完事了。但我在真实项目中踩过不少坑，比如压测到一半发现数据全是重复的，或者断言没写好导致误报。今天我把核心的几个组件掰开揉碎讲清楚。
4.1 线程组配置——压测的“发动机”
线程组是压测的起点。你想想看，没有线程组，Sampler跑给谁看？
核心参数就三个：
- 线程数：模拟的并发用户数。我习惯先设10个线程跑一轮，看看响应时间，再逐步往上加。
- Ramp-Up Period：启动所有线程的时间。比如10个线程设5秒，就是每秒启动2个。千万别设成0，否则瞬间冲击会把服务器打懵。
- 循环次数：每个线程跑几遍。压测时长一般用“持续时间”控制更准。
实战建议：用“调度器”代替循环次数。勾选“永远”，然后设置持续时间（比如300秒）。这样压测时长可控，数据也更稳定。
我曾经遇到一个项目，测试同学设了1000线程、Ramp-Up为0，结果服务器直接挂了。后来发现不是业务扛不住，是瞬间连接数太大导致TCP backlog溢出。嗯，这里要注意——线程数不等于真实并发能力，还要看服务器处理速度。
4.2 Sampler——发什么请求？
Sampler就是你要发的请求类型。最常用的是HTTP请求，但还有JDBC、JMS、FTP等。
HTTP请求配置要点：
- 协议：http或https，注意端口号
- 方法：GET、POST、PUT、DELETE等
- 参数：可以写在URL里，也可以用“参数”标签页添加
- 超时：连接超时和响应超时，我一般设5000ms，太长会拖慢整体压测
小技巧：用“HTTP请求默认值”组件统一管理协议、域名、端口。这样改环境时只改一处，不用每个Sampler都改。
我记得有一次压测，发现响应时间忽高忽低。排查了半天，原来是Sampler里忘了勾选“Keep-Alive”，每次请求都新建TCP连接。加上后，性能提升30%以上。
4.3 Listener——怎么看结果？
Listener是JMeter的“眼睛”。没有它，你跑完压测就是两眼一抹黑。
常用Listener：
| 名称 | 用途 | 注意点 |
|---|---|---|
| 查看结果树 | 调试时看请求/响应详情 | 压测时关掉，否则内存爆炸 |
| 聚合报告 | 统计吞吐量、平均响应时间、错误率 | 最常用的报告组件 |
| 图形结果 | 可视化趋势 | 适合演示，但不适合精确分析 |
| 后端监听器 | 实时推送数据到InfluxDB + Grafana | 生产级压测必备 |
警告：压测时不要用“查看结果树”！我曾经在压测1000并发时开着它，结果JMeter自己先OOM了。建议用“简单数据写入器”把结果存成CSV，压完再分析。
4.4 断言——怎么判断对错？
断言就是检查服务器返回的内容对不对。没有断言，你压测出来的错误率可能是0，但实际全是错误数据。
常用断言：
- 响应断言：检查响应文本是否包含某个字符串。比如登录接口返回“success”
- JSON断言：针对JSON格式的响应，检查某个字段的值
- 持续时间断言：响应时间超过阈值就算失败。我常用这个来监控性能退化
- 大小断言：检查响应体大小，防止返回空数据
我建议每个Sampler至少加一个响应断言。为什么呢？因为有一次我压测下单接口，服务器返回了200，但body里是“库存不足”。如果没有断言，这个请求会被算成成功，压测数据就失真了。
最佳实践：断言要精确，但不要太严格。比如检查“success”比检查完整JSON更稳定。因为接口升级后字段顺序可能变，但关键词一般不变。
4.5 参数化——数据从哪里来？
压测不能所有用户都用同一份数据。比如登录接口，每个用户都要不同的账号密码。这就是参数化要解决的问题。
参数化方式：
- CSV数据文件配置：最常用。把账号密码存在CSV里，JMeter逐行读取
- 用户自定义变量：适合少量固定参数，比如服务器地址
- 函数助手：用
__Random()、__UUID()生成随机数据 - JDBC请求：从数据库查数据，适合复杂场景
CSV配置要点：
- 文件编码用UTF-8，否则中文乱码
- “线程共享模式”选“所有线程”，确保每个线程拿到的数据不重复
- 数据量要大于并发数×循环次数，否则数据会重复使用
避坑指南：我曾经用CSV参数化时，忘了勾选“遇到文件结束符再次循环”。结果压测到一半，所有线程都拿不到新数据，直接报错。所以记得根据场景选择“循环”还是“停止线程”。
4.6 关联——怎么传递数据？
关联是JMeter脚本里最考验功力的部分。说白了，就是把上一个请求的返回值，传给下一个请求用。
典型场景：登录后拿到token，后续请求都要带上这个token。
实现方式：
- 正则表达式提取器：最通用。从响应文本里匹配出需要的值
- JSON提取器：专门处理JSON格式的响应。用JSONPath语法，比正则简单
- 边界提取器：适合HTML等非结构化文本
JSON提取器示例：
// 响应：{"token": "abc123", "userId": 456}
// JSONPath表达式：$.token
// 变量名：myToken
// 后续请求中用 ${myToken} 引用我见过最坑的情况是，正则写得太宽泛，匹配到了多个值。比如响应里有多个“token”字段，结果提取到了错误的值。所以提取器一定要加“匹配数字”，指定取第几个匹配项。
关联调试技巧：在提取器后面加一个“调试取样器”或“查看结果树”，看提取到的变量值对不对。确认无误后再删掉调试组件。
4.7 知识体系总览
下面这张图把本章的核心逻辑串起来了。你对照着看，思路会更清晰。
这张图展示了JMeter脚本的核心流程：线程组驱动Sampler发请求，断言检查结果对不对，参数化提供数据，关联传递上下文，最后Listener收集结果。你写脚本时，就按这个顺序搭组件，基本不会漏。
我的习惯：写脚本前先画个流程图，标清楚哪些数据需要参数化、哪些需要关联。想清楚了再动手，比边写边改效率高得多。
好了，JMeter脚本的核心组件就这些。线程组管并发，Sampler管请求，Listener管结果，断言管校验，参数化管数据，关联管传递。把这六个组件用好，大部分压测场景都能覆盖。