压测前先写什么？吞吐、延迟、错误率与成功标准
先写要支持哪项决定
压测可以用于判断新版本是否退化、某次活动的容量是否足够，或一台节点故障后剩余系统能否承载业务。目的不同，场景和成功标准也不同。没有明确问题，单纯把并发加到报错，只能得到某种特定条件下的极限现象。
开始前写出业务流程、请求比例、数据规模和目标持续时间。例如假设测试一个文档站，文章浏览、搜索和下载占比不同，不能只压最轻的静态首页，却把结果称为整站容量。
测试仅在自有或明确获授权的环境和范围内进行。外部支付、邮件、短信等依赖应隔离或使用提供方允许的测试方式，避免压力流量产生真实业务动作。
定义成功请求和延迟口径
HTTP返回200不一定代表业务成功。应用可能用200返回错误JSON，也可能要求响应中存在某个字段。因此，应同时验证传输结果和必要的业务断言，并记录失败原因分类。
延迟可以看平均值和百分位，但应说明测量范围。例如客户端观察的总时间与应用内部处理时间并不相同，连接建立、TLS和网络等待可能只出现在前者。比较两个版本时必须保持同一口径。
k6的阈值机制可以把错误率、请求耗时等指标转成通过或失败条件。工具负责执行判断，阈值仍应来自业务目标，而不是机械复制文档示例。k6阈值说明
负载模型决定实际施加的压力
固定虚拟用户数的封闭模型中，用户完成一次操作后再开始下一次；系统变慢时，实际请求到达率可能随之下降。开放模型按预定到达节奏发起迭代，更适合某些外部请求持续到来的情景。两种模型回答的问题不同。k6负载模型文档
假设活动入口每秒持续迎来新访问，如果只使用固定用户等待响应的模型，服务变慢后压测端可能自动“放慢”，从而低估拥塞。反过来，内部固定人数的后台操作则可能更接近封闭模型。
还要检查压测机自身CPU、连接数和网络。生成端达到上限后，请求量不再增加，并不能证明被测服务器容量稳定。报告中应保留压测端资源状态和未能启动的迭代等信息。
把测试拆成阶段并设停止条件
先用很小负载验证脚本、数据和监控，再逐步增加到目标水平，保持一段符合业务需求的观察时间。需要研究恢复能力时，可在受控环境停止施压后继续观察队列与资源是否回落。
成功标准应同时包含吞吐、延迟和错误，还可增加队列等待、资源余量等约束。假设目标是持续处理某个业务量且高百分位延迟不超过约定值，那么仅达到请求量但错误大量增加，应判为未通过。
设置明确停止条件，例如生产关键流程受到非预期影响、数据库空间接近保护边界或外部依赖出现异常。停止应有责任人和可执行入口，避免测试脚本失控后只能等待服务器自行恢复。
报告写明可以推广到哪里
保存应用版本、实例规格、网络路径、缓存状态、数据量和测试脚本版本。冷缓存与热缓存结果应分别标记，空数据库测试也不能代表真实生产数据规模。
结论可以写成“在所列环境与请求比例下，目标阶段满足这些阈值”，并说明未覆盖的登录人数、地区或突发模式。不要把一次压测的最高数字包装成供应商对所有业务的性能承诺。
若未通过，应根据监控定位瓶颈，再只修改相关因素后复测。压测的价值是给容量和发布决策提供有边界的证据，成功标准应在运行前确定，而不是看到结果后再放宽。