压测场景分类：六种核心模式
做压测这么多年，我经常被问到同一个问题：
「到底该做哪种压测？」
说实话，很多人把负载测试、压力测试、稳定性测试混为一谈。其实它们各有各的用处。你想想看，一辆车要上市，既要测它能不能拉满货跑高速（负载），也要测它超载后会不会爆胎（压力），还得测它连续开三天三夜会不会自燃（稳定性）。
下面这六种场景，是我在实际项目中反复验证过的分类方式。
1. 负载测试（Load Testing）
负载测试，说白了就是「正常情况下的极限在哪」。
我习惯把负载测试比作体检。测的是系统在预期流量下的各项指标——响应时间、吞吐量、错误率。目标不是压垮系统，而是验证它能不能扛住设计指标。
关键参数：
- 目标并发数：比如设计指标是1000并发
- 目标TPS：比如预期每秒处理500笔交易
- 响应时间阈值：比如99%的请求在200ms内返回
2. 压力测试（Stress Testing）
压力测试就有点「暴力」了。它的目标是找到系统的崩溃点。
我经常跟团队说：压力测试不是要证明系统有多强，而是要找到它什么时候会跪。
怎么做：
- 逐步增加并发数，直到系统出现明显退化
- 记录崩溃时的各项指标
- 观察崩溃后的恢复行为——是优雅降级还是直接挂掉
3. 稳定性测试（Stability Testing）
稳定性测试，也叫「耐力测试」或「长时间测试」。
嗯，这里要注意：很多系统能扛住短时高峰，但跑个一两天就开始出问题。内存泄漏、连接池耗尽、日志文件撑爆磁盘——这些都是稳定性测试才能发现的。
我的建议：
- 至少跑24小时，最好72小时
- 监控内存、CPU、磁盘、网络的全生命周期变化
- 重点关注：GC频率、线程数、连接数是否持续增长
4. 容量测试（Capacity Testing）
容量测试，说白了就是「系统到底能吃下多少」。
它和负载测试的区别在于：负载测试验证设计指标，容量测试探索系统上限。
典型场景：
- 数据库能存多少条记录而不明显降速
- 缓存能支撑多少key而不触发淘汰策略
- 带宽能支撑多少并发连接而不丢包
| 测试类型 | 目标 | 典型指标 |
|---|---|---|
| 负载测试 | 验证设计指标 | 响应时间、TPS |
| 容量测试 | 探索系统上限 | 最大连接数、最大数据量 |
5. 尖峰测试（Spike Testing）
尖峰测试模拟的是流量突然暴涨的场景。
比如秒杀、抢票、突发新闻——流量可能在几秒内飙升10倍甚至100倍。
我的做法：
- 先让系统在低负载下稳定运行
- 突然将并发数提升到目标值的5-10倍
- 观察系统是否触发限流、降级、熔断
- 观察流量回落后系统能否自动恢复
6. 并发测试（Concurrency Testing）
并发测试，很多人以为就是「多线程压测」。其实它更关注的是资源竞争问题。
说白了，就是多个请求同时访问同一份资源时，系统会不会出乱子。
典型场景：
- 多个用户同时修改同一条数据
- 多个线程同时获取同一个锁
- 多个请求同时写入同一个文件
知识体系总览
下面这张图，是我自己总结的压测场景分类体系。你可以把它当作一个检查清单，每次做压测前对照一下，看看覆盖了哪些场景。
如何选择压测场景
说了这么多，你可能想问：那我到底该做哪些？
我的建议是分三步走：
- 先做负载测试——确认系统能达到设计指标
- 再做压力测试——找到系统的极限在哪里
- 最后做稳定性测试——确保系统能长时间稳定运行
尖峰测试和并发测试，根据业务特点选择性加入。比如秒杀系统必须做尖峰测试，金融系统必须做并发测试。
好了，这一章就到这里。下一章我们会深入讲解每种场景的具体实施方法，包括工具选择、参数配置、结果分析。到时候我会拿几个真实项目案例出来，跟大家聊聊那些年我们踩过的坑。