压力测试概述与定义
做压力测试这么多年，我经常被问到同一个问题：「压力测试到底测什么？」
说白了，压力测试就是——把系统往死里逼，看它什么时候会崩溃。
你想想看，一个电商网站平时几百人用，一切正常。双十一突然涌进几十万人，它还能撑住吗？撑不住的时候，是变慢、报错，还是直接挂掉？挂了之后多久能恢复？这些问题，就是压力测试要回答的。
什么是压力测试
压力测试（Stress Testing）是一种通过模拟超常负载，来评估系统在极限条件下行为表现的测试方法。我给个更直白的定义：压力测试 = 在极端条件下验证系统的稳定性和恢复能力。
我个人习惯把压力测试分成两个层面来看：
- 数据层面——系统能处理的峰值流量是多少？当超过这个峰值时，表现如何？
- 恢复层面——系统崩溃后，能不能自动恢复？恢复时间是多少数据是否会丢失？
核心要点：压力测试不关心「系统在正常情况下能不能用」，它关心的是「系统在快要挂掉的时候，还能不能优雅地活下去」。
压力测试与负载测试的区别
我经常看到新人把压力测试和负载测试混为一谈。这两个东西，其实差别很大。
| 对比维度 | 压力测试 | 负载测试 |
|---|---|---|
| 核心目标 | 找到极限 + 验证恢复 | 验证性能指标是否达标 |
| 负载模型 | 持续加压直至崩溃 | 在预估峰值内持续运行 |
| 关注点 | 系统边界、降级行为、恢复能力 | 响应时间、吞吐量、资源利用率 |
| 测试环境 | 通常与生产环境一致或接近 | 可以是预发布环境或等比例缩容环境 |
| 典型场景 | 秒杀、大促、突发故障演练 | 日常峰时验证、容量规划 |
举个例子。我在项目中遇到过这样一个情况：某次负载测试结果显示，系统在 5000 QPS 时平均响应时间只有 50ms，所有人都觉得没问题。结果上线后第一个大促，流量刚冲到 4500 QPS，系统就出现了大量超时和雪崩。为什么？因为负载测试只测了「正常+轻微超载」的范围，根本没去碰那个真正的极限边界。而压力测试要做的，就是找到那个让系统断崖式下降的拐点。
压力测试的核心目标
我个人把压力测试的目标归纳为四点：
- 发现极限点——系统在多高的负载下开始降级？在多高的负载下彻底崩溃？
- 验证降级策略——限流、熔断、降级这些保护措施，在真实压力下是否按预期触发？
- 检验恢复能力——系统崩溃后，能否自动拉起？数据是否完整？RTO（恢复时间目标）能否满足？
- 暴露隐蔽缺陷——内存泄漏、资源池耗尽、线程死锁、缓存穿透……这些平时看不出来的问题，压力一上来就现形了。
小技巧：很多团队只做到第 1 步就停了。我建议一定要跑到第 4 步——持续加压到系统彻底挂掉，然后仔细看日志和监控，你会发现大量平时根本看不到的异常。
一个简单的压力测试流程
好了，理论说完了，咱们来看看实际操作时怎么走。这是一个我一直在用的经典流程：
- 明确目标——比如「验证系统在 10000 QPS 下的降级表现」或者「找到系统能承受的最大用户数」。
- 设计场景——是持续加压、阶梯加压，还是突发冲击？结合业务场景来。
- 准备脚本——写测试脚本或配置测试工具。我最常用的工具是 JMeter 和 Locust。
- 部署监控——CPU、内存、IO、网络、GC、慢查询……一个都不能少。没有监控的压力测试，就是盲打。
- 执行测试——从小量开始，逐步加压。记录每个阶段的关键指标。
- 分析结果——找到瓶颈，定位根因。这一步最花时间，也最考验功力。
- 优化 + 回归——修完问题，再跑一轮，直到达标为止。
压力测试的分类
你可能会问：「压力测试是不是只有一种？」我的回答是——不是。我通常把它分为三类：
- 单模块压力测试——只针对某个核心接口或功能模块压，比如登录接口、下单接口。适合快速定位局部瓶颈。
- 端到端压力测试——模拟完整业务流程，从用户请求到数据库落盘都覆盖。适合验证整体系统承载能力。
- 混沌压力测试——在压力测试过程中，随机注入故障（比如 kill 掉某个服务实例、让网络延迟增加 200ms）。这是我最喜欢的一种，因为它能暴露系统在「压力和故障叠加」时的真实表现。
注意：不要一上来就跑端到端压力测试。我见过很多团队犯这个错误——结果出了问题，根本分不清是前端、后端还是数据库的问题。先从小范围开始，逐步扩大覆盖面。
好了，以上是压力测试的概述和基本定义。下面我用一张图来总结这一章的核心知识体系——这样你看起来会更直观。嗯，这张图我画了好多年，每次培训都会用，算是我的压箱底了。
最后说一句掏心窝的话：压力测试不是为了「证明系统没问题」，而是为了「提前找到它一定会出问题的地方」。我曾经因为跳过压力测试，吃过大亏——那个案例我后面会详细讲。但我希望你从一开始就记住：压力测试不是选择题，是必答题。