用可重复的业务场景表达性能目标，避免只写在线人数或平均响应时间而无法判断真实承载表现。
先说用户在做什么
“支持一千人”可能指注册人数、在线会话或同时操作人数，含义完全不同。性能需求应说明业务动作、请求节奏和业务比例，例如查询与提交是否同时发生、导出是否属于长任务。已有业务可参考监控和日志；新业务可提出预测模型，但要标明假设并由相关方确认。否则测试完成后即使得到漂亮数字，也未必回答了实际问题。
把条件和阈值写在一起
一个可执行的指标至少应关联软件版本、部署资源、数据规模、负载模型、持续时间、统计口径和通过条件。响应时间要说明测量起止点，失败率要说明哪些错误计入；性能目标不能脱离业务正确性。Grafana k6 的官方阈值文档展示了用响应分位值与错误率表达通过条件的方法，但其中示例数字不是任何行业统一要求。
示例：把一句话改成测试约定
以下数值仅是写法示例，不是推荐指标，也不是格修科技测试成果。可以将“查询很快”改成：在约定测试环境、十万条合成记录下，持续二十分钟以每秒十次请求执行约定查询，统计稳态阶段响应的第九十五百分位，目标低于两秒，同时核对业务结果和错误率。项目还应单独确定预热、缓存状态、查询分布及失败判定，不能只复制这一组数字。
别让平均值掩盖问题
平均响应较低时，仍可能有部分请求严重超时；因此宜同时观察分位值、错误、吞吐和时间趋势。吞吐上涨也不一定意味着处理能力更好，可能包含失败重试或错误返回。资源曲线、数据库等待及队列积压有助于解释结果，但应先观察再定位，不能见到 CPU 较高就直接判定需要扩容。
复测必须保证条件可比
优化前后保持业务模型、数据规模、环境和统计方法可比；若升级了硬件、减少了数据或修改了缓存，应记录为条件变化。报告宜说明是否达到目标负载、发生了哪些瓶颈现象、哪些限制尚未验证。上线决策还要考虑实际流量变化和依赖服务，不应把一次性能测试的最大吞吐直接写成长期容量承诺。
关键事实
指标组成：负载、环境、数据、时长、统计口径与阈值
判断原则：性能与业务结果正确性共同成立
常见问题
一定要用第九十五百分位作为验收指标吗？
不一定。分位值、阈值和统计窗口要根据业务体验与合同要求确定；关键是定义一致、记录充分，并同时检查错误与数据正确性。
