本文目录
压测通过，不能只意味着 HTTP 接口没有报错
有效的压测验收应预先约定测试范围、数据规模、负载模型、业务正确性、延迟与失败阈值，并证明负载发生器达到计划压力。平均负载、峰值突增和长时间运行解决不同问题，需按上线风险选择。检查 HTTP 状态之外，还要核对订单、库存、审批或任务最终状态；测试结束后验证积压清空和资源恢复。报告必须保留代码版本、环境差异、计划与实际负载、失败分类和未覆盖依赖，性能目标由业务决定。
压测方案如何选择
| 测试类型 | 适合回答的问题 | 单独使用的不足 |
|---|---|---|
| 常规负载 | 在日常业务比例下延迟与错误是否满足目标 | 无法说明活动突增和极限容量 |
| 阶梯压力 | 随到达率增加，在哪个阶段发生排队或性能拐点 | 短阶段可能漏掉持续运行后的资源泄漏 |
| 突增测试 | 入口瞬时增长时限流、连接和预热是否可用 | 只测突发不能替代持续高峰 |
| 持续与恢复 | 长时间负载后资源是否稳定，停止加压能否恢复 | 恢复通过也不证明所有数据写入正确 |
适用边界：先约定哪些环境和依赖能够测试
本文适合应用 API、数据库访问和异步任务的性能验收。真实支付、短信、外部库存和合作方接口必须在授权范围内使用隔离配置或可控替身，避免测试污染业务与额外费用。
替身能验证调用方式与故障处理，却不能证明真实提供方的生产容量。报告应分开记录真实依赖和替代依赖，并说明替身延迟、错误与限额模型。浏览器页面体验还需要前端加载与网络条件测试，纯接口压测不能宣称整站体验达标。
为每轮测试预先安排数据生命周期，包含建立、占用、释放和清理。若无法让任务在当次测试内完成，至少记录可追踪标识并安排后续对账。测试报告不能把尚未处理的异步任务全部视作成功，也不能通过清空队列掩盖最终交付缺口。
- 列出访问环境、账号、数据清理规则、停止条件和执行负责人。
- 保留生产与测试的机器、数据库、网络、证书和数据规模差异。
将用户路径写成有业务断言的脚本
场景应包含前置身份、数据准备、核心操作和结果校验，而不只是循环请求一个最快接口。登录复用、业务等待、分页与读写比例应来自真实行为或明确假设。
HTTP 200 可能表示“受理中”或业务失败，接口返回成功也可能没有正确落库。提交订单后应核对业务标识、状态、金额与库存关系；审批后检查状态转换和权限。将脚本逻辑错误、认证失败、业务拒绝、系统异常分别统计，不能把全部响应都算作有效吞吐。
- 为每个业务动作设置可执行的结果检查和最终状态对账。
- 测试账号与业务标识分散使用，再单独安排热点和重复提交场景。
测试数据决定结果是否有解释力
空数据库和反复访问同一条已缓存记录通常会高估容量。真实系统还有深分页、多租户隔离、时间范围筛选、大对象与历史数据倾斜，这些因素应纳入数据样本。
脱敏数据需保留字段长度、关联关系、分布和代表性基数。无法复制生产时，用合成数据明确标注生成规则，并记录哪些倾斜尚未覆盖。预热场景和冷启动场景分开执行，避免先压一次便把所有缓存命中条件带入验收。
- 记录表大小、索引、热点占比、对象尺寸以及缓存初始状态。
- 保证脚本读取不会提前耗尽数据，写入后有可复核的清理与对账方法。
证明计划压力真正到达被测系统
负载发生器也受 CPU、内存、连接、带宽和虚拟用户分配限制。发送端力不够时，看似稳定的后端并不代表通过目标负载，应同时对照入口收到量与发生器完成量。
k6 的 dropped_iterations 表示计划迭代未启动，可能源于执行器分配不足，也可能与迭代时间变长有关。它不是业务成功率的替代指标。把计划迭代速率、实际请求率、入口接收量和有效业务完成量放在同一时间线上，确认一轮脚本包含多少 HTTP 请求。
- 先对隔离的轻量目标校验发生器，不把发生器瓶颈当成系统极限。
- 对未启动、被打断、超时和检查失败分别计数并解释。
实施步骤：冻结标准，再执行与复测
依次完成范围与阈值评审、脚本小流量验证、常规负载、阶梯增压、必要的突增或持续测试、恢复与数据对账。每次改动后只在同样条件下比较，出现新瓶颈再调整测试重点。
k6 的 checks 用于检查响应，thresholds 用于把聚合指标判为通过或失败；只写检查而没有整体阈值，自动化验收可能不能按预期失败。业务阈值应按关键路径分别约定，并给出时间窗、失败口径和停止条件，不照搬示例的毫秒数。
- 执行前保存版本、配置、测试数据快照和完整脚本参数。
- 性能变更报告注明收益、额外资源、正确性影响与未解决瓶颈。
报告验收：失败阶段与恢复过程都要留下
正式报告应包括每级压力的实际负载、成功率、分位延迟、错误类型、资源与依赖等待，以及峰值过后的恢复曲线。只提供最终截图会丢掉压力不足、失败重试和积压等关键条件。
在目标负载下检查最终业务记录；在超过能力的阶段检查系统能否有序拒绝并保持数据正确。停止测试后继续观察队列年龄、连接数和内存，确认没有长期阻塞任务。环境不足或依赖限额造成的限制应作为下一步条件，而不是删除失败记录。
不同角色应能复核与其有关的证据：业务负责人看完成状态和体验，技术负责人看负载、资源与失败原因，采购方看约定指标和范围。出现争议时使用同一脚本与数据重新执行，并固定观察窗口，而不是各自截取最好的结果作为验收依据。
- 把达标阶段、未达标阶段与未覆盖场景分别写清。
- 保留可重放脚本、关键原始指标与业务对账结果供双方复核。
需求讨论中的问题
达到约定 QPS 就算压测通过吗？
还要在这个负载下满足关键业务成功率、延迟与数据正确性要求，并证明计划流量真实到达。发送了很多失败请求不能作为有效容量。
可以直接在生产压测吗？
需有明确授权、流量范围、隔离数据、影响观察与立即停止手段。先在隔离环境校验脚本和限制，再按业务风险决定是否进行受控生产验证。
为什么短压测通过，上线后仍然变慢？
短测试可能没有覆盖数据规模、缓存淘汰、定时任务叠加、连接泄漏和长期积压。按风险补充持续测试，并记录与生产的差异，才能解释验收结论。
性能压测可以验收的七个条件
可逐项勾选，辅助本次阅读；刷新页面后不保留。
参考资料
技术概念可进一步阅读以下资料；文中的业务场景与实施清单用于方案讨论。
- Grafana k6：Thresholds
核验 checks 与 thresholds 的职责，以及阈值用于整体性能通过与失败判定。
- Grafana k6：Dropped iterations
核验未启动迭代的含义与虚拟用户分配、迭代耗时之间的关系。
需要评估现有系统的性能瓶颈？
提供关键业务路径、真实峰值、服务器与数据库配置，以及现有压测或故障记录，月弦科技可据此梳理优化顺序、实施范围和可验证的验收条件。