第四章：JMeter 实战——线程组配置、Sampler 使用、监听器设置、参数化与断言
好，咱们进入 JMeter 实战环节。说实话，JMeter 这工具看着简单，但真正用好它，需要理解几个核心概念。我见过太多人把 JMeter 当成“点一点就能压”的工具，结果压出来的数据根本没法看。
这一章，我会带你过一遍 JMeter 压测的五个关键环节。每个环节我都会结合自己的踩坑经历来讲。你跟着走一遍，基本就能上手了。
核心要点：JMeter 压测脚本 = 线程组（模拟用户） + Sampler（发请求） + 监听器（看结果） + 参数化（造数据） + 断言（验结果）。缺一不可。
4.1 线程组配置——模拟用户行为
线程组是压测的起点。说白了，它就是定义“有多少虚拟用户来打你的系统”。
我个人习惯这样配置：
- 线程数：模拟并发用户数。比如设 100，就是 100 个用户同时在线。
- Ramp-Up 时间：用户启动的时长。设 10 秒，就是 10 秒内启动完 100 个用户。
- 循环次数：每个用户发多少次请求。设 10，就是每个用户发 10 次。
我的经验：Ramp-Up 时间别设太短。我曾经设过 1 秒启动 500 个用户，结果系统直接挂了——不是被压垮的，是被 JMeter 自己搞崩的。建议 Ramp-Up 时间 = 线程数 / 10，比如 100 个线程就设 10 秒。
还有一个容易被忽略的选项——调度器。你可以设置压测持续多久，比如跑 5 分钟。这样比设循环次数更可控。
线程组配置示例：
- 线程数：200
- Ramp-Up：20 秒
- 循环次数：永远
- 调度器：持续时间 300 秒4.2 Sampler 使用——发请求的核心
Sampler 就是真正发请求的组件。最常用的是 HTTP 请求 Sampler。
配置要点：
- 协议：http 或 https
- 服务器名称或 IP：目标地址
- 端口号：默认 80/443
- 方法：GET/POST/PUT/DELETE 等
- 路径：接口路径
- 参数：GET 参数或 POST 表单数据
注意：如果接口需要 Token 或 Cookie，记得加 HTTP 信息头管理器。我见过有人压了半天，结果全是 401——因为没带 Token。
对于 POST 请求，我建议用 Body Data 方式传 JSON。这样更清晰，也方便后续参数化。
HTTP 请求 Sampler 配置：
- 协议：https
- 服务器：api.example.com
- 端口：443
- 方法：POST
- 路径：/order/create
- Body Data：{"userId": "1001", "amount": 99.9}4.3 监听器设置——看结果
压测跑完了，怎么看结果？监听器就是干这个的。
我常用的监听器有这几个：
| 监听器名称 | 作用 | 我的建议 |
|---|---|---|
| 查看结果树 | 看每个请求的详情 | 调试时用，压测时关掉，否则吃内存 |
| 聚合报告 | 统计吞吐量、平均响应时间等 | 必加，核心指标都在这里 |
| 图形结果 | 可视化展示 | 适合汇报用，但别依赖它做决策 |
| jp@gc - PerfMon Metrics Collector | 监控服务器资源 | 需要配合 ServerAgent 使用 |
关键指标解读：
- 吞吐量（Throughput）：每秒处理请求数。越高越好。
- 平均响应时间：所有请求的平均耗时。一般要求 < 200ms。
- 90% 响应时间：90% 的请求都在这个时间内完成。比平均值更有参考价值。
- 错误率：失败请求占比。一般要求 < 1%。
嗯，这里要注意：压测时别开“查看结果树”。我刚开始用 JMeter 时，开着它压了 1000 个用户，结果 JMeter 自己先 OOM 了。后来才知道，这个监听器会把每个请求的详情都存内存里，压测规模一大就扛不住。
4.4 参数化——造数据
压测时，如果所有用户都用同一个账号、同一个商品 ID，那压出来的结果没有意义。因为真实场景下，每个用户的数据都不一样。
参数化就是解决这个问题的。JMeter 提供了几种方式：
- CSV 数据文件：从文件读取数据。最常用。
- 用户定义的变量：手动设置几个固定值。
- 函数助手：用 __Random 等函数生成随机数据。
我个人最推荐 CSV 数据文件。因为它最灵活，数据可以提前准备好。
CSV 文件内容示例（user.csv）：
1001,张三
1002,李四
1003,王五
...
CSV 数据文件配置：
- 文件名：/data/user.csv
- 变量名称：userId,userName
- 分隔符：,
- 是否循环：True
- 是否停止线程：False避坑指南：我曾经用 CSV 参数化时，发现所有用户都用了同一个数据。排查了半天，原来是 CSV 文件编码问题——JMeter 默认用 UTF-8，但我的文件是 GBK。所以，记得检查文件编码。
另外，__Random 函数也很有用。比如生成随机手机号：
${__Random(13800000000,13899999999,phone)}这样每次请求的手机号都不一样，更贴近真实场景。
4.5 断言——验结果
压测时，请求发出去，你怎么知道它成功了？只看 HTTP 状态码 200 是不够的。万一接口返回了 200，但 body 里是错误信息呢？
断言就是用来验证响应内容的。JMeter 提供了多种断言：
- 响应断言：检查响应文本是否包含特定字符串。
- JSON 断言：检查 JSON 响应中的某个字段值。
- 大小断言：检查响应大小是否在预期范围内。
- 持续时间断言：检查响应时间是否超过阈值。
我最常用的是 响应断言 和 JSON 断言。
响应断言配置：
- 模式匹配规则：包含
- 测试模式：success
JSON 断言配置：
- JSON Path 表达式：$.code
- 期望值：0注意：断言不要设得太严格。比如检查“success”字符串，万一接口返回“Success”（大小写不同），断言就失败了。我建议用“包含”模式，而不是“等于”。
还有一个技巧：持续时间断言可以用来做性能阈值。比如要求接口响应时间不超过 500ms，超过就算失败。这样压测报告里就能直接看到哪些请求超时了。
持续时间断言配置：
- 持续时间（毫秒）：500好了，这一章的内容就到这里。线程组、Sampler、监听器、参数化、断言——这五个环节你掌握了，JMeter 压测脚本的基本功就算打牢了。下一章我会讲如何用这些组件搭建一个完整的压测脚本，到时候咱们再细聊。