性能测试工具怎么选
选性能工具不是选最流行的，而是匹配场景与团队：协议支持（HTTP、WebSocket、gRPC）、脚本能力（复杂业务编排还是简单打流）、分布式需求、报告与分析深度、CI 集成难度、团队语言栈。先明确要回答的问题——找容量、查瓶颈还是守回归——再从候选工具里挑，避免为了工具改变验证目标。
基本信息
| JMeter | 协议广、生态成熟、分布式能力完善，界面驱动，脚本较重 |
|---|---|
| k6 | JavaScript 脚本、命令行优先、指标与阈值原生，CI 友好 |
| Locust | Python 脚本、事件循环高并发、可读性强，适合代码化团队 |
| wrk | 轻量高吞吐的基准工具，复杂编排弱，适合快速摸阈值 |
| Gatling | Scala 脚本、报告出色、模型清晰，团队语言门槛较高 |
| 选择维度 | 协议、场景复杂度、分布式、报告、CI 集成、学习成本 |
场景与工具匹配
| 场景 | 优先考虑 | 理由 |
|---|---|---|
| CI 门禁短压测 | k6 | 脚本轻、阈值与退出码原生 |
| 复杂业务链路 | JMeter 或 Locust | 编排与参数化能力强 |
| 高并发基准 | wrk 或 k6 | 压资源占用低、吞吐高 |
| WebSocket 与流式 | k6 或自研客户端 | 协议支持与自定义校验 |
| 大规模分布式 | JMeter 分布式或云压测 | 执行机扩展与结果聚合成熟 |
典型使用场景
- 新项目立基线：按协议与团队栈选择主力工具，一次选定长期复用。
- 补充专项：主工具不擅长的协议或场景，用轻量工具补位。
- 人员流动：选择生态与文档成熟的工具，降低交接成本。
- 报告需求：管理层要趋势与结论时，优先指标原生、导出方便的工具。
- 成本核算：云压测按量计费与自建压力机集群的成本对比。
工具不制造结论：脚本模型、数据量级与观测设计决定结论质量，工具只是执行载体。
允许双工具：一个守 CI 回归，一个做专项分析，是常见且合理的组合。
换工具要有理由：迁移成本含脚本重写与人员培训，评估清楚再动。