一份压力测试报告通常会看哪些核心指标？

结论：压测报告不能只报 QPS；必须同时说明负载条件、业务成功率、长尾时延、资源瓶颈和停止加压后的恢复情况。

同样是 1000 QPS，小查询、图片上传和创建订单代表完全不同的工作量；同样是 P95 200 ms，在零错误与大量业务拒绝时也不是同一结果。滚水科技把报告写成“在什么条件下得到什么证据”，让业务、研发和运维能共同决定上线，而不是罗列仪表盘截图。

在安排里程碑、资源与验收节奏时，还可以对照 系统上线前为什么建议做压力测试？ 和 能不能把响应时间、修复时间这些服务承诺（SLA）写进合同？；这些内容补充了需要放在同一项决策中考虑的上下文。

先读测试条件，再读指标

报告首页应写目标版本、代码提交、环境拓扑与规格、数据量和分布、缓存状态、外部服务处理方式、测试时段及工具版本。负载模型写清每类业务占比、到达率或并发、思考时间、请求体大小、爬升方式、持续时间和峰值。没有这些信息，结果无法复现，也不能与下次报告比较。

报告维度	至少记录	常见误读	正确用途
业务结果	订单/上传/指令等端到端成功数、拒绝和重复	HTTP 200 就算业务成功	判断用户任务是否真正完成
流量与时延	吞吐、并发/到达率、P50/P95/P99、最大值	只看平均值或孤立 QPS	找到随负载变化的拐点和长尾
错误与降级	超时、4xx/5xx、业务错误、重试、降级命中	把限流全算成功或把预期拒绝全算故障	判断失败是否符合设计
资源与依赖	CPU、内存、GC、IO、连接、锁、队列、缓存和上游耗时	CPU 不满就认为没有瓶颈	把症状关联到具体限制
稳态与恢复	积压、水位、扩缩容、停止加压后的恢复时间	测试一停就结束记录	发现泄漏、雪崩和不可恢复状态

Grafana k6 的内置指标文档区分 Counter、Gauge、Rate 与 Trend，并建议从请求量、失败率和时延入手；Thresholds 文档展示了按百分位与错误率设置通过条件。报告可以采用这些概念，但滚水科技必须在测试前根据客户确认的业务高峰、用户等待容忍度、故障影响和预算提出阈值及其依据，不能要求客户凭空填写技术 SLO，也不能测试完后挑一个刚好通过的数字。

每个数字都要带分母和标签

成功率要区分传输成功和业务成功，并按核心场景统计。例如库存不足是预期业务拒绝，数据库超时是系统错误，两者不能混在一个失败率里。时延应说明测量点是在压测机、网关还是服务端，包含不包含 DNS、TLS、排队和第三方调用。OpenTelemetry 的 HTTP 指标语义约定为请求时长、活动请求、状态码和错误类型提供了统一命名思路，有助于把压测端与服务端观测关联起来。

吞吐必须与错误和时延同图观察：系统在过载后快速返回 500，QPS 反而可能更高。资源也不是只看平均 CPU；单核饱和、数据库锁、连接池、磁盘延迟、GC 暂停、消息消费者落后或供应商限额都可能先成为约束。建议附关键时间序列和追踪样本，说明瓶颈判断依据，而不是凭经验写“建议加服务器”。

结论应能直接支持一个决策

报告结尾至少回答：目标负载是否达到预设阈值；首次不达标发生在哪个负载台阶；主要限制和证据是什么；超过容量时系统怎样拒绝或降级；负载恢复后积压多久清空；建议是优化代码、调整资源、改变架构、设置限流还是接受风险。承载上限只对本次环境和模型成立，不能直接换算成日活人数。

优化建议要标注优先级、预期影响、代价和验证方法。例如增加只读副本可能缓解查询，但不能解决写锁；扩大应用实例若数据库已饱和，可能让故障更快。实施后用同一脚本与数据条件复测，并将结果与基线对比。报告还应保留原始数据、脚本和配置，方便审计异常或重复实验。

滚水科技不会用一次压测保证未来所有流量，也不将“测试工具显示 Pass”当作唯一上线条件。我们会在报告结尾提交达标与否、当前容量、主要瓶颈、优化或扩容建议、预计代价、复测条件和停止上线条件；平台账号、备份回滚、监控告警、严重缺陷和业务验收仍需分别检查。客户据此确认上线窗口和预算取舍，不需要自行解释仪表盘。压测报告的价值，是把容量和失败模式从猜测变成限定条件下可复现的证据。