评估自动化测试稳定性，关键是把“结果是否可复现”变成可计算的指标：在固定时间窗内，以执行记录为分母，统计重跑翻转、环境与数据导致的失败、超时和偶发失败占比，再通过失败归因和重跑验证区分真实缺陷与不稳定用例。单看通过率容易掩盖偶发问题，需要结合分母、缺失值和归因证据一起解读。评估所需的数据登记与缺陷关联，可以在ONES测试管理流程中承载。
要点总览（TL;DR）
- 稳定性评估的核心是把“结果是否可复现”变成可计算指标：在固定时间窗内以执行记录为分母，统计翻转率、无效失败率、首次通过率、超时率和平均修复时长。
- 口径决定可比性：翻转率的分母用“失败后执行了重跑的次数”，首次通过率的分母用有效执行次数，跳过与缺失执行单列，不默认视为通过。
- 区分不稳定用例与真实缺陷靠重跑验证：同一提交同一环境下重跑结果翻转且归因指向环境或数据，倾向判为不稳定；稳定复现且归因指向产品逻辑，倾向判为真实缺陷。
- 算例演示：2000次执行、240次失败、160次重跑、48次翻转，翻转率30%、无效失败率50%、首次通过率约92.6%，单看通过率会掩盖可复现性问题。
- 指标反映可复现性而非产品质量，样本过少、环境差异大、口径变更时结果不可比；应看连续周期趋势，并保留完整执行与重跑记录防止美化。
评估目标：先明确要回答的稳定性问题
稳定性评估的第一步是写清评估对象和判断用途。对象不同，取数范围和结论含义都会变化：评估整个测试套件，回答的是“这套自动化资产整体是否可依赖”；评估某个用例集，回答的是“这组场景在多次执行中是否可复现”；评估流水线中的某个阶段，回答的是“该阶段的结果能否作为准入依据”。三者混在一起统计，指标会失去解释力。
评估要回答的问题通常有三类。第一，结果可复现：同一代码提交、同一环境下重复执行，结果是否一致。第二，失败可归因：失败中有多少来自产品缺陷，多少来自环境、数据或脚本自身。第三，维护成本可控：不稳定用例占用了多少排查和修复时间，是否在收敛。
评估周期和使用场景需要同步确定。发布前准入关注最近一个版本的执行表现，日常巡检关注按天或按周的波动，试点验收关注一段观察期内是否达到可推广的稳定水平。建议在评估开始前形成一份简短的目标说明，至少包含：评估对象及其边界、统计周期、判断用途、结论的使用者。目标说明不需要复杂，但要能防止后续把稳定性评估做成笼统的通过率汇报。
指标与范围：稳定性用哪几个指标衡量
稳定性指标应围绕“可复现性”和“失败性质”设计，而不是只统计通过数量。下表列出一组常用指标及各自回答的问题，团队可按评估目标取舍，但建议至少保留翻转率、无效失败率和首次通过率三项。
| 指标 | 回答的问题 | 稳定性侧面 |
|---|---|---|
| 翻转率 | 失败后重跑，结果发生变化的比例有多高 | 结果可复现性，最直接的不稳定信号 |
| 无效失败率 | 失败中有多少并非产品缺陷导致 | 失败信号的可信度 |
| 首次通过率 | 不依赖重跑，首次执行即通过的比例 | 结果的一次性可信度 |
| 超时率 | 因执行超时导致的失败占比 | 执行环境与脚本健壮性 |
| 平均修复时长 | 不稳定用例从被标记到恢复稳定用了多久 | 维护成本与收敛速度 |
需要明确哪些现象不计入稳定性问题。产品逻辑导致的真实缺陷，反映的是质量而非稳定性；需求变更导致用例失效，属于用例维护范畴；主动跳过的用例也不应算作失败。把这些现象与不稳定失败分开统计，指标才能指向正确的改进动作。翻转率关注的是“同一条件下结果是否变化”，真实缺陷在重跑中通常稳定复现，二者在数据上可以区分。
数据口径：分母、时间窗与缺失值处理
不同团队算出的稳定性数字不可比，多数时候问题出在口径而非数据本身。口径说明应固定四件事：分子、分母、时间窗和缺失值规则。
分母的选择取决于指标。翻转率的分母建议用“发生失败并执行了重跑的次数”，而不是全部执行次数，否则重跑少的团队会显得更稳定。无效失败率的分母是总失败次数。首次通过率的分母是有效执行次数，跳过和缺失执行单列，不并入分母，也不默认视为通过。若按用例维度统计，分母为用例数；若按流水线维度统计，分母为流水线运行次数。同一份报告内应保持维度一致。
时间窗和统计粒度要写进报告。按天统计适合观察波动，按版本统计适合发布准入，按发布批次统计适合跨版本比较。代码变更、环境变更、数据变更需要在执行记录上打标记，否则无法判断某次失败翻转是变更引起还是用例本身不稳定。
| 指标 | 分子 | 分母 | 时间窗 | 单位 | 缺失值规则 |
|---|---|---|---|---|---|
| 翻转率 | 重跑后结果发生变化的执行次数 | 失败后执行了重跑的次数 | 按版本或按周 | 百分比 | 未重跑的失败不计入分母，单独列出 |
| 无效失败率 | 归因为环境、数据、脚本的失败次数 | 总失败次数 | 同上 | 百分比 | 未归因失败单列，不默认计入分子 |
| 首次通过率 | 首次执行即通过的次数 | 有效执行次数 | 同上 | 百分比 | 跳过、缺失执行不计入分母 |
| 超时率 | 超时失败次数 | 总执行次数 | 同上 | 百分比 | 取消执行不计入 |
| 平均修复时长 | 各不稳定用例修复时长之和 | 被标记的不稳定用例数 | 按观察期 | 小时或天 | 未修复用例标注为未关闭，不参与均值 |
手动重跑记录必须保留，包括重跑发起人、重跑时间和重跑结果。只保留最终结果会丢失翻转信息，翻转率就无法计算。缺失执行要在报告中显式标注数量，样本过少时不出结论。
计算与评估步骤：从执行记录到稳定性结论
有了口径，计算本身并不复杂，难点在归因和验证。建议按以下步骤推进，每一步都留下可复查的记录。
- 采集执行记录。导出评估时间窗内的全部执行记录，字段至少包括用例标识、提交或版本标识、执行时间、执行结果、是否重跑、重跑结果、失败原因、环境标识。
- 标记变更与重跑。为每条记录补充代码变更、环境变更、数据变更标记，并标注重跑关系。同一提交下的多次执行归为一组，便于判断结果一致性。
- 按口径计算指标。翻转率 = 重跑结果发生变化的执行次数 ÷ 失败后重跑的执行次数 × 100%；无效失败率 = 非产品缺陷失败次数 ÷ 总失败次数 × 100%；首次通过率 = 首次执行通过次数 ÷ 有效执行次数 × 100%；超时率 = 超时失败次数 ÷ 总执行次数 × 100%。平均修复时长按小时或天计，需说明计时起点是首次标记不稳定，截止点是恢复稳定执行。
- 失败归因抽样。对失败样本逐条或抽样归因，分类为环境、数据、脚本、产品缺陷、未知。归因依据应记录在案，例如日志片段、环境状态、复现步骤，避免只按失败信息关键词机械分类。
- 重跑验证翻转。对疑似不稳定的失败，在同一提交、同一环境下重跑。重跑结果翻转且归因指向环境或数据，倾向判为不稳定用例；重跑稳定复现且归因指向产品逻辑，倾向判为真实缺陷。两种情形都要保留证据。
- 设定观察期与复评节奏。稳定性是趋势问题，建议以版本周期或固定周为观察期，每个周期复评一次，对比前后指标变化，确认改进措施是否生效。
归因环节决定指标的可信度。若归因粗糙，无效失败率会失真，翻转率也无法解释。建议对归因为“未知”的失败单独统计占比，占比过高时先补足日志和环境信息，再下结论。
算例：一个版本周期的稳定性评估
以下为演示情景，数字用于说明计算过程，不代表任何团队的实际水平。某版本周期内，自动化测试共执行2000次，其中失败240次。失败后有160次执行了重跑，重跑结果发生变化的有48次。对240次失败做归因，环境原因60次，数据原因36次，脚本原因24次，产品缺陷96次，未知24次。另有跳过执行80次，缺失执行20次。
翻转率 = 48 ÷ 160 × 100% = 30%。无效失败率 = (60 + 36 + 24) ÷ 240 × 100% = 50%。首次通过率的分母为有效执行次数，即2000 − 80 − 20 = 1900次，首次通过次数为2000 − 240 = 1760次，首次通过率 = 1760 ÷ 1900 × 100% ≈ 92.6%。未知失败占比 = 24 ÷ 240 × 100% = 10%。
解读时不能只看92.6%的首次通过率。翻转率达到30%，说明近三分之一的失败重跑后结果不同，结果可复现性存在明显问题；无效失败率50%，意味着一半失败并非产品缺陷，排查成本被大量消耗在环境、数据和脚本上。结合未知失败占比10%，可以判断当前归因信息还不够完整，下一步应优先补齐环境与数据失败的日志记录，再针对高频不稳定用例安排修复。
分母为零或样本过少时，处理规则要提前约定。若某版本没有发生失败重跑，翻转率分母为零，此时不出百分比结论，标注“样本不足，未计算”。若失败次数少于20次，建议只报告绝对数量和失败清单，不据此判断稳定性趋势。跳过和缺失执行数量较大时，首次通过率的可比性下降，应在报告中注明。
解读与限制：指标能说明什么、不能说明什么
稳定性指标反映的是执行结果的可复现程度，不能直接代表产品质量。一个版本翻转率很低，可能说明自动化结果可信，也可能说明用例覆盖的场景过于简单；反过来，翻转率高也不必然意味着产品问题多，可能只是环境不稳定。指标需要与真实缺陷率、用例覆盖范围结合看。
以下情形下结果不可比，报告中应主动说明：样本量过小，例如单次流水线运行或失败次数很少；环境差异大，例如不同执行机、不同依赖版本混在一起统计；统计口径变更，例如中途调整了分母或归因分类。跨团队比较时，还要确认时间窗和变更标记方式一致。
指标存在被美化的空间。选择性跳过不稳定用例、失败后反复重跑直到通过、只统计成功执行，都会让数字变好而实际问题依旧。防范方式是保留完整执行记录和重跑记录，把跳过率、重跑次数一并报告，并定期抽查归因证据。稳定性评估应看趋势而非单次快照，连续几个周期的翻转率和无效失败率是否下降，比某一次的高通过率更有参考价值。指标用于定位改进方向，不宜直接作为个人绩效结论。
把评估落到协同管理：记录、归因与复评
稳定性评估依赖三类数据能够被稳定登记和追溯：执行记录、失败归因、重跑标记。这些数据分散在个人表格或聊天记录里，复评时就难以还原当时的判断依据。更稳妥的做法是在测试管理流程中统一承载：用例执行时记录执行人和结果，失败时填写归因分类，重跑时保留与原执行的关联，评估时按版本或时间窗汇总。
失败用例与缺陷、任务的关联同样重要。归因为产品缺陷的失败，应能快速转为缺陷任务并流转到研发；归因为环境或数据的失败，应关联到对应的维护任务，明确责任人和处理状态。这样，无效失败率不只是一个数字，还能对应到具体的改进动作。
ONES测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；用例可分配执行人，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；同时提供测试情况概览和质量统计报表，可查看测试计划进度与通过率，并自动生成测试报告。对于本文的评估方法，这些能力可以承载执行记录登记、失败转缺陷和周期性报告输出；翻转率、无效失败率等专项指标的计算口径仍需团队按前述规则自行定义，并在报告中注明数据来源和统计范围。
复评节奏建议与版本节奏对齐：每个版本周期结束后，由测试负责人汇总指标、归因分布和未关闭的不稳定用例，组织一次简短评审，确认下个周期的改进重点。评审结论和指标口径变更一并记录，保证不同周期的数据可以对照。评估结论的使用范围也应写清，例如仅用于发布准入判断，或用于自动化资产维护排期，避免指标被挪作其他用途后产生误读。
常见问题
翻转率的分母为什么不用全部执行次数？
用全部执行次数做分母，会让重跑少的团队显得更稳定，因为大量失败根本没有进入重跑环节。翻转率要回答的是“失败后重跑，结果变化的比例有多高”，分母应限定为发生失败并执行了重跑的次数。未重跑的失败单独列出数量，提示这部分结果尚未验证，而不是默认视为稳定。
同一提交重跑结果翻转，就一定是用例不稳定吗？
不一定，需要结合归因证据判断。重跑翻转且失败原因指向环境状态、测试数据或执行顺序，倾向判为不稳定用例；若翻转同时伴随环境变更标记，则更可能是环境问题而非用例本身。建议对翻转样本保留日志片段、环境标识和重跑时间，归因为“未知”的翻转单独统计，占比过高时先补足信息再下结论。
失败次数很少的版本，稳定性指标还能用吗？
样本过少时百分比波动极大，不适合据此判断趋势。可以约定一个最低样本门槛，例如失败次数少于20次时只报告绝对数量、失败清单和归因分布，不计算翻转率与无效失败率，并标注“样本不足，未计算”。分母为零时同样不出百分比结论。跨版本比较时，还要确认两个版本的样本量和口径一致。
评估数据分散在个人表格里，复评时怎么保证可追溯？
关键是把执行记录、失败归因和重跑标记统一登记在同一处，并保留重跑与原执行的关联。ONES测试管理支持用例分配执行人、未通过用例快速创建缺陷任务并在测试与研发团队间流转，也提供测试情况概览和质量统计报表，可承载执行记录登记与失败转缺陷；翻转率、无效失败率等专项指标的计算口径仍需团队自行定义，并在报告中注明数据来源和统计范围。
稳定性指标可以直接用于个人绩效考核吗？
不建议直接使用。指标存在被美化的空间，例如选择性跳过不稳定用例、失败后反复重跑直到通过，都会让数字变好而实际问题依旧。更合适的用法是定位改进方向：看连续几个周期翻转率和无效失败率是否下降，把跳过率、重跑次数一并报告，并定期抽查归因证据。若确需与考核关联，应同时约束跳过率和重跑次数，避免单一指标驱动错误行为。
