压力测试基础与目标设定
做性能测试这么多年，我经常被问到：“压力测试到底测什么？”很多人觉得不就是把请求怼上去，看系统崩不崩嘛。嗯，没那么简单。
今天我们就从基础聊起。把压力测试这件事说清楚——为什么做、做什么、做到什么程度才算合格。
什么是压力测试？
压力测试，说白了就是在超出正常负载的条件下，观察系统的行为和极限。它不是“正常使用场景”的模拟，而是故意踩油门，看车轮还能抓地多久。
我刚开始做压测的时候，以为只要跑到CPU 100%就是压力。后来发现，系统可能在CPU 60%的时候就因为锁竞争挂了。
为什么要做压力测试？
你想想看，一个线上系统，平时1000 QPS跑得稳稳的，突然双十一流量翻倍到5000 QPS，会怎样？没有压测数据，没人敢拍胸脯说“能扛”。
- 验证系统的容量上限——到底能支持多少用户并发？
- 暴露资源瓶颈——是CPU不够？内存不足？还是数据库扛不住？
- 检验降级与熔断策略——极端情况下，业务功能表现是否可接受？
- 为容量规划提供依据——加多少机器？什么时候加？
我在一个电商项目中，压测发现数据库连接池配置成50就够，结果运维拍脑袋配了200，导致连接数打满，应用反而更慢。这就是不按数据规划的结果。
压力测试的核心目标
很多人把“找到最大TPS”当作唯一目标。我习惯把目标拆成三个层次：
- 发现瓶颈 —— 哪个组件最先达到极限？
- 确定拐点 —— 随着负载增加，系统性能从哪里开始急剧下降？
- 验证恢复 —— 压力释放后，系统能否自动回到正常状态？
举个例子，我曾经压一个支付服务，TPS在500时响应时间1ms，到520时突然跳到200ms。拐点非常明显。那个点，就是我们需要优化的地方。
关键性能指标
没有指标，压测就成了瞎撞。我常用的核心指标如下：
| 指标 | 含义 | 典型关注点 |
|---|---|---|
| TPS（Transactions Per Second） | 每秒完成的事务数 | 系统吞吐能力的直接体现 |
| QPS（Queries Per Second） | 每秒查询数 | 常用于读接口，关注点与TPS类似 |
| 响应时间（RT） | 从发送请求到收到响应的总耗时 | 关注平均、99分位、最大 |
| 错误率 | 失败请求占总请求的比例 | 通常要求低于0.1%或0.01% |
| 系统资源利用率 | CPU、内存、磁盘IO、网络带宽 | 寻找短板资源 |
压力测试的类型
不同场景用不同方法。我整理了一个对比表：
| 类型 | 目标 | 常用策略 | 典型场景 |
|---|---|---|---|
| 负载测试 | 验证正常负载下的表现 | 逐步增加并发，到预期峰值 | 上线前的常规验证 |
| 压力测试 | 寻找极限和崩溃点 | 持续增加负载直到系统出问题 | 确认系统弹性边界 |
| 稳定性测试 | 验证长时间运行 | 固定负载跑几小时甚至几天 | 排查内存泄漏、连接泄漏 |
| 尖峰测试 | 模拟突发流量 | 瞬间拉升负载 | 秒杀、促销场景 |
有人说“压力测试”就是负载测试，我不这么看。负载测试是“能跑多久”，压力测试是“能扛多高”。我在实际项目中，会先做负载测试确认基线，再做压力测试找上限。
压力测试的基本流程
我总结了一个五步走的方法，大家可以直接套用：
- 目标设定 —— 明确你要测什么指标、什么量级、什么场景。
- 场景设计 —— 确定并发模型、数据分布、请求比例。
- 脚本开发 —— 编写压测脚本，注意参数化和关联。
- 执行与监控 —— 收集全量指标，包括业务指标和系统指标。
- 分析与优化 —— 找到瓶颈，提出改进方案，循环验证。
目标设定的原则
没有目标的压测就是折腾。我一般按照以下原则设定目标：
- 可量化 —— 不能说“性能好”，要说“TPS ≥ 2000，99分位 RT ≤ 50ms”。
- 有参照 —— 基于当前线上水位或业务预测，不能空想。
- 分层次 —— 先定期望值，再定极限值，最后定破坏性阈值。
- 可回溯 —— 每次压测记录环境、版本、参数，方便对比。
举个例子，我负责的一个网关服务，目标设定如下：
- 正常负载：5000 QPS，RT≤20ms，错误率0%
- 压力上限：8000 QPS，RT≤100ms，错误率＜0.1%
- 破坏阈值：达到10000 QPS后允许部分请求失败，但10秒内恢复
你看，三个层次覆盖了从正常到极端的所有场景。后续所有优化都围绕这些数字进行。
常见误区
做了这么多年压测，见过太多翻车现场。我列几个最典型的：
- 误区一：压测环境与实际环境脱节 —— 用低配机器测高配场景，结果毫无参考价值。
- 误区二：只测一个点 —— 所有请求打同一个接口，忽略了业务混合的真实性。
- 误区三：忽视冷启动和预热 —— 刚启动就跑最大压力，JIT还没优化完，结果不准。
- 误区四：不记录基线 —— 改完代码再测，到底有没有提升？没有基线数据根本说不清。
结过程图：压力测试知识体系
这张图把压力测试的核心流程和知识要点串起来了。从目标设定开始，经过场景设计、脚本开发、压测执行、指标监控，最后到瓶颈分析。分析完发现瓶颈，再回到目标设定，形成闭环。右侧和左侧分别列出了关键指标和测试类型，这些是贯穿整个流程的基本要素。
说实话，很多团队压测做了很多次，但每次都是“这次要测什么”临时拍脑袋。如果你能把这个闭环跑通三四轮，系统的吞吐量瓶颈基本就无处藏身了。
好了，基础和目标设定先聊到这儿。记住一句话：没有目标的压测是浪费机器，没有流程的压测是浪费时间。