一、压力测试基础
大家好，我是老张。在性能测试这行摸爬滚打了十几年，今天咱们来聊聊压力测试最基础的东西。说实话，很多干了三五年的测试，对这几个概念还是模模糊糊的。咱们先把地基打牢。
1.1 什么是压力测试
压力测试，说白了就是——把系统往死里压，看它什么时候扛不住。
我习惯这么定义：压力测试是通过持续增加负载，让系统超过正常承载能力，观察它在极限状态下的表现。你想想看，就像测试一座桥的承重，不是看它能不能过普通轿车，而是看它能不能扛住满载的重卡，甚至要知道它到底能扛几辆重卡才会塌。
具体来说，压力测试会关注这些点：
- 系统在超负荷时的响应时间变化
- 什么时候开始报错、丢数据
- 崩溃后能不能自动恢复
- 资源（CPU、内存、IO）的极限在哪里
核心要点：压力测试不是为了证明系统能跑多快，而是为了找到系统什么时候会死、怎么死的、死后能不能活过来。
1.2 压力测试 vs 负载测试
这两个概念，我见过太多人搞混了。有一次面试，候选人说「我们做了压力测试，TPS到了5000」，我一听就知道他做的是负载测试。为什么会这样？因为很多人把「压力大」等同于「负载高」。
咱们用一张图来理清关系：
嗯，这里要注意一个关键区别：负载测试是在「安全区」内测试，压力测试是故意冲进「危险区」。我个人的习惯是，先做负载测试确认系统能正常跑，再做压力测试找极限。
| 对比维度 | 负载测试 | 压力测试 |
|---|---|---|
| 核心目标 | 验证性能是否达标 | 找到系统极限 |
| 负载策略 | 逐步增加到预期峰值 | 持续增加直到崩溃 |
| 预期结果 | 系统正常运行 | 系统可能出现故障 |
| 关注指标 | 响应时间、TPS、错误率 | 崩溃点、恢复能力、资源极限 |
| 典型场景 | 上线前性能验收 | 容量规划、容灾演练 |
1.3 压力测试的目标与价值
说白了，做压力测试就三个目的：
- 找到系统的天花板——到底能扛多少并发？TPS上限是多少？
- 验证系统的韧性——扛不住的时候怎么表现？是优雅降级还是直接崩？
- 为容量规划提供依据——需要加多少机器？什么时候该扩容？
我记得有一次给一个金融客户做压力测试，他们的系统平时只有几百的TPS。我压到2000的时候，系统开始报连接超时。再压到3000，直接挂了，而且重启后数据丢了半小时。你想想看，如果这个场景发生在真实交易高峰期，后果不堪设想。
我的经验：压力测试最大的价值不是「测出问题」，而是「提前暴露问题」。线上出问题叫事故，测试环境出问题叫优化空间。这个区别，懂的都懂。
1.4 常见误区
这些年我带过不少团队，发现大家对压力测试的误解还真不少。挑几个最常见的说说：
- 误区一：压力测试就是使劲压
我曾经见过有人开1000个线程直接怼上去，系统瞬间崩了，然后报告写「系统最多支持100并发」。这其实是在做破坏性测试，不是压力测试。真正的压力测试是有策略地逐步加压，记录每个阶段的指标变化。 - 误区二：压力测试只测一次就够了
系统是活的，代码在改、配置在调、流量在变。我建议每次大版本发布前都要做一轮压力测试。有一次我们优化了数据库连接池，结果压力测试发现新配置在高并发下反而更差——幸亏提前发现了。 - 误区三：压力测试只看TPS
TPS只是其中一个指标。你想想看，TPS很高但响应时间从50ms飙到5s，这算好还是不好？我习惯同时看TPS、响应时间、错误率、资源使用率这四个维度，缺一不可。 - 误区四：压力测试是测试团队的事
这个坑我踩过。以前测试团队自己压，发现性能问题丢给开发，开发说「我们本地跑没问题啊」。后来改成测试+开发+运维一起看，压测现场直接定位问题，效率翻倍。
避坑指南：我曾经在一个项目中，测试环境压测通过，上线后却扛不住。后来发现测试环境的网络带宽是10G，生产环境只有1G。所以压力测试的环境一定要和生产环境尽可能一致，否则压出来的数据就是自欺欺人。
好了，这一章的基础概念就聊到这儿。记住一句话：压力测试不是要证明系统有多强，而是要提前知道系统有多弱。下一章咱们聊聊怎么搭建压力测试环境，到时候我会分享一些我常用的工具和配置技巧。