性能测试基础：让数据说话
性能测试，说白了就是给系统做一次「体检」。我见过太多项目上线后才发现扛不住流量，那时候再改就晚了。今天咱们聊聊性能测试的三种核心类型、标准流程，以及我常用的几把「手术刀」。
一、三种核心测试类型
很多人分不清负载测试和压力测试的区别。我刚开始也犯过这个错，直到有一次把压力测试当负载测试做，结果线上出了大问题。咱们一个一个说清楚。
1. 负载测试（Load Testing）
负载测试的目标是：在预期流量下，系统能不能稳定运行。比如你预估双十一峰值是1万QPS，那就模拟1万并发，看看响应时间、错误率是否达标。
核心指标：平均响应时间 < 200ms，错误率 < 0.1%，CPU使用率 < 70%
我个人习惯把负载测试分成三档：70%负载、100%负载、120%负载。这样能看出系统在接近极限时的表现趋势。
2. 压力测试（Stress Testing）
压力测试就狠多了——不断加压，直到系统崩溃。目的是找到系统的「天花板」在哪里。
我曾经帮一个电商平台做压力测试，发现数据库连接池在500并发时就开始报错。嗯，这就是瓶颈。找到它，你才能针对性优化。
注意：压力测试一定要有熔断机制。我见过有人把系统压死，结果恢复花了两个小时。建议设置自动降级或限流。
3. 稳定性测试（Endurance Testing）
稳定性测试也叫「长跑测试」。系统跑个72小时，看看内存会不会泄漏、连接会不会耗尽。
我记得有一次做稳定性测试，跑了48小时一切正常，结果第50小时突然OOM了。排查发现是一个缓存对象没释放。这种问题，短时间测试根本发现不了。
| 测试类型 | 目标 | 持续时间 | 典型场景 |
|---|---|---|---|
| 负载测试 | 验证预期性能 | 10-30分钟 | 日常峰值验证 |
| 压力测试 | 寻找极限点 | 5-15分钟 | 容量规划 |
| 稳定性测试 | 发现长期问题 | 24-72小时 | 上线前验证 |
二、测试流程：五步走
很多新手上来就开压，结果数据一塌糊涂。我建议按这个流程来：
- 需求分析——搞清楚要测什么。是接口响应时间？还是吞吐量？
- 场景设计——模拟真实用户行为。比如登录、浏览、下单的比例。
- 脚本开发——用工具写测试脚本。这一步最耗时。
- 执行测试——先小规模验证，再逐步加压。
- 结果分析——看数据，找瓶颈，出报告。
我的经验：第2步最容易出错。很多人只测一个接口，但真实用户是混合操作的。建议用「用户行为模型」来设计场景。
三、常用工具：JMeter vs wrk
工具不在多，在于用对地方。我主要用两个：
1. JMeter
JMeter是图形化工具，适合复杂场景。你可以配置线程数、循环次数、定时器，还能加断言检查结果。
// 一个简单的JMeter测试计划
Thread Group:
- 线程数: 100
- Ramp-Up: 10秒
- 循环次数: 10
HTTP Request:
- 协议: https
- 域名: api.example.com
- 路径: /users/login
- 方法: POST
- 参数: {"username":"test","password":"123456"}
监听器:
- 聚合报告
- 响应时间图
我个人习惯用JMeter做稳定性测试。因为它能跑很久，而且报告很详细。
2. wrk
wrk是命令行工具，轻量、高效。适合快速压测单个接口。
# 一个简单的wrk命令
wrk -t12 -c400 -d30s http://api.example.com/users
# 参数说明：
# -t12: 12个线程
# -c400: 400个并发连接
# -d30s: 持续30秒
wrk的输出很简洁：
Running 30s test @ http://api.example.com/users
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 45.67ms 12.34ms 123.45ms 75.00%
Req/Sec 1.23k 123.45 1.56k 68.00%
36900 requests in 30.00s, 4.52MB read
Requests/sec: 1230.00
Transfer/sec: 154.00KB
选型建议：
- 复杂场景（登录+下单+支付）→ 用JMeter
- 单接口快速验证 → 用wrk
- 需要分布式压测 → 用JMeter + 远程代理
四、知识体系图
下面这张图帮你理清本章的核心逻辑：
五、避坑指南
最后分享几个我踩过的坑：
- 不要在生产环境做压力测试——我曾经见过有人直接在线上压，结果把数据库压挂了。一定要用预发环境或隔离环境。
- 监控要到位——压测时CPU、内存、IO、网络都要看。我习惯用Prometheus + Grafana实时监控。
- 数据要真实——别用全量缓存数据压测。真实场景下缓存命中率没那么高。
重要提醒：性能测试不是一次性的。每次代码变更、架构调整后，都应该重新跑一遍。我建议把性能测试集成到CI/CD流水线中。
好了，性能测试的基础就聊到这儿。记住一句话：没有数据，就没有优化。下次咱们聊聊如何分析测试结果，找到真正的瓶颈。
可可精品资料库