性能测试基础：目的、类型与工具选型

性能测试这件事，我见过太多团队把它当成「上线前跑一把」的过场。结果呢？线上流量一上来，系统直接雪崩。说白了，性能测试不是交作业，而是给系统做一次「压力体检」。你想想看，连自己的系统能扛多少并发都不知道，怎么敢上线？

一、性能测试到底为了什么？

我习惯把性能测试的目的归纳为三个核心点：

• 摸清系统的真实容量——到底能支撑多少用户同时在线？
• 找到系统的性能瓶颈——是数据库慢？还是网络带宽不够？
• 验证优化措施的效果——改完代码后，性能真的提升了吗？

记得有一次，我接手一个电商项目，团队说系统已经「优化好了」。结果我压测一跑，TPS 只有 200，CPU 却飙到 95%。一查，原来是日志框架的同步刷盘把 IO 打满了。你看，没有性能测试，这种问题根本发现不了。

二、三种核心性能测试类型

很多新手容易把负载测试、压力测试、稳定性测试混为一谈。其实它们各有各的用途。我画了一张图，帮你理清关系：

1. 负载测试

负载测试，说白了就是「模拟真实用户行为」。比如你的系统预期支撑 1000 个用户同时在线，那就模拟 1000 个并发请求，看看响应时间、TPS、错误率是否达标。

我在项目中习惯这样操作：

• 先按 50% 的预期负载跑一轮（500 并发）
• 再按 80% 跑一轮（800 并发）
• 最后按 100% 跑一轮（1000 并发）

每一轮都记录关键指标，对比看趋势。如果 80% 负载时响应时间已经翻倍，那说明系统容量可能被高估了。

2. 压力测试

压力测试的目标是「找到系统的天花板」。我会持续增加并发数，直到系统崩溃或响应时间不可接受。嗯，这里要注意：压力测试不是要把系统打垮，而是要找到那个「临界点」。

我曾经帮一个金融客户做压力测试，系统在 3000 并发时一切正常，加到 3200 时突然 502 满天飞。一查，是 Nginx 的 worker_connections 配置不够。这种问题，不做压力测试根本发现不了。

3. 稳定性测试

稳定性测试，也叫「长时间测试」。我会让系统在 70%-80% 的负载下持续运行 8 小时甚至 24 小时，观察内存、CPU、GC 等指标的变化趋势。

为什么这么做？因为很多问题不是瞬间爆发的，而是慢慢积累的。比如：

• 内存泄漏——每次请求泄漏 1KB，跑 8 小时后 OOM
• 连接池耗尽——连接回收不及时，慢慢把连接池占满
• 日志文件过大——日志轮转配置不对，磁盘写满

我记得有一次做稳定性测试，跑了 12 小时后 TPS 从 2000 降到了 800。一查，是某个缓存 key 没有设置过期时间，导致缓存越来越大，最终影响了查询性能。

三、性能测试工具怎么选？

工具选型这件事，我个人的经验是：没有最好的工具，只有最适合你场景的工具。下面这张表是我常用的对比：

工具	适用场景	优点	缺点
JMeter	HTTP/HTTPS 接口、数据库、消息队列	社区活跃、插件丰富、支持分布式压测	GUI 模式资源消耗大、脚本维护成本高
Gatling	高并发 HTTP 场景、实时流处理	基于 Scala、性能极高、报表美观	学习曲线陡峭、调试不方便
Locust	Python 技术栈、自定义协议	纯 Python 编写、扩展性强、支持分布式	单机并发能力有限、报表功能弱
wrk	快速压测、单机高并发	轻量级、性能极高、适合快速验证	只支持 HTTP、不支持复杂场景
k6	CI/CD 集成、云原生场景	脚本简洁、支持 JavaScript、内置仪表盘	社区相对较小、高级功能需付费

我个人的建议是：

• 如果你团队以 Java 为主，选 JMeter，生态最成熟
• 如果你追求极致性能，选 Gatling 或 wrk
• 如果你需要 CI/CD 集成，选 k6
• 如果你需要自定义协议，选 Locust

四、一个完整的性能测试流程

最后，我分享一下我在项目中常用的性能测试流程，一共 6 步：

1. 明确目标——预期并发数、响应时间要求、TPS 目标
2. 设计场景——模拟真实用户行为，包括思考时间、请求比例
3. 准备环境——隔离测试环境，确保与生产环境配置一致
4. 执行测试——先小规模验证，再逐步加压
5. 监控分析——关注 CPU、内存、IO、网络、GC 等指标
6. 报告输出——给出结论和优化建议

这 6 步看起来简单，但每一步都有坑。比如「准备环境」这一步，我见过有人用开发环境做压测，结果数据库连接数只有 10，压到 50 并发就挂了。这种测试结果，说白了没有任何参考价值。