1台机器模拟1000并发，你还在手动测接口？

01 线程组：你的“虚拟用户工厂”

线程组是JMeter的灵魂。它定义了多少用户、什么频率、持续多久。不懂线程组，就等于不会做压测。

核心参数：
- 线程数：虚拟用户数量。1000线程 = 1000个并发用户。
- Ramp-Up时间：用户启动时间。10秒启动1000用户 = 每秒100个用户涌入。
- 循环次数：每个用户执行多少次。1次 = 单次请求，永久 = 持续压到停。

实战场景：
假设你要模拟“双11”瞬间流量。1000用户同时访问登录接口。

配置：
- 线程数：1000
- Ramp-Up：5秒
- 循环次数：1

线程数: 1000

Ramp-Up (秒): 5

循环次数: 1

代码示例（测试计划结构）：

Test Plan

  ├── Thread Group (1000 users, 5s ramp-up)

  │   ├── HTTP Request (POST /login)

  │   ├── HTTP Header Manager

  │   └── View Results Tree

  └── Listeners

      └── Summary Report

> 不懂线程组，压测就是盲人摸象。

进阶技巧：
- 梯度压测：线程数从100递增到1000，观察系统拐点。
- 持续时间：用“持续时间”代替“循环次数”，精确控制压测时长。
- 延迟创建线程：勾选后，线程在Ramp-Up期间才创建，节省资源。

避坑指南：
- 线程数不是越大越好。单机1000线程是上限，超过需要分布式。
- Ramp-Up时间太短（0秒）会导致瞬间CPU飙升，测试结果失真。
- 循环次数设为“永久”时，必须设置“调度器”时长，否则测试不会停止。

02 断言：让结果自己“开口说话”

没有断言的压测，等于测了个寂寞。断言自动判断响应是否符合预期，失败就标记为错误。

常用断言类型：
- 响应断言：检查响应文本是否包含特定字符串。
- JSON断言：验证JSON字段的值。
- 大小断言：检查响应体大小是否在范围内。

实战案例：
登录接口返回JSON：`{"code":200,"message":"success"}`

配置响应断言：

模式匹配规则: 包含

测试模式: "code":200

代码示例（断言配置）：

Assertion

  ├── Apply to: Main sample and sub-samples

  ├── Test Field: Response Text

  ├── Pattern Matching Rules: Contains

  └── Patterns to Test: "code":200

> 断言是压测的“裁判”，没有它，结果只是一堆数字。

高级用法：
- 多重断言：一个请求可以添加多个断言，检查不同维度。
- 变量断言：用`${variable}`动态匹配。
- 正则断言：用正则表达式提取复杂数据。

调试技巧：
- 用“View Results Tree”查看断言失败详情。
- 断言失败时，JMeter会记录“Assertion failed”日志。
- 设置“断言结果”监听器，统计失败率。

性能影响：
- 断言越多，测试速度越慢。每增加一个断言，响应时间增加0.1-0.5毫秒。
- 1000并发下，10个断言会让测试时间增加10%。
- 关键接口用断言，非关键接口用“忽略”。

03 监听器：把数据变成“可视化情报”

监听器是压测的“仪表盘”。它把原始数据转化为图表和报告，让你一眼看出系统瓶颈。

核心监听器：
- 聚合报告：最常用。显示平均响应时间、吞吐量、错误率。
- 图形结果：可视化时间序列，观察性能波动。
- 查看结果树：调试用，展示每个请求的详细数据。

实战解读：
假设聚合报告显示：

Label      #Samples  Average  Min  Max  Std.Dev.  Error%  Throughput

/login     1000      125      30   800  120       2.3%    200/sec

关键指标：
- Average 125ms：平均响应时间，行业标准<200ms。
- Error% 2.3%：错误率，超过1%需要排查。
- Throughput 200/sec：吞吐量，系统处理能力。

> 监听器不是“装饰品”，它是性能问题的“X光机”。

配置技巧：
- 写入CSV：聚合报告勾选“Save Table Data”，导出数据做深度分析。
- 自定义图表：用“jp@gc - PerfMon Metrics Collector”监控服务器CPU、内存。
- 实时监控：用“Backend Listener”将数据发送到InfluxDB+Grafana。

避坑指南：
- 监听器会消耗内存。1000线程下，每个监听器占用50-100MB内存。
- 压测时只开1个监听器，其他压测结束后再添加。
- “查看结果树”只在调试时用，正式压测必须关闭。

进阶工具：
- Command-line模式：用`jmeter -n -t test.jmx -l results.jtl`执行压测，无GUI开销。
- HTML报告：用`jmeter -g results.jtl -o report/`生成专业报告。
- 分布式压测：1台Master+N台Slave，突破单机并发限制。

---

> 性能测试不是“测一次”，是“测到系统崩溃，然后修复它”。