可验收的性能目标，核心是把业务诉求写成能复算、能判定的条款。一条完整的目标至少包含业务场景、负载与数据规模、指标及阈值、统计口径、判定人和判定时点。本文按“选指标—定口径—算结果—下结论”的顺序，说明性能测试计划中如何定义这些条款，并给出订单提交链路的填写示例与阈值依据说明。
要点总览（TL;DR）
- 可验收的性能目标要写成一句话：在什么负载下执行什么场景，哪个指标在什么时间窗内按什么口径统计达到什么阈值，由谁在什么时点判定。
- 指标选择围绕响应时间、吞吐量、错误率和资源占用四类分工，场景范围按核心链路取舍，并写明本轮不纳入的部分。
- 每个指标都要有公式、单位、分子分母、统计时间窗和异常计入规则；分母为零或样本不足时判为数据无效，不能记为通过。
- 判定规则要在压测前确定，明确是全部硬指标满足才通过，还是核心指标满足加观察指标记录，未达标项记录差距并安排复测。
- 阈值来自业务基线、历史数据或容量规划，结论受测试环境差异、负载模型偏差和版本时效限制，单次通过不等于生产环境同等表现。
验收目标要回答哪几个问题
性能目标之所以经常在验收阶段产生争议，往往是因为写成了“系统响应要快”“支持高并发”这类无法判定的表述。可验收的目标需要固定六个要素：场景、负载、指标、阈值、口径、判定。缺任何一项，结论都可能被重新解释。
这六个要素对应四个必须回答的问题：
- 业务场景与用户行为：用户在什么入口、按什么操作顺序、以什么比例访问系统。例如“订单提交”是单次点击提交，还是包含加购、选券、支付确认的完整链路。
- 负载与数据规模：并发用户数、请求速率、数据集大小、预热状态。负载要能换算成业务请求量，而不是只写一个并发数字。
- 指标、阈值与时间窗：看哪个指标、达到什么值算通过、在哪个统计区间内取数。阈值要带单位和比较方向，如“P95 响应时间 ≤ 800 ms”。
- 判定人与判定时点：谁确认目标、谁签署结论、在压测结束后多久出判定、复测由谁发起。
把上述要素串成一句话，就是一条可验收目标的基本结构：在〔负载条件〕下执行〔业务场景〕，〔指标〕在〔时间窗〕内按〔口径〕统计达到〔阈值〕，由〔角色〕在〔时点〕判定通过或不通过。后续章节的指标选择、口径定义和判定流程，都是围绕这句话展开的。
指标与范围：选哪些指标、覆盖哪些场景
指标不是越多越好。性能验收常用的四类指标各有分工：响应时间描述用户等待，吞吐量描述系统处理能力，错误率描述请求失败比例，资源占用描述服务器侧的承载余量。四类指标组合起来才能支撑一个结论，单独看任何一类都容易误判。
| 指标类别 | 回答的问题 | 常见写法 | 使用注意 |
|---|---|---|---|
| 响应时间 | 用户等多久 | P95、P99 响应时间，单位 ms | 需说明统计的是服务端处理时间还是端到端时间 |
| 吞吐量 | 单位时间能处理多少业务 | 每秒事务数（TPS）、每秒请求数（QPS） | 需与并发数、思考时间一起给出，否则不可比 |
| 错误率 | 多少请求失败 | 失败请求数 ÷ 总请求数 × 100% | 需定义哪些状态码或异常计入失败 |
| 资源占用 | 服务器还有多少余量 | CPU、内存、连接池使用率峰值 | 需注明采样间隔和统计的机器范围 |
场景范围要围绕核心链路取舍。判断标准可以是：该链路是否直接产生交易或核心业务结果、故障时用户是否可感知、是否位于本次变更的影响面内。核心链路（如下单、支付回调）纳入验收；边缘场景（如后台导出、低频配置页）可以纳入观察但不设硬阈值，或明确排除并写明理由。
并发用户与业务请求量之间需要换算关系。常见做法是用“并发用户数 × 每用户单位时间请求数”估算请求速率，再结合业务峰值时段的比例校准。如果只写“1000 并发”，不同思考时间和操作路径下产生的压力差异很大，结论无法复现。范围表里还应有一列“本轮不纳入”，例如第三方支付网关的真实扣款、跨机房容灾切换，避免验收时被临时追加要求。
数据口径：分子分母、时间窗与缺失值
口径决定同一份压测数据能否得出同一个结论。每个指标都应写清公式、单位、分子分母、统计时间窗和采样方式，并事先约定异常数据的计入规则。
| 指标 | 公式与单位 | 时间窗与采样 | 异常计入规则 |
|---|---|---|---|
| P95 响应时间 | 将时间窗内全部成功请求的响应时间升序排列，取第 95 百分位值，单位 ms | 压测稳定运行后连续 10 分钟，剔除前 2 分钟预热数据 | 超时请求不计入百分位样本，单独计入错误率 |
| 错误率 | 失败请求数 ÷ 总请求数 × 100% | 与响应时间同一时间窗 | HTTP 5xx、连接超时、业务返回码异常均计为失败；4xx 中属于参数校验的按约定单列 |
| 吞吐量 | 时间窗内成功事务数 ÷ 时间窗秒数，单位 TPS | 同一时间窗，按分钟粒度取稳定段均值 | 失败事务不计入成功事务数 |
| CPU 峰值使用率 | 时间窗内各采样点使用率的最大值，单位 % | 采样间隔 10 秒，覆盖全部应用节点 | 取所有节点中的最高值，并注明节点数量 |
百分位与平均值适用场景不同。平均值会被少量极快请求拉低，掩盖长尾用户的等待；百分位更接近用户体感，但必须说明取哪个百分位、样本量多少。样本量过小时，P99 只由个别请求决定，参考价值有限，此时应改用 P95 或延长采样时间。
缺失值和分母为零要提前约定。分母为零（如时间窗内没有成功请求）时，不能简单记为“0% 错误率”或“通过”，应判定为本次数据无效、需补测。样本不足（如成功请求少于预设下限）时，同样标记为无效而非通过。超时请求通常不计入响应时间样本，但必须计入错误率，否则会出现“响应时间很好看、实际大量请求失败”的失真结论。这些规则写在计划里，验收时才有共同依据。
计算与判定步骤：从原始数据到通过结论
从压测原始数据到验收结论，可以按以下步骤执行，每一步都留下可复核的记录：
- 采集：保存压测工具输出的请求明细、服务端监控数据和日志，记录压测起止时间、负载配置和数据集版本。
- 清洗：剔除预热阶段数据，标记超时、连接失败和业务异常请求，按口径表归类为成功、失败或无效。
- 逐指标计算：按公式计算每个指标的数值，保留计算脚本或表格，确保他人可用同一份原始数据复算出相同结果。
- 阈值比对：将计算结果与阈值逐项比较，记录“达标/未达标/数据无效”三种状态，数据无效不能记为达标。
- 综合判定：按事先约定的规则汇总结论。常见规则是“全部硬指标满足才算通过”，也可以对指标分级：硬指标必须满足，观察指标仅记录不参与判定。规则必须在压测前确定。
- 偏差复核与复测：未达标时先复核数据采集是否完整、环境是否受到干扰，排除测量问题后再判定为性能问题；需要复测的，写明复测范围、环境和时间。
判定表建议包含指标、阈值、实测值、状态、数据有效性和备注六列。多指标同时满足的规则要写清楚是“全部满足”还是“核心指标满足且观察指标不恶化”，避免出现部分达标时各方各取所需。
示例：一条订单提交链路的验收目标
以下为演示情景，数值仅用于说明写法，不代表通用达标线。
场景与负载：模拟 500 个并发用户执行“加购—提交订单—支付确认”链路，思考时间 3 秒，商品数据集 10 万条，压测持续 30 分钟，取第 5 至第 25 分钟的稳定段作为统计时间窗。
| 指标 | 阈值 | 口径 | 实测值 | 状态 |
|---|---|---|---|---|
| 订单提交接口 P95 响应时间 | ≤ 800 ms | 成功请求的端到端耗时，升序取第 95 百分位 | 720 ms | 达标 |
| 链路错误率 | ≤ 0.5% | 失败请求数 ÷ 总请求数，含超时与 5xx | 0.3% | 达标 |
| 订单创建吞吐量 | ≥ 120 TPS | 稳定段时间窗内成功订单数 ÷ 秒数 | 135 TPS | 达标 |
| 应用节点 CPU 峰值 | ≤ 75% | 4 个应用节点中最高采样值 | 82% | 未达标 |
按“全部硬指标满足才通过”的规则，本次判定为不通过，原因是 CPU 峰值超出阈值。记录方式应写明：未达标指标、实测值与阈值的差距、对应时间点、涉及节点、初步怀疑原因（如连接池配置或慢查询），以及复测计划。若规则将 CPU 列为观察指标，则结论为通过并附资源余量风险提示——这正是判定规则必须提前约定的原因。
解读与限制：阈值怎么定、结论能说明什么
阈值不能凭空设定，常见来源有三类：业务基线（如用户可接受的页面等待时间、运营峰值订单量）、历史数据（上一版本或上一季度的实测表现）、容量规划（按未来一段时间的业务增长预留余量）。无论采用哪类来源，都应在计划中注明依据和推导过程，便于后续版本对比时保持口径一致。
结论的适用边界需要明确写出：
- 环境差异：测试环境的机器规格、网络条件、数据量和依赖服务与生产环境不同，测试通过说明在该环境下满足阈值，不能直接等同于生产环境同等表现。
- 单指标不等于整体稳定：响应时间和错误率达标，不代表系统在流量突增、依赖降级或长时间运行下仍然稳定，稳定性需要结合持续压测和故障演练另行评估。
- 指标与因果的边界：压测结果反映特定负载模型下的表现，负载模型与实际用户行为存在偏差时，结论的适用范围随之收窄。指标变化也不能单独证明某次代码改动是唯一原因。
- 时效性：阈值和结论对应特定版本与特定时间，架构调整或业务量变化后需要重新校准。
把验收目标纳入测试计划与协作流程
验收目标只有写进测试计划并被评审确认，才具备约束力。计划文档中应设置独立的“性能验收目标”部分，包含场景范围表、指标口径表和判定规则，并与功能测试范围、环境说明放在同一份计划里，避免性能条款散落在会议纪要中。
责任角色要明确：测试负责人起草目标与口径，业务方确认场景和阈值，开发负责人确认环境与数据条件，最终由测试负责人签署判定结论。评审时重点核对阈值依据、分母定义和异常计入规则，这三处最容易在执行阶段产生分歧。
执行阶段的记录与追踪同样重要。压测结果、计算过程和判定表应作为测试计划的附件或关联记录保存，未达标项转为缺陷或改进任务跟踪，复测结果与原始结论一并归档，形成可追溯的版本质量记录。ONES 支持测试计划的规划和执行，并可多维度概览全部测试计划；测试计划可与迭代关联，测试报告支持自定义模板组装，便于把性能验收结论与版本质量信息放在同一处查看和归档。对于验收标准不清晰的场景，将目标条目、口径和判定结果随测试计划一起记录，可以让后续复测和版本对比有据可查。
常见问题
性能目标里的并发用户数怎么写才能被复现？
并发数要和思考时间、操作路径、数据集一起写，否则同样的并发数字会产生完全不同的压力。建议同时给出请求速率：用并发用户数乘以每用户单位时间请求数估算，再按业务峰值时段的比例校准。计划中记录压测工具的负载配置和脚本版本，复测时沿用同一套参数，结论才具备可比性。
压测时间窗内成功请求太少，指标算出来很好看，能判通过吗？
不能。计划中应预设样本量下限，成功请求数低于下限时标记为数据无效、需要补测，而不是按计算结果判达标。同理，时间窗内没有成功请求导致分母为零时，也不能记为 0% 错误率。把这类规则写在口径表里，可以避免验收阶段对同一份数据得出相反结论。
阈值定多少合适，有没有通用标准可以照搬？
没有可以直接照搬的通用达标线。阈值通常来自三类依据：业务基线（用户可接受的等待时间、运营峰值订单量）、历史数据（上一版本或上一季度的实测表现）、容量规划（为未来业务增长预留的余量）。选定依据后要在计划中写明推导过程，并在架构调整或业务量明显变化后重新校准。
部分指标达标、部分未达标时，验收结论怎么给？
取决于压测前约定的判定规则。常见做法是把指标分为硬指标和观察指标：硬指标全部满足才判通过，观察指标只记录不参与判定。也可以约定核心指标满足且观察指标不恶化即通过。规则必须在执行前确定并写入计划，否则部分达标时各方容易各取所需。未达标项应记录实测值与阈值的差距、涉及节点和初步原因，转为改进任务并安排复测。
性能验收结论如何随测试计划一起留存和追踪？
把场景范围表、指标口径表和判定表作为测试计划的组成部分或关联记录保存，压测原始数据、计算过程和复测结果一并归档。未达标项转为缺陷或改进任务跟踪，复测结论与原始结论对照记录。ONES 支持测试计划的规划和执行，并可多维度概览全部测试计划；测试计划可与迭代关联，测试报告支持自定义模板组装，便于把性能验收结论与版本质量信息放在同一处查看和归档。
