性能测试基础：测试类型、工具选型与场景设计
性能测试这事儿，说白了就是给系统「把把脉」。
我见过太多团队，上线前拍脑袋说「没问题」，结果一上线就被用户流量打趴下。嗯，今天咱们就把性能测试的底裤扒干净——测试类型怎么选、工具怎么挑、场景怎么设计。
一、性能测试的三大类型
很多人把负载测试、压力测试、稳定性测试混为一谈。其实它们各有各的用处。我习惯这么区分：
| 测试类型 | 核心目标 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 负载测试 | 摸清系统在预期负载下的表现 | 日常业务峰值（如双11的80%流量） | 负载曲线没做阶梯，直接上满，结果系统挂了都不知道瓶颈在哪 |
| 压力测试 | 找到系统的极限和崩溃点 | 突增流量、DDoS模拟 | 有一次压到极限，数据库连接池爆了，但监控没配告警，半夜才被用户投诉 |
| 稳定性测试 | 验证长时间运行下的资源泄漏 | 7×24小时跑批任务、长连接服务 | 有个服务跑了3天，内存涨了2GB，GC日志一看，线程池没释放 |
一句话总结：负载测试看「能不能扛住」，压力测试看「扛到什么时候崩」，稳定性测试看「扛久了会不会出问题」。
二、测试工具选型：JMeter、wrk、ab怎么选？
工具选不对，测试白费。我个人的经验是：
1. JMeter —— 全能型选手
适合复杂场景。比如需要登录态、参数化、断言、分布式压测。我曾在项目中用它模拟3000用户并发下单，配合Grafana看实时曲线，效果不错。
- 优点：支持协议多（HTTP、JDBC、JMS）、图形化界面、插件丰富
- 缺点：资源消耗大（Java写的嘛）、脚本维护成本高
- 适用场景：全链路压测、接口回归、复杂业务流
2. wrk —— 轻量级利器
如果你只想测HTTP接口的吞吐量，wrk是首选。它基于C语言，单机就能压出几十万QPS。
# 一个简单的wrk命令
wrk -t12 -c400 -d30s http://localhost:8080/api
# 参数说明：
# -t12：12个线程
# -c400：400个并发连接
# -d30s：持续30秒我记得有一次线上排查慢接口，用wrk一压，发现TPS只有200，再配合火焰图，秒级定位到是JSON序列化太慢。
3. ab（Apache Bench）—— 老牌工具
简单粗暴，适合快速验证。但功能有限，不支持动态参数。
ab -n 10000 -c 100 http://localhost:8080/说实话，我现在很少用ab了。除非是临时在服务器上测一下，懒得装其他工具。
| 工具 | 并发能力 | 学习成本 | 我的推荐指数 |
|---|---|---|---|
| JMeter | 高（可分布式） | 中 | ⭐⭐⭐⭐⭐ |
| wrk | 极高（单机百万级） | 低 | ⭐⭐⭐⭐ |
| ab | 中 | 极低 | ⭐⭐⭐ |
我的建议：团队里至少备两个工具——JMeter做复杂场景，wrk做快速压测。别只依赖一个，否则遇到瓶颈时你都不知道是工具的问题还是系统的问题。
三、测试场景设计：从业务出发
场景设计是性能测试的灵魂。你想想看，如果场景设计错了，压出来的数据就是废纸。
1. 基于业务模型设计
别自己瞎编并发数。我一般这么做：
- 拉取线上Nginx日志，分析真实用户行为
- 统计接口调用比例（比如登录10%、搜索30%、下单5%）
- 按比例构造混合场景
2. 阶梯式加压
不要一上来就满负荷。我习惯用「爬坡」的方式：
# JMeter中设置阶梯线程组
- 阶段1：50并发，持续2分钟
- 阶段2：100并发，持续2分钟
- 阶段3：200并发，持续2分钟
- 阶段4：500并发，持续5分钟（观察是否崩溃）为什么要这样？因为你可以看到系统在哪个点开始「拐弯」——比如响应时间突然飙升，或者错误率开始出现。
3. 数据准备要真实
我曾经犯过一个低级错误：压测数据全是「张三」「李四」这种简单数据，结果数据库缓存命中率100%，压出来性能极好。上线后真实数据一进来，缓存全失效，系统直接雪崩。
避坑指南：压测数据要模拟真实分布。比如用户ID要随机、商品SKU要多样、时间戳要分散。最好直接从生产环境脱敏一份数据出来。
4. 监控要到位
没有监控的压测就是盲人摸象。我每次压测都会盯着这几个指标：
- TPS/QPS（吞吐量）
- 响应时间（P50、P95、P99）
- 错误率（<1%算健康）
- CPU、内存、磁盘IO、网络带宽
- GC频率和停顿时间
四、知识体系总览
下面这张图，是我自己梳理的性能测试核心逻辑。你照着这个框架去设计，基本不会跑偏。
核心思路：先定类型 → 再选工具 → 设计场景 → 配好监控。每一步都别跳，跳了就是给自己埋雷。
好了，性能测试的基础框架就这些。你回去可以拿一个自己的服务试试，先跑个wrk看看吞吐量，再用JMeter模拟真实用户行为。遇到问题别慌，性能优化这事儿，就是「测→发现→改→再测」的循环。
想要更多资料，联系可可