性能测试方法论：基准测试、负载测试、压力测试、稳定性测试、容量规划
性能测试不是上来就压接口。我见过太多团队，拿着JMeter就开干，结果测了半天，连自己在测什么都不清楚。
说白了，性能测试有五种基本类型。每种类型解决不同的问题。搞混了，结论就是错的。
核心观点：五种测试类型，对应五个不同的问题。基准测试问「多快」，负载测试问「能扛多少」，压力测试问「极限在哪」，稳定性测试问「能跑多久」，容量规划问「该扩多少」。
1. 基准测试：先知道「正常」长什么样
基准测试，就是给系统拍一张「素颜照」。没有压力，没有干扰，就看它最原始的性能。
我个人习惯，接手一个新系统时，第一件事就是跑基准测试。为什么？因为后面所有测试的结论，都要跟基准对比才有意义。
我的经验：基准测试要在「干净」环境下跑。我曾经在测试环境里跑基准，结果发现响应时间比预期慢了3倍——查了半天，原来是旁边有人在跑大数据任务。所以，跑基准前，先确认环境是「空」的。
基准测试通常关注几个核心指标：
- 响应时间：单个请求从发出到收到响应的时间
- 吞吐量：单位时间内能处理的请求数
- 错误率：请求失败的比例
- 资源消耗：CPU、内存、磁盘IO、网络IO
举个例子，一个简单的HTTP接口基准测试：
# 使用wrk做基准测试
wrk -t4 -c10 -d30s http://api.example.com/users
# 结果解读
Running 30s test @ http://api.example.com/users
4 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.34ms 3.21ms 45.67ms 85.23%
Req/Sec 845.67 56.23 1023.00 78.45%
25370 requests in 30.00s, 45.67MB read
Requests/sec: 845.67
Transfer/sec: 1.52MB你看，基准测试告诉我们：这个接口在无压力下，平均延迟12ms，每秒能处理845个请求。这就是「正常」的样子。
3. 负载测试：看系统「能扛多少」
基准测试知道了「正常」，负载测试就要看「能扛多少」。
说白了，就是逐步增加并发用户数，看系统什么时候开始「扛不住」。
我一般这样设计负载测试：
- 从基准值开始，比如100并发
- 每2分钟增加100并发
- 持续观察响应时间和错误率
- 找到「拐点」——响应时间突然飙升的那个点
注意：负载测试不是压力测试。负载测试的目标是找到「系统能稳定承载的最大负载」，而不是把系统打垮。我曾经见过有人把负载测试跑成了压力测试，结果系统挂了，业务也停了——嗯，那是个惨痛的教训。
负载测试的结果，通常用一张「吞吐量-延迟」曲线图来表示。你会发现，当并发数超过某个阈值后，吞吐量不再增加，延迟却直线上升。那个阈值，就是系统的「最佳负载点」。
3. 压力测试：找到系统的「极限」
压力测试，就是故意把系统往死里压。看它什么时候崩溃，崩溃后能不能恢复。
你可能会问：「为什么要故意搞崩系统？」
原因很简单：生产环境不会提前告诉你它要出问题。压力测试就是模拟「最坏情况」——比如双十一的流量洪峰、突发的爬虫攻击。
压力测试的关键点：
- 极限值：系统在崩溃前的最大吞吐量是多少？
- 崩溃行为：是优雅降级，还是直接挂掉？
- 恢复能力：压力解除后，系统能自动恢复吗？
- 数据一致性：崩溃过程中，有没有数据丢失或损坏？
避坑指南：我曾经在压力测试中，发现系统崩溃后数据库连接池没有释放，导致重启后依然无法提供服务。从那以后，我每次压力测试都会检查「崩溃后的资源清理」——连接池、线程池、文件句柄，一个都不能漏。
4. 稳定性测试：看系统「能跑多久」
稳定性测试，也叫「耐力测试」或「浸泡测试」。说白了，就是让系统在中等负载下跑上几个小时甚至几天，看它会不会出问题。
为什么需要这个？因为很多问题不是立刻暴露的——内存泄漏、连接池耗尽、磁盘写满，这些都需要时间才能显现。
我一般这样设计稳定性测试：
- 负载水平：取负载测试中「最佳负载点」的70%-80%
- 持续时间：至少4小时，关键系统建议24-72小时
- 监控指标：除了常规指标，还要关注GC频率、堆内存使用趋势、线程数变化
举个例子，我曾经帮一个金融系统做稳定性测试。跑了12小时后，发现响应时间从10ms慢慢涨到了50ms。查了半天，发现是日志框架的异步队列满了，导致业务线程阻塞。这种问题，跑短时间测试根本发现不了。
小技巧：稳定性测试中，重点关注「趋势」而不是「绝对值」。响应时间从10ms涨到15ms不可怕，可怕的是它一直在涨，没有收敛的趋势。那说明系统存在资源泄漏。
5. 容量规划：回答「该扩多少」
容量规划，是性能测试的「终极目标」。前面四种测试都是在「发现问题」，容量规划是在「解决问题」。
说白了，就是根据业务增长预测，算出需要多少服务器、多少带宽、多少数据库连接。
容量规划的核心公式：
所需资源 = (预估峰值流量 / 单机承载能力) × 冗余系数
其中：
- 预估峰值流量 = 日常流量 × 峰值倍数（比如双十一可能是日常的10倍）
- 单机承载能力 = 从负载测试中得出的最佳负载点
- 冗余系数 = 1.5 ~ 2.0（留出余量，应对突发情况）举个例子：
| 指标 | 数值 |
|---|---|
| 日常QPS | 1000 |
| 峰值倍数（双十一） | 10x |
| 预估峰值QPS | 10000 |
| 单机承载能力（来自负载测试） | 2000 QPS |
| 所需机器数（不含冗余） | 10000 / 2000 = 5台 |
| 冗余系数 | 1.5 |
| 最终所需机器数 | 5 × 1.5 = 8台（向上取整） |
注意：容量规划不是「算一次就完事」。业务在变，系统在变，容量规划也要持续迭代。我建议每季度做一次容量评估，每次大版本发布后重新跑一次负载测试。
总结一下
五种测试类型，其实是一个完整的闭环：
- 基准测试：建立基线，知道「正常」
- 负载测试：找到上限，知道「能扛多少」
- 压力测试：验证极限，知道「崩溃后怎么办」
- 稳定性测试：检验耐力，知道「能跑多久」
- 容量规划：指导扩容，知道「该扩多少」
嗯，这五种方法，缺一个都不完整。我见过太多团队只做负载测试，结果上线后系统跑了两天就挂了——那就是忽略了稳定性测试。也见过只做压力测试的，结果连系统正常能扛多少都不知道——那就是没做负载测试。
所以，别偷懒。五种测试，一个都不能少。
最后说一句：性能测试不是一次性的工作。系统在变，流量在变，代码在变。每次大版本发布、每次架构调整，都应该重新跑一遍这五种测试。只有这样，你才能真正掌握系统的「脾气」。