压力测试的三种核心类型

做压力测试这几年，我经常被问到同一个问题：“压力测试到底测什么？”

其实说白了，压力测试不是单一的动作。它分三个维度：负载测试、容量测试和稳定性测试。这三者看着像亲兄弟，但各有各的脾气。

我习惯用一个比喻来理解它们：
负载测试是“看看能扛多少活”，容量测试是“找到极限值在哪儿”，稳定性测试是“长时间干会不会出事”。

下面咱们逐个拆解。

负载测试

负载测试，我的理解是：在预期流量下，验证系统能不能正常干活。说白了就是给系统一个“正常范围”的压力，看它响应快不快、报不报错。

我在项目中遇到过这样一个场景：上线前产品经理说“日活预计10万”，那我们就得模拟10万用户同时在线的情况。这就是典型的负载测试。

核心关注点

• 响应时间：接口平均响应是否在SLA范围内
• 吞吐量：每秒能处理多少请求
• 错误率：有没有出现5xx或超时
• 资源消耗：CPU、内存、带宽是否合理

一个简单的负载测试场景

假设我们要测一个登录接口。目标是：1000个用户同时登录，平均响应时间小于500ms，错误率低于1%。

我一般会用这样的配置做基准测试：

# JMeter 线程组配置示例
线程数: 1000
Ramp-Up 时间: 10秒
循环次数: 10
持续时间: 300秒

嗯，这里要注意：Ramp-Up时间太短，容易把系统直接冲垮，测不出真实水平。我建议至少让压力慢慢爬升，观察系统是怎么“接招”的。

容量测试

容量测试，说白了就是找到系统的极限在哪。它回答一个问题：“系统最多能扛多少人而不崩溃？”

这和负载测试不一样。负载测试是在“预期范围内”测，容量测试是往死里压，直到系统撑不住为止。

我曾经在一个电商项目中做容量测试。系统设计说是能支持5000并发，结果我们压到3800的时候，数据库连接池就爆了。你想想看，这要是没提前测出来，双十一那天就等着闪崩吧。

容量测试怎么搞？

1. 阶梯加压：一开始给500并发，稳定后加1000，再加到1500……直到出现拐点
2. 找到拐点：响应时间突然飙升、错误率急剧上升、CPU打满——这些就是拐点信号
3. 记录极限值：把最大并发数、最大吞吐量、资源上限记下来

常见的容量瓶颈

稳定性测试

稳定性测试，我想用一个词来形容：“熬”。它不是测爆发力，而是测耐力。系统能不能在高负载下连续跑12小时、24小时甚至更久？会不会出现内存泄漏？会不会越跑越慢？

我见过不少系统，刚上线跑得飞快，跑了三天就开始卡顿。一查，原来是某个缓存没清理，内存一点点被吃掉。这就是稳定性的问题。

稳定性测试的关键指标

• 长期资源趋势：CPU、内存、磁盘IO是否随时间增长
• GC行为：Full GC频率是否越来越快
• 慢请求比例：响应时间是否逐渐变长
• 内存泄漏检测：堆内存使用量是否持续上升

怎么判断稳定性测试通过？

我个人标准：连续运行24小时，各项指标波动不超过10%。

如果响应时间从200ms慢慢涨到800ms，就算没报错，这也是不稳定的表现——说明系统在“慢性死亡”。

三种类型的关系

你可能会问：这三种测试到底先做哪个？我的建议是先负载、再容量、最后稳定性。

• 先做负载测试，确认系统在正常范围内没问题
• 再做容量测试，摸清系统的真实上限
• 最后做稳定性测试，保证系统能长时间撑住

但实际项目中，这三个往往是迭代进行的。找到容量瓶颈，修完代码后，再跑一遍负载测试，确认没引入新问题。嗯，这才是实战中的节奏。

三种类型对比一览

最后，我习惯用一张对比表来快速回顾它们的不同。这个表在我的团队里贴了好几年，每次新人来都先看这个。

其实这三种类型没有的界限。我遇到很多团队，把负载测试做成了“轻量级的容量测试”，把稳定性测试做成了“长时间的负载测试”。这都不算错，关键是你要清楚自己到底在测什么。