2. 压力测试的目标与意义
很多人问我：“压力测试不就是把系统搞挂吗？”
嗯，这么说也没错，但不全面。
把系统搞挂只是手段，不是目的。
我们真正想知道的，是系统在极限状态下——它到底会怎么挂。
我个人习惯，在开始任何压力测试之前，先给自己定三个清晰的目标。没有目标的压测，像无头苍蝇，数据再多也没用。
2.1 压力测试要回答的四个核心问题
说白了，压力测试要回答的就四个问题。我管它叫“四个拷问”：
- 系统承载极限在哪？ —— 每秒能处理多少请求？能支撑多少用户同时在线？能跑多久不崩溃？
- 失效模式是什么？ —— 是响应变慢？直接挂掉？还是开始报奇怪的错？
- 恢复能力如何？ —— 压力撤掉后，系统能自己缓过来吗？还是需要人工重启？
- 哪些组件先掉链子？ —— 是数据库顶不住了？还是网络带宽到了？Redis 缓存扛不住了？
我在一个金融项目中遇到过这种情况。团队觉得系统稳得很，负载测试都过了。结果一上压力测试，数据库连接池几分钟就爆了。原因？一个批量查询没加索引，数据量一上来，直接锁表等待。
2.2 压力测试与负载测试的差异
很多人分不清压力测试和负载测试。我刚开始也搞混过。其实区别很简单：
| 对比维度 | 负载测试 | 压力测试 |
|---|---|---|
| 核心目标 | 验证系统在预期负载下的表现 | 探索系统在超预期负载下的极限 |
| 负载条件 | 正常峰值负载（如 80% 上限） | 远超正常峰值的负载（如 200%-500% 上限） |
| 关注点 | 响应时间、吞吐量、资源利用率 | 系统崩溃点、失效模式、恢复能力 |
| 测试结束后 | 系统应保持正常运行 | 系统可能部分或完全不可用 |
| 适合阶段 | 上线前常规验证 | 上线前极限验证、混沌工程 |
你想想看，负载测试就像问：“这辆车跑120km/h，稳不稳？”
压力测试则是问：“这辆车油门踩到底，能跑多少？会不会散架？百公里刹车能不能刹得住？”
2.3 压力测试的六个关键目标
我觉得可以把压力测试的目标拆成六个维度。每个维度都很直接，没有花里胡哨的东西。
- 定位系统瓶颈 —— 找到拖后腿的那个组件。可能是 CPU、内存、IO，也可能是代码里的死循环。
- 验证高可用策略 —— 看看你的熔断、降级、限流有没有用。我曾经见过一个限流策略，配置限流500，结果代码里写的是每5分钟。压测一上去，直接被打穿。
- 评估容量规划 —— 为未来的扩容提供数据支撑。比如今年3800用户是极限，明年预估6000，你得提前知道该加几台机器。
- 暴露隐式依赖 —— 平时没事，压力一大，各个服务之间那些没文档化的调用、超时的配置、认证的瓶颈全冒出来。
- 验证恢复能力 —— 挂掉之后能不能自动恢复？还是需要人工介入？恢复时间是多少？这些决定了你的SLA。
- 生成风险评估报告 —— 给老板和运维看。告诉他们：“这个系统，在XXX并发下安全，超过XXX会有YYY风险。”
2.4 压力测试为什么重要？
我直接说大实话：没见过挂掉的系统，你永远不知道它有多脆弱。
我曾经负责过一个大促项目。离线跑得好好的，一到线上流量峰值的瞬间，登录服务直接挂掉。查了半天，发现是认证服务那边的线程池太小，请求全在排队，排队多了直接OOM。这个场景，在常规负载测试下根本测不出来。只有持续加压力，逼它到极限，它才会暴露出来。
再说个更实际的。你在面试的时候，如果简历里写“做过压力测试”，但只说了个并发数，面试官大概率会觉得你只是跑了个脚本。如果你能说清楚——怎么发现瓶颈的、用了什么分析工具、优化后极限提升了多少、恢复时间控制在多少——这才叫真的有价值。
说白了，压力测试的意义在于：
- 给系统上一份“意外险” —— 知道最坏情况是什么，才能防患于未然。
- 给运维团队一份“操作手册” —— 压力大到什么程度该告警？什么时候需要自动扩容？什么时候该手动熔断？
- 给公司一个“成本账本” —— 花多少钱买多少机器，撑多少流量，心里有数。
2.5 压力测试的核心价值（SVG图示）
讲了这么多，我画了一张图，把压力测试的核心价值串起来。你一看就明白了。
2.6 如何看待压力测试的“成本”
有人觉得压力测试太费时间、太费机器。说实话，我理解。尤其项目赶的时候，压测经常被砍掉。但我想说一个亲身经历。
有一个项目，上线前因为时间紧，没做压力测试。结果上线第一天，用户量一上去，系统直接崩了。修复、重启、排查...团队通宵了两天。最后算下来，这波故障造成的损失，够买十几台压测服务器了。
所以我的建议是：
压力测试不是成本，是投资。
花几天时间做压测，省掉的是线上故障后几周的修复成本和用户流失。