系统上线前一切正常，大促流量一来就雪崩——这几乎是每个技术团队都经历过的噩梦。性能测试的价值不在于跑出一个漂亮的 TPS 数字，而在于提前找到系统的瓶颈点与容量边界。本文从指标体系、工具选型、场景设计到常态化落地，完整讲清性能测试该怎么做。

先说指标。很多团队只盯着吞吐量，这是典型误区。一套完整的性能指标至少包含四个维度：响应时间（关注 P95、P99 而非平均值，平均值会掩盖长尾问题）、吞吐量（TPS/QPS）、并发能力（系统能同时承载的活跃用户数）、资源水位（CPU、内存、磁盘 IO、网络带宽、连接池占用）。此外还要看错误率曲线，很多系统在压力上升时不是变慢，而是直接开始报错，这类拐点比响应时间更能说明容量上限。

工具层面，JMeter 依然是开源阵营的中坚力量。它支持 HTTP、HTTPS、TCP、WebSocket、JDBC 等丰富协议，可以模拟高并发请求并输出多维度监控数据，插件生态成熟，支持分布式压测来模拟大规模用户访问。对于需要写代码定义场景的团队，Gatling 和 k6 提供了更好的可维护性和更低的资源开销，尤其 k6 用 JavaScript 描述场景，天然适合放进代码仓库做版本管理。云压测平台则解决了压力机资源和多地域出口的问题，适合验证 CDN、跨区域部署的真实表现。

场景设计是最容易被敷衍的一环。基准测试用于建立单接口的性能基线；负载测试逐步加压，观察系统在预期流量下的表现；压力测试持续加压直到系统崩溃，找出真实容量上限和失效模式；稳定性测试用中等压力跑够 8 到 24 小时，专门捕捉内存泄漏、连接泄漏、日志堆积这类慢性病；峰值测试模拟流量瞬间冲高，验证限流降级和弹性扩容是否真的生效。这五类场景缺一不可，只跑其中一两种得出的结论往往具有误导性。

压测数据的真实性同样关键。用固定的单一用户账号压测，会让缓存命中率虚高，得出的数字比真实场景乐观数倍。正确做法是构造符合生产分布的参数化数据集，包含冷热数据混合、不同数据量级的账号、以及合理比例的异常输入。压测流量还应做好标记，避免污染生产数据和业务报表。

找到瓶颈之后，定位手段要跟上。全链路追踪能快速判断耗时集中在哪个服务，火焰图定位到具体方法，数据库慢查询日志和执行计划揭示索引问题，GC 日志暴露内存配置不合理。常见瓶颈按出现频率排序大致是：数据库慢查询与锁竞争、连接池配置过小、序列化开销、同步阻塞调用、日志同步写盘、以及不合理的循环远程调用。

最后是常态化。性能测试不该是上线前的一次性活动。将轻量级性能用例接入 CI/CD 流水线，代码提交后自动触发，与历史基线对比，一旦关键接口 P99 劣化超过阈值就阻断合并，这就是性能回归门禁。压测结束后自动生成可视化报告并推送到团队群，让性能数据像单元测试覆盖率一样成为日常可见的工程指标。

总结：性能测试的终极目标是把"能扛多少"从猜测变成可度量、可复现、可持续监控的事实。指标看长尾，场景要完整，数据要真实，瓶颈要定位到行，流程要嵌入流水线。做到这五点，大促之夜才能睡得安稳。