周期与交付
一份压力测试报告通常会看哪些核心指标？
一份有价值的压力测试报告，不止是"压到多少 QPS 跑过了"那一行结论，至少要把成功率、响应时间（含 P95/P99 长尾）、吞吐量、资源占用、错误类型这五类指标讲清楚，并给出瓶颈定位和扩容建议。
滚水科技在交付前做压测时，通常会按以下几类整理结果：
- 成功率：分接口看，不只看总成功率。一个接口失败率 3% 看起来不高，但如果它是下单或支付接口，业务就已经废了。
- 响应时间：除了平均值，更重要的是 P95、P99。长尾延迟往往才是真实用户感受到的"卡"。我们会把 P99 和平均值的差距单独拎出来分析。
- 吞吐量/TPS：在不同并发档位下能稳定支撑多少业务请求，以及到哪个档位开始出现明显性能拐点。
- 服务器资源：CPU、内存、磁盘 IO、带宽、数据库连接池、慢 SQL、缓存命中率。瓶颈大多藏在这里。
- 错误类型与分布：是超时、连接被拒、5xx、数据库死锁，还是上游依赖挂掉。错误类型决定下一步该改代码、加资源还是改架构。
只列这些数字其实还不够。我们更看重报告的后半部分：
- 瓶颈定位：在某个并发档位下，到底是被哪个组件卡住的，是数据库、缓存、网关，还是单点服务。
- 承载推断：以现在的架构，估算能支撑的日活/峰值，以及离瓶颈还有多少冗余。
- 优化建议：每条建议要标注成本和预期收益，例如"加一台从库可缓解读压力，但写仍然是瓶颈"。
像 新能源智能充换电 这类有硬件设备并发上报的项目，我们还会在压测里加上"设备长连接 + 高频数据上报"的复合场景，单纯模拟接口请求很容易漏掉真实问题。
报告不是给研发自己看的，是要让业务方也能据此判断系统能不能撑住下一阶段的增长。