完成了接口功能测试后，我们将正式进入性能压测领域。性能压测的核心是模拟真实用户并发访问，评估系统在不同负载下的响应能力。本文将从 JMeter 的线程模型出发，讲解如何设计合理的压测策略（基准测试、负载测试、稳定性测试），并结合梯度加压插件实现精细化的负载模型。
一、性能压测的三大目标
二、JMeter 线程模型详解
2.1 线程组（Thread Group）核心参数
2.2 线程数与 Ramp-up 的关系
快速启动（Ramp-up 很小）：瞬间产生大量并发，可能造成网络拥塞或系统拒绝服务，适合测突发流量。
平缓启动（Ramp-up 较大）：模拟用户逐步增加，可以观察性能曲线的渐变过程，便于发现拐点。
经验公式：
Ramp-up = 线程数 / 每秒增加的线程数。例如想每秒增加 10 个线程，100 线程则 Ramp-up = 10 秒。
2.3 线程组执行顺序
同一个测试计划下的线程组是并行执行的（除非使用 Inter-Thread Communication 插件）。
如果希望顺序执行（例如先登录再下单），应将不同操作放在同一个线程组中，或使用 Throughput Controller 控制比例。
三、压测策略设计
3.1 基准测试（单用户基准）
目的：确定系统在无竞争情况下的性能基线。
配置：
线程数 = 1
循环次数 = 10~50（或运行 1~2 分钟）
记录平均响应时间、TPS、错误率
作用：后续压测的对比参照，也可用于验证脚本的正确性。
3.2 负载测试（寻找拐点）
使用梯度加压方式：逐渐增加并发用户数，观察 TPS 和响应时间的变化，找到性能拐点。
手工配置多个线程组：
线程组1：10 并发，Ramp-up 10s，持续 2 分钟
线程组2：20 并发，Ramp-up 10s，持续 2 分钟
线程组3：50 并发，Ramp-up 10s，持续 2 分钟
...
但更推荐使用 Concurrency Thread Group 或 Stepping Thread Group（需安装 Custom Thread Groups 插件）。
3.3 稳定性测试（耐久测试）
目的：检测长时间运行下的内存泄漏、资源耗尽等问题。
配置：
线程数：设为预估峰值并发数的 80% 左右
持续时间：至少 1 小时，通常 8 小时或更长
监听器重点监测内存、GC 活动
四、梯度加压插件详解
JMeter 默认的线程组只能固定线程数或简单爬坡。要模拟阶梯式增加/减少并发，需要安装 Custom Thread Groups 插件。
4.1 安装 Custom Thread Groups
通过 JMeter Plugins Manager：
Options → Plugins Manager
搜索 "Custom Thread Groups" → 安装
4.2 Stepping Thread Group（步进线程组）
配置项：
This group will start：初始线程数
First, wait for：初始延迟
Then start：增加线程数
Next, add：每次增加的线程数
Threads steps：步数（增加几次）
Then hold load for：满负载保持时间
Finally, stop / threads every：每秒停止的线程数
示例：
从 0 开始，每 10 秒增加 10 个线程，直到 100，保持 5 分钟，然后每 5 秒停止 10 个线程。
4.3 Concurrency Thread Group（并发线程组，更推荐）
配置项：
Target Concurrency：目标并发数（可设为变量如 ${__P(threads,100)}）
Ramp Up Time：爬升时间
Ramp Up Steps Count：爬升步数（平滑步数）
Hold Target Rate Time：保持满负载时间
Thread Iterations Limit：每个线程的循环次数限制（可留空）
Log Threads Status：记录状态
这个线程组更适合精确控制 TPS 而非固定线程数，因为它会根据实际吞吐量动态调整线程。但对于初学者，Stepping Thread Group 更直观。
五、实战：设计一个完整的负载测试场景
5.1 测试场景描述
目标接口：GET /api/products 和 POST /api/orders
混合比例：70% 浏览商品，30% 下单
并发目标：从 10 逐渐增加到 200，找到性能拐点
5.2 测试计划结构
text
Test Plan
├─ HTTP Request Defaults（服务器、协议）
├─ HTTP Header Manager（公共头）
├─ Stepping Thread Group (浏览商品线程组)
│ ├─ HTTP Request (GET /products)
│ └─ 监听器
├─ Stepping Thread Group (下单线程组)
│ ├─ HTTP Request (POST /orders)
│ └─ 监听器
└─ 聚合报告 + 图形结果
5.3 配置阶梯
浏览商品线程组：
Start Threads Count: 7（因为总目标 200 的 70% 约 140，但阶梯可设独立）
First, wait for: 0
Then start: 7
Next add: 7 every ? 可以根据需要设置步长
Thread steps: 20（总线程 7*20=140）
Hold load: 5 min
Finally stop: 14 threads every 5 sec
下单线程组：
Start Threads Count: 3（30%）
Next add: 3 every 相同时间间隔
Thread steps: 20（总线程 60）
其他类似
注意两个线程组的 Ramp-up 步调和时间要同步，使总体并发按比例增长。
5.4 运行与观察
运行测试，使用 jp@gc - Active Threads Over Time 监听器观察实际并发数。
结合 Transactions per Second 监听器观察 TPS 曲线，找到拐点（TPS 不再随线程增加而增加的点）。
六、常见误区与注意事项
线程数 ≠ 并发用户数：如果每个线程执行一个请求后立即结束，实际并发数可能小于线程数。使用"循环"和"思考时间"才能模拟真实并发。
忽略思考时间（Think Time）：真实用户有操作间隔，压测中若不加入思考时间，服务器压力会远大于实际。使用 Uniform Random Timer 或固定定时器。
单机压测的瓶颈：一台机器的 JMeter 可能无法产生足够压力（受 CPU、内存、网络限制）。需要分布式压测（后续文章讲解）。
不要只用平均响应时间：关注 90%、95%、99% 分位值，避免被长尾请求掩盖问题。
七、总结
本文核心：
压测的三种类型：基准测试、负载测试、稳定性测试
线程组参数的含义与配置
使用 Stepping Thread Group 实现梯度加压
如何设计混合场景的压测模型