性能测试的通过准则和评估口径怎么确定

性能测试的通过准则需要从业务目标反推：先明确被测场景、负载模型和时间窗，再为响应时间、吞吐量、错误率、资源占用分别设定指标、统计口径和阈值，最后写明判定规则。评估口径的关键是让分子分母、统计位置和取数时间可复算，并在计划阶段与业务、开发、运维共同确认，避免测试结束后再改标准。

要点总览（TL;DR）

• 通过准则从业务目标反推：先定场景、负载模型和时间窗，再为响应时间、吞吐量、错误率、资源占用分别设指标、口径和阈值。
• 口径可复算的关键是写清分子分母、统计位置（客户端/网关/服务端）、分位数选择和缺失值处理，跨版本对比时保持取数位置一致。
• 判定规则在计划阶段确定：全部满足制适合上线放行，加权制适合多链路比较，分级制适合核心与非核心链路差异对待。
• 波动容忍与复测次数要预先约定，分母为零或样本不足时标记为不可判定并补充测试，不按通过处理。
• 测试结论受环境差异约束，指标达标说明约定场景下表现符合预期，放行决策还需结合缺陷、回滚方案和业务风险。

评估目标：这次性能测试要回答什么

通过准则的第一项工作，是把测试要回答的问题写清楚。同一个系统，上线放行、容量评估和版本回归三种用途，对指标的要求并不相同：上线放行关注关键链路在预期峰值下是否稳定；容量评估关注系统在多大负载下开始劣化、余量有多少；版本回归关注新版本相对基线的指标是否出现明显回退。用途不同，场景选择、负载设定和阈值宽严都会随之变化。

评估目标说明应包含三部分内容。第一是场景清单，列出被测系统和关键业务链路，例如登录、订单查询、下单支付，并说明每条链路在本次测试中承担什么验证任务。第二是用途与判定方式，写明本次结果用于上线放行、容量评估还是版本回归，以及结论由谁使用。第三是目标与非目标，例如本次覆盖正常业务负载下的性能表现，不覆盖攻击模拟、源码分析和全链路故障演练，避免读者把结论外推到未测试的范围。

参与确认标准的角色通常包括业务方、开发、测试和运维。业务方确认场景优先级和业务量假设，开发确认链路边界和技术约束，测试负责口径与数据采集，运维确认环境与监控条件。标准在计划阶段共同签字或评审通过，后续复测沿用同一口径，结果才具备可比性。

指标与范围：选哪些指标、覆盖多大负载

性能测试的基础指标一般包括四类：响应时间、吞吐量、错误率和资源占用。四类指标回答的问题不同，响应时间反映单次请求的快慢，吞吐量反映单位时间内系统能处理多少业务，错误率反映请求失败的比例，资源占用反映服务器、数据库、中间件等基础资源的消耗水平。指标并非越多越好，应围绕评估目标选取，每条关键链路配置一组能支撑判定的指标即可。

业务指标与系统指标需要建立对应关系。业务侧关心的是“一次订单查询多久返回”“高峰期每分钟能完成多少笔下单”，系统侧关心的是接口耗时、每秒请求数、CPU 使用率。计划中应写明业务指标由哪些系统指标支撑，例如订单查询的响应时间对应查询接口的服务端耗时，下单吞吐量对应下单接口的成功请求数。对应关系清楚，测试结果才能翻译成业务语言。

负载模型决定测试覆盖的范围。需要写明并发用户数或请求速率、各业务请求的比例、加压方式（阶梯加压、恒定负载或峰值冲击）以及测试时长。例如按业务高峰的请求比例构造混合场景，以每 5 分钟增加一档并发的阶梯方式加压，每档稳定运行 10 分钟，观察指标随负载变化的趋势。负载模型应来自业务量假设，并在计划中注明假设来源，便于后续容量变化时更新。

时间窗同样属于范围的一部分。需要明确统计的是加压稳定期、峰值时段还是整个测试过程，预热阶段的数据是否计入。时间窗一旦确定，所有指标都按同一窗口取数，避免响应时间取全程、吞吐量取峰值这类口径混用。

数据口径：分子分母、统计位置与缺失值

口径可复算，意味着任何人拿到原始数据，按写明的公式和取数规则都能算出相同结果。下表给出四类基础指标的口径要素，可作为计划中的口径表模板。

指标	计算口径	统计位置	关键约定
响应时间	单次请求从发出到收到完整响应的时间，单位毫秒	客户端、网关或服务端，需明确其一	报告 P50、P95、P99 分位数，说明是否包含网络耗时
吞吐量	统计窗口内成功完成的请求数 ÷ 窗口时长，单位请求/秒	与被统计接口一致	分母为有效统计时长，分子只计成功请求
错误率	失败请求数 ÷ 总请求数 × 100%	与吞吐量同一采集点	区分超时、连接失败、业务错误码等类别，分别统计
资源占用	采样周期内 CPU、内存、磁盘 IO、网络等使用率的均值与峰值	服务器或容器监控	写明采样间隔（如 10 秒）与聚合方式（均值、P95、峰值）

响应时间的统计位置直接影响数值。客户端统计包含网络传输和浏览器渲染，网关统计包含后端转发，服务端统计只反映应用内部处理。三者不可混用，报告中应注明取数位置，跨版本对比时保持位置一致。分位数的选择也要写清：P95 表示 95% 的请求快于该值，适合描述大多数用户的体验；P99 对尾部延迟更敏感，适合对稳定性要求高的链路。只报平均值容易掩盖长尾问题。

错误率的分子分母需要明确边界。总请求数是否包含重试请求、超时请求如何归类、业务错误码是否计入失败，都应在计划中约定。建议将错误分为连接层失败、超时、服务端错误和业务校验失败四类，分别给出数量和占比，便于定位问题。缺失值和样本不足的处理规则同样要前置：采集失败的时间段标记为无效窗口，不计入统计；某指标有效样本少于约定数量时，结论标记为“不可判定”，补充测试后再判定，不直接按通过处理。

计算与判定步骤：从原始数据到通过结论

从原始数据到通过结论，可以按以下步骤执行，每一步都留下可核查的记录。

1. 数据采集：按计划的时间窗和采样间隔采集客户端、服务端和监控数据，记录采集起止时间与工具版本。
2. 数据清洗：剔除预热阶段数据，标记采集异常的时间段，按约定规则处理重试和超时请求，保留清洗前后的样本数量。
3. 指标计算：先按接口计算单接口指标，再按业务链路聚合，最后汇总到场景层。聚合层级在计划中固定，避免不同报告口径不一。
4. 结果比对：将计算结果与阈值逐项比对，记录每项指标的实测值、阈值和判定结果。
5. 形成结论：按判定规则汇总，输出通过、不通过或不可判定，并附上未达标项和待确认问题。

判定规则有三种常见形式。全部满足制要求所有指标同时达标才算通过，适合上线放行这类风险敏感的用途；加权制对指标赋权后计算综合得分，适合多链路横向比较；分级制将结果分为通过、有条件通过和不通过，例如核心链路全部达标、非核心链路个别指标轻微超标时判为有条件通过，由业务方确认是否接受。选择哪种形式取决于评估用途，并在计划阶段确定。

波动容忍与复测次数需要预先约定。性能指标受环境、数据量和调度影响存在自然波动，可以约定实测值在阈值上下一定比例内视为临界，临界项复测一次，以两次结果中较差的一次作为判定依据；复测仍临界时提交评审。分母为零或样本不足时，按前述规则标记为不可判定，并说明补充测试的场景与时间，不将空数据解释为达标。

在测试管理流程中，性能测试计划、准则确认和结果评审可以作为工作项与文档流转。ONES 测试管理支持测试计划与迭代关联，形成测试流程闭环，并支持多维度概览测试计划进度；测试报告支持自定义组装模板，适配不同业务场景。将性能准则作为计划附件、把复测记录和评审结论留在同一工作项下，后续版本回归时可以直接对照同一口径复算。

例子：一次订单查询场景的准则与计算

以下为演示情景，用于说明口径如何落地，数值为示例设定，不代表任何通用达标线。

场景设定：订单查询接口，业务高峰假设为 200 并发用户，混合场景中查询请求占 70%、下单请求占 30%，采用恒定负载运行 30 分钟，前 5 分钟为预热不计入统计。统计位置为服务端应用日志，时间窗为第 5 至 30 分钟。

阈值与口径示例：查询接口 P95 响应时间不超过 300 毫秒，P99 不超过 800 毫秒；场景吞吐量不低于每秒 150 次成功请求；错误率不超过 0.5%，其中超时单独统计且不超过 0.2%；应用服务器 CPU 均值不超过 70%，峰值不超过 85%，采样间隔 10 秒。

计算过程：统计窗口 25 分钟共 1500 秒，采集到查询请求 240000 次，其中成功 238800 次，超时 600 次，服务端错误 400 次，业务校验失败 200 次。吞吐量为 238800 ÷ 1500 = 159.2 次/秒，达到阈值。错误率为 (600 + 400 + 200) ÷ 240000 = 0.5%，处于阈值边界；其中超时占比 600 ÷ 240000 = 0.25%，超过 0.2% 的约定。响应时间按服务端日志计算，P95 为 280 毫秒，P99 为 920 毫秒，P99 超标。CPU 均值为 68%，峰值为 83%，均在阈值内。

结果解读：吞吐量和 CPU 达标，P99 响应时间和超时占比未达标，错误率处于临界。按全部满足制判定为不通过，未达标项集中在长尾延迟和超时。遗留问题包括：超时请求是否集中在特定数据量区间、P99 超标是否与数据库慢查询相关，需要补充定位测试后再复测。复测沿用同一时间窗和统计位置，以两次结果中较差的一次作为最终判定依据。

解读与限制：结论能说明什么、不能说明什么

性能测试结论的适用范围受测试环境约束。测试环境的机器规格、网络条件、数据量和依赖服务与生产环境存在差异，测试通过说明在约定负载模型和环境下指标达标，不能直接等同于生产环境在真实流量下同样稳定。报告中应写明环境差异，必要时在生产环境进行小流量验证。

指标达标与业务稳定之间是相关关系，不能当作因果保证。响应时间和错误率达标，说明在测试覆盖的场景和负载下系统表现符合预期，但未覆盖的链路、突发流量、依赖服务故障和数据结构变化仍可能引发问题。单指标也不能代表整体绩效，吞吐量高但长尾延迟严重，用户体验依然可能受损，判定时应结合多类指标综合解读。

准则需要随版本和容量变化更新。业务量增长、架构调整或依赖升级后，原有的负载模型和阈值可能不再适用，应在版本规划时同步复核准则，保留历史口径以便对比。测试结果用于支撑决策，最终是否放行还需结合缺陷情况、回滚方案和业务风险共同判断。

常见问题

性能测试的阈值一定要在测试开始前定死吗？中途发现设得不合理怎么办？

阈值应在计划阶段与业务、开发、运维共同确认，并随测试计划一起评审通过，这样后续复测才有可比基准。测试执行中如果发现阈值明显脱离实际，例如业务量假设本身有误，应记录变更原因、变更前后的数值和确认人，作为计划变更处理，而不是在结果出来后直接调整。变更后的阈值只对后续测试生效，已完成的测试按原口径报告，并在结论中注明差异。

响应时间报平均值不够用，P95 和 P99 应该怎么选？

两者回答的问题不同。P95 表示 95% 的请求快于该值，适合描述大多数用户的常规体验；P99 对尾部延迟更敏感，适合对稳定性要求高的链路，例如支付、下单。实践中可以同时报告 P50、P95、P99，并在准则中明确哪一项作为判定依据。只报平均值容易掩盖长尾问题，一次慢请求集中的时段在均值上可能看不出来，却直接影响用户投诉。

测试环境和生产环境差异较大，测试通过能作为上线依据吗？

测试通过说明在约定的负载模型和测试环境下指标达标，可以作为上线决策的重要输入，但不能直接等同于生产环境在真实流量下同样稳定。报告中应写明机器规格、网络条件、数据量和依赖服务的差异，必要时安排生产环境小流量验证。最终放行还需结合缺陷情况、回滚方案和业务风险评估共同判断。

多个指标有的达标有的不达标，判定规则怎么设更合理？

取决于测试用途。上线放行这类风险敏感的用途适合全部满足制，任何一项未达标即判不通过；多链路横向比较可以用加权制，但权重需在计划阶段确定并说明依据；核心链路与非核心链路要求不同时，可用分级制，例如核心链路全部达标、非核心链路个别指标轻微超标判为有条件通过，由业务方书面确认是否接受。规则一旦确定，同一版本周期内保持一致。

性能测试的计划、准则和复测记录放在哪里便于后续对照？

常见做法是把性能测试计划、指标口径表和判定规则作为测试计划的附件，复测记录和评审结论留在同一工作项下，后续版本回归时直接对照同一口径复算。ONES 测试管理支持测试计划与迭代关联，形成测试流程闭环，并支持多维度概览测试计划进度；测试报告支持自定义组装模板，适配不同业务场景。具体配置方式需结合团队实际流程确认。