性能测试类型：负载、压力、稳定性
你可能会问：都是跑压测，分这么细干嘛？
我刚开始接触性能测试时，也觉得就测个并发数完事。结果有一次上线前做了“压力测试”，指标全绿，结果上线后被慢查询拖垮了。后来才发现——我做的其实是负载测试，不是真正的压力测试。不同类型的测试，目标不同，看到的瓶颈也不同。
负载测试：摸清系统的日常承受能力
定义：模拟预期的用户量或业务量，检验系统能否在正常负载下稳定运行。
目标：找到系统在预期工作负载下的响应时间、吞吐量、资源使用情况。说白了就是：给个正常值，看它行不行。
关键指标我习惯看三个：
- TPS/QPS：每秒事务数/查询数，看吞吐量是否达标
- 平均响应时间：500ms以内算优秀，1s内可接受
- CPU/内存使用率：一般建议CPU不超过70%，内存不过高
我个人习惯先做基准测试（单用户跑一轮），拿到底线数据。然后再逐级增加并发用户数（比如10、50、100、200），观察拐点出现在哪里。这个拐点就是系统的最佳承载线。
我记得有个项目，负载测试做到200并发时TPS还能稳定在1500，但到了250并发直接降到800。排查后发现是数据库连接池配置了最大200个连接——连接池满了，请求排队。调大连接池后，TPS又上去了。
压力测试：找到系统的崩溃边界
定义：不断加大负载，直到系统扛不住为止。目的是找到极限值和恢复能力。
你想想看，如果系统在负载超过预期30%时就瘫了，那线上流量突增该怎么办？
我曾经踩过一个坑：做压力测试时只关注了“系统什么时候报500错误”，却忽略了降级和熔断策略是否生效。正确做法是：压力测试不仅要看系统如何崩溃，还要看在压力回落后能不能自动恢复。
压力测试通常分两步：
- 阶梯加压：每5分钟增加50%负载，观察响应时间和错误率的变化
- 极限维持：在接近崩溃点保持一段时间，看看会不会导致雪崩
有一次我测试一个秒杀系统，压到3000并发时系统开始丢请求，但并没崩溃。我以为是扛住了。结果再跑一次的时候，Redis连不上直接OOM——原来第一次压测已经把缓存写爆了。嗯，这里要注意：压力测试要关注系统状态的持续恶化，不只是瞬时指标。
稳定性测试：看系统能不能长跑
定义：在接近生产负载的条件下，长时间运行（通常12~48小时），检查有无内存泄漏、连接泄漏、定时任务异常等问题。
说白了就是让系统跑个通宵，第二天看结果。很多隐蔽的Bug只会在长时间运行后暴露。
- 内存泄漏：通过查看JVM堆内存/非堆内存曲线，如果持续上升且GC无法回收，基本确定有泄漏
- 连接泄漏：数据库连接池、HTTP连接池的活跃连接数随时间增长而不是稳定
- 文件句柄泄漏：lsof命令能看到打开的文件描述符不断增长
我有个血的教训：之前做支付网关的稳定性测试，跑了8小时都正常，但在第11小时突然大量超时。查到最后发现是日志文件没有配置滚动，磁盘满了。自此之后，稳定性测试脚本里我一定放一个磁盘监控，并在测试前后对比磁盘使用量。
稳定性测试的负载通常建议是峰值的70%左右，持续12~24小时。如果条件允许，我推荐跑满48小时，因为一些慢泄漏可能需要时间积累才能暴露。
三种测试类型对比
| 维度 | 负载测试 | 压力测试 | 稳定性测试 |
|---|---|---|---|
| 核心目标 | 验证能否处理预期负载 | 找出系统极限和弹性 | 验证长期运行的可靠性 |
| 负载水平 | 正常 ~ 150% | 从正常逐步加到极限 | 70%~100%峰值 |
| 持续时间 | 几分钟 ~ 几小时 | 几十分钟 ~ 几小时 | 12 ~ 48小时 |
| 关注指标 | 响应时间、TPS、错误率 | 极限T/S、是否降级、恢复时间 | 内存、连接数、GC行为、磁盘 |
| 常见发现 | 配置瓶颈、代码效率问题 | 保护机制失效、雪崩隐患 | 泄漏、资源耗尽、定时任务异常 |
综合运用：三种测试怎样配合
实际项目中我不会只做一种。我的标准流程是：
- 先做负载测试，快速扫出明显的性能问题（比如慢SQL、不合理线程模型）
- 再做压力测试，验证极限能力和自我保护机制
- 最后稳定性测试，跑24小时看持久表现
下面这张图是我习惯用的测试类型关系，帮你理解它们之间的承接关系：
负载测试发现问题后，我通常会先修复再进入压力测试。压力测试发现的极限值会成为限流和熔断阈值的重要参考。最后稳定性测试像是一次“大考”，熬过去才算真正上线。
一个小技巧：稳定性测试时可以用jstat -gcutil每隔5分钟记录一次GC情况。如果看到FGC（Full GC）次数持续增加，且堆占用降不下去，大概率是内存泄漏。
总之，三种测试各有侧重，但都是性能调优中缺一不可的工具。你平时做测试时，也可以按照这个顺序来试试——先摸底，再找极限，最后看持久力。多跑几次，经验自然就长了。