一、压力测试基础概念
大家好，我是老张。在性能测试这个行当摸爬滚打了十几年，今天咱们来聊聊压力测试最基础的东西。别小看这些概念，我见过太多人做了几年测试，连压力测试和负载测试都分不清。
什么是压力测试
压力测试，说白了就是「把系统往死里压」。
你想想看，一个系统平时跑得好好的，用户量一上来就崩了。为什么？因为没人知道它的极限在哪。压力测试就是干这个的——找到那个「临界点」。
我习惯这样定义：压力测试是通过不断增加并发请求，让系统资源达到饱和，从而发现系统在极限状态下的行为表现。
核心要点：压力测试关注的是「系统什么时候会崩溃」，而不是「系统能处理多少正常请求」。
压力测试的目标
做压力测试，目标其实很明确。我总结为三点：
- 找到系统的极限容量——到底能扛多少并发？
- 发现瓶颈点——是CPU扛不住了？还是数据库先挂了？
- 验证恢复能力——压崩之后，系统能不能自己缓过来？
我在项目中遇到过一件事：一个电商平台，平时压测到5000并发都稳稳的。结果双十一当天，3000并发就挂了。后来一查，是缓存策略有问题。嗯，这就是压力测试没做到位。
我的经验：压力测试不是一次性的。每次大版本上线前，我都会建议团队至少跑一轮压力测试。别等到线上出问题再后悔。
压力测试 vs 负载测试
这两个概念，很多人搞混。我简单说下区别：
| 维度 | 压力测试 | 负载测试 |
|---|---|---|
| 目标 | 找到极限点 | 验证预期性能 |
| 压力大小 | 持续加压直到崩溃 | 保持在预期范围内 |
| 关注点 | 系统何时崩溃、如何崩溃 | 响应时间、吞吐量是否达标 |
| 典型场景 | 秒杀、抢购 | 日常业务高峰 |
举个例子你就明白了。负载测试就像你开车跑高速，看看120码稳不稳。压力测试呢？是把油门踩到底，看看这车到底能跑多快，会不会散架。
注意：千万不要在生产环境做压力测试！我曾经见过有人直接在线上压测，结果把数据库压崩了，影响了真实用户。压力测试一定要在预发环境或者专门的压测环境做。
常见的压力测试场景
这些年我接触过的项目，压力测试场景大致分这么几类：
1. 秒杀/抢购场景
这是最典型的压力测试场景。瞬间涌入大量请求，系统能不能扛住？我做过一个案例，某电商平台秒杀活动，1秒内涌入10万请求。结果呢？数据库连接池先爆了。
2. 突发流量场景
比如微博上突然爆了个热搜，或者新闻网站出了个大新闻。流量在几分钟内暴涨几十倍。这种场景下，系统能不能自动扩容？会不会雪崩？
3. 长时间运行场景
有些系统平时压力不大，但需要连续运行几天甚至几周。比如银行的对账系统、电信的计费系统。这种场景下，内存泄漏、连接未释放这些问题就会暴露出来。
4. 资源耗尽场景
故意把CPU、内存、磁盘IO压到极限，看看系统会怎么反应。是优雅降级？还是直接崩溃？
我的建议：刚开始做压力测试，别贪多。先从一个核心场景入手，跑通了再扩展。我刚开始带团队时，总想一次把所有场景都覆盖，结果哪个都没做好。
知识体系总览
下面这张图，是我自己总结的压力测试知识体系。你一看就明白了：
这张图把压力测试的核心内容串起来了。你仔细看看，其实就四个维度：定义、目标、区别、场景。把这四个搞明白，压力测试就算入门了。
一句话总结：压力测试不是看你系统有多强，而是看你系统什么时候会跪。知道怎么跪的，才知道怎么扶。
好了，这一章的内容就到这。记住我说的：压力测试不是炫技，是保命用的。下一章咱们聊聊具体的压测工具怎么选、怎么用。