软件性能测试主要测什么？负载测试、压力测试、稳定性测试全解析

性能测试

一提性能测试，很多人脑子里就一个画面：开个JMeter，怼上一万个并发，看系统崩不崩。然后呢？然后就没有然后了。说实话，性能测试不是只有一种打法。负载测试、压力测试、稳定性测试，这三个东西看着像，实际上测的是完全不同的问题。搞混了，测了也白测。

一、先说性能测试到底在测啥？

别想复杂了，性能测试的本质就一件事：在不同条件下，系统还能不能正常干活。注意，不是"能不能用"，是"能不能正常干活"。能打开页面不叫性能好，1000个人同时打开页面还能在2秒内响应，这才叫性能好。所以性能测试关注的核心指标就那么几个：响应时间、吞吐量（TPS）、资源占用（CPU、内存、IO）、错误率。围绕这几个指标，衍生出了三种主流测试类型。

二、负载测试

负载测试干的事很简单，模拟真实用户量，看系统表现怎么样。比如你的APP日常有5000人在线，那我就用工具模拟5000个用户同时操作，看看响应时间是多少、有没有报错、CPU占了多少。

它的目标不是把系统搞崩，而是找到一个"甜蜜点"：在这个负载下，系统跑得最舒服，响应快、资源够用、错误率低。

说白了，负载测试回答的问题是：正常情况下，系统够不够用？举个例子，某电商大促前做负载测试，模拟8000并发，结果发现响应时间从1.5秒飙到了6秒，TPS上不去。这就说明当前配置扛不住这个量，得提前优化。

三、压力测试

压力测试跟负载测试最大的区别在于：它不关心正常情况，它关心的是系统的极限在哪、崩了之后什么样。

还是刚才那个电商系统，负载测试测到8000并发发现不行了，那压力测试就是继续加：10000、15000、20000……一直加到系统彻底扛不住，看它是怎么挂的。是直接500报错？还是响应时间无限拉长？还是内存溢出直接崩掉？这些都是压力测试要记录的。它回答的问题是：系统的天花板在哪？崩了之后能不能恢复？

这里有个很关键的点，压力测试不是为了证明系统有多强，是为了找到它的脆弱点。比如某系统在12000并发时数据库连接池爆了，那这个连接池就是瓶颈，后面调优就得针对这个来。

四、稳定性测试

前两个测的是"瞬间表现"，稳定性测试测的是长时间运行下系统会不会慢慢烂掉。这个最容易被忽略，但其实最致命。你想啊，一个系统跑10分钟没问题，跑10个小时呢？跑7天呢？很多问题不是一瞬间暴露出来的，是跑着跑着慢慢积累的，内存泄漏、连接不释放、日志撑爆磁盘、Full GC越来越频繁……

稳定性测试的做法很朴素：在中等负载下（一般是日常峰值的70%~80%），连续跑24小时、72小时，甚至更久。中间不停，盯着指标看有没有漂移。它回答的问题是：系统能不能长时间稳定运行，会不会慢慢变烂？行业实践里，72小时是底线，头部机构已经跑到30天连续无故障了。你要是只跑了半小时就说"稳定性没问题"，那真的是在赌。

五、三种测试怎么选？

这三个不是互斥的，是互补的。负载测试告诉你"现在行不行"，压力测试告诉你"最多能扛多少"，稳定性测试告诉你"能扛多久"。三个加在一起，才是一份完整的性能评估。只做其中一个，就跟体检只查血压一样，不是没用，是远远不够。你们现在性能测试主要做哪种？有没有遇到过上线后才发现扛不住的情况？

标签：性能测试、稳定性测试