1. 性能测试基础：概念、目的、类型
大家好，我是你们这趟性能压测之旅的带路人。开篇我先说句实在话——性能测试不是什么高深莫测的玄学，说白了就是「让系统跑一跑，看它扛不扛得住」。我带过不少团队，发现很多人一开始就把这件事想复杂了，结果方向跑偏，浪费大量时间。
嗯，今天咱们就把地基打好。我会从最核心的概念讲起，再带你理清不同类型测试到底在测什么、什么时候用。你记住：基础不牢，后面所有的调优技巧都是空中楼阁。
1.1 什么是性能测试？
我个人习惯这样定义：性能测试是用工具模拟真实用户行为，对系统施加负载，从而评估系统响应时间、吞吐量、资源利用率等指标的过程。它的本质是「带着问题去压」，而不是「随便跑个脚本看报不报错」。
举个例子：你开发了一个电商下单接口，上线前得知道它一秒能处理多少订单、用户点击后多久能看到结果。这个「知道」的过程，就是性能测试。
1.2 为什么要做性能测试？
我在项目中遇到过不少「上线前才想起来压测」的案例，结果无一例外都是手忙脚乱。性能测试的目的，可以归纳为四点：
- 验证系统是否满足性能需求：比如 SLA 要求 99% 的请求在 200ms 内返回，压完了才知道达不达标。
- 发现性能瓶颈：到底是数据库慢？还是代码逻辑有锁？压一压，问题就现形了。
- 评估系统容量：这台服务器最多能撑多少并发？什么时候该加机器？
- 保证稳定性：系统连续跑 7 天会不会内存泄漏？会不会半夜挂了？
1.3 性能测试的类型
很多新人容易把「负载测试」和「压力测试」混为一谈。你想想看，虽然它们都属于性能测试，但意图和场景完全不同。下面这张图就是咱们这一章的骨架，我亲手画的，你先感受下全貌。
下面我把几个核心类型拆开来讲——都是你以后写压测方案时一定会用到的。
1.3.1 负载测试（Load Testing）
负载测试的目标很纯粹：在正常预期负载下，验证系统性能是否达标。比如我们预估双十一峰值是 5000 QPS，那就用 5000 QPS 去压，看响应时间、错误率、CPU 是否在合理范围。
我曾经接手过一个项目，开发说「接口没问题，压测结果很好」。结果一查，他们压的是 100 并发，而线上高峰期是 5000 并发。这哪叫负载测试？分明是「挠痒痒」。记住：负载值一定要基于业务预估，不能拍脑袋。
1.3.2 压力测试（Stress Testing）
压力测试就暴力多了——持续增加负载直到系统崩溃。为什么要有这个类型？你想想看，如果系统突然被恶意攻击或者流量暴涨，它该怎么应对？是优雅降级、拒绝新请求，还是直接 OOM 导致整个集群雪崩？
1.3.3 稳定性测试（Soak / Endurance Testing）
稳定性测试也叫「长时间测试」。它的核心关注点是：系统连续运行数小时甚至数天后，各项指标是否会持续劣化。很多时候，功能测试都过了，压测短时间也没问题，但跑 12 小时后内存缓慢泄漏、连接池耗尽、GC 频繁——这些问题，只有稳定性测试能发现。
我个人习惯，线上核心服务至少做 24 小时稳定性测试。如果业务允许，我会拉长到 72 小时。你可能会问：「有必要吗？」我的回答是：线上出一次凌晨故障，代价比压测大十倍。
1.3.4 容量测试（Capacity Testing）
容量测试和负载测试容易混淆。我觉得区别在于：负载测试关注「当前性能」，容量测试关注「最大容量」。比如你压出 2000 并发时响应时间 500ms，那系统容量就是 2000 并发吗？不一定。容量测试会结合 CPU、内存、网络等资源瓶颈，给出一个安全线。
举个例子：一台 4C8G 的机器，压到 1500 QPS 时 CPU 已经冲到 95%，响应时间飙到 2s。那它的「安全容量」就是 1000 QPS，而不是 1500。你想想看，这个冗余就是给你自己留的余地。
1.3.5 其他常见类型
除了上面四种，还有几个类型你需要知道：
| 类型 | 说明 | 典型场景 |
|---|---|---|
| 并发测试 | 多个用户同时操作同一资源 | 抢票、秒杀场景 |
| 尖峰测试 | 模拟短时间内流量脉冲 | 新闻推送、秒杀开始瞬间 |
| 配置测试 | 调整系统参数寻找最佳配置 | JVM 堆大小、连接池数调优 |
| 基准测试 | 固定环境下的参考性能数据 | 版本迭代前后性能对比 |
1.4 性能测试的流程框架
有了概念和类型，咱们还得知道「怎么做」。一个标准的性能测试流程，我把它归纳为六个步骤：
- 需求分析：搞清楚要测什么指标、达到什么标准。
- 场景设计：选择测试类型、设计负载模型（并发数、思考时间、数据量）。
- 环境准备：搭建压测环境，确认与生产环境差异。
- 脚本开发与验证：编写压测脚本，先跑一遍验证功能正确。
- 执行与监控：跑起来，同时采集服务器、数据库、中间件指标。
- 分析与调优：查瓶颈、改代码/配置、再验证，直到达标。
1.5 一个真实的案例
我负责过一套支付系统上线前的性能验证。当时业务方给的指标是「单机 500 QPS，P99 响应时间 300ms 以内」。我们先用负载测试，发现压到 400 QPS 时响应时间已经接近 400ms。分析发现是数据库连接池配置小了——默认 20 个连接，400 QPS 时排队严重。调整到 50 个后，500 QPS 顺利通过。
但是别急——我又做了稳定性测试。24 小时后，发现响应时间从 200ms 缓慢升到了 280ms，还在涨。后来查到是一条慢 SQL 随着表数据增长越来越慢。优化索引后，再压 48 小时稳定在 180ms。你看，如果只做负载测试，这个问题上线后一周才会暴露，那代价就大了。
所以我说，不同类型测试就像不同角度的探照灯，少了哪一盏，都可能留下阴影。希望你学完这一章，能真正理解「为什么需要这些类型」，而不是只会背定义。