自动化测试稳定性可以用一组可复算的指标来评估：以用例执行结果为最小单位，统计固定时间窗内的失败次数、通过率、翻转次数、失败归因分布和平均修复时长。评估前先定口径，区分真实缺陷失败、环境或数据失败、脚本自身失败，再计算不稳定用例占比与失败重跑通过率，避免把偶发失败当成产品缺陷，也避免用单一通过率掩盖波动。
要点总览（TL;DR）
- 稳定性评估先定口径再取数：以用例执行结果为最小单位，固定用例集、分支、环境和时间窗，同一份说明下不同人应算出相同结果。
- 核心指标六个：执行通过率、不稳定用例占比、翻转率、失败重跑通过率、失败归因分布、平均修复时长，分别对应结果、波动、归因与修复。
- 失败先分三类再计算：真实缺陷、环境或数据、脚本自身，未归因项单列保留，避免把偶发失败计入缺陷密度。
- 翻转以同一版本或同一提交下同一用例结果不一致识别，重跑结果单独记录、不覆盖首次结果，否则波动无法追溯。
- 指标用于定位与改进：通过率高不代表覆盖充分，不稳定用例占比受用例集变化影响，阈值结合历史基线与业务风险设定。
评估目标：稳定性要回答哪几个问题
稳定性评估要回答三个问题：失败是否可复现、波动来自哪里、修复是否及时。这三个问题分别对应不同的判断用途，先明确用途，再决定取哪些数。
- 失败是否可复现：同一用例在同一版本或同一提交下重复执行，结果是否一致。用于判断流水线结果的可信度，决定红灯是否值得立即排查。
- 波动来自哪里：失败集中在产品缺陷、环境与测试数据、脚本自身中的哪一类。用于确定治理优先级，把有限的修复投入放到占比最高的来源上。
- 修复是否及时：从首次失败到恢复稳定通过用了多长时间。用于评估用例治理的推进节奏，识别长期挂起的不稳定用例。
把失败来源分成三类是评估成立的前提。若把环境抖动和脚本缺陷都计入产品缺陷，缺陷密度会被高估，开发侧会对测试信号失去信任；若把真实缺陷失败当作偶发波动忽略，发布判断就会失真。归因不必追求一次到位，但每条失败记录至少要有一个可追溯的初步分类，并允许人工复核修正。
评估结论的用途需要事先约定。用于发布判断时，关注的是当前版本关键用例集的稳定通过情况；用于用例治理时，关注的是不稳定用例的分布与修复进度；用于流水线可信度评估时，关注的是重跑通过率与翻转率。三种用途对时间窗和用例范围的要求不同，混在一起统计会得到无法解释的数字。
指标与范围：用哪些指标、统计哪些用例
建议采用六个核心指标，覆盖结果、波动、归因和修复四个维度。指标含义与统计范围如下表。
| 指标 | 含义 | 统计范围 |
|---|---|---|
| 执行通过率 | 统计期内通过的执行次数占有效执行次数的比例 | 指定用例集、分支、环境、时间窗 |
| 不稳定用例占比 | 统计期内出现过结果翻转的用例数占纳入统计用例数的比例 | 同上，按用例去重计数 |
| 翻转率 | 同一版本或同一提交下结果不一致的执行次数占该范围内执行次数的比例 | 按版本或提交分组统计 |
| 失败重跑通过率 | 首次失败后重跑通过的次数占重跑总次数的比例 | 仅统计发生重跑的失败执行 |
| 失败归因分布 | 各类失败来源（缺陷、环境数据、脚本）占失败总数的比例 | 按失败执行计数，允许未归因项单列 |
| 平均修复时长 | 不稳定用例从首次失败到连续通过所需时间的平均值 | 按用例统计，单位小时或天 |
统计范围要写清楚四件事：用例集（全量回归、冒烟集还是某模块子集）、分支（主干还是发布分支）、环境（哪套测试环境）、时间窗（自然周、迭代周期还是发布周期）。范围一旦确定，同一指标跨周期比较才有意义。
纳入与排除规则同样需要固定。跳过（skip）和阻塞（blocked）的执行不计入通过率分母，单独统计数量；环境整体不可用期间的执行记录整段排除，并在报告中注明排除区间；新引入例在首次稳定运行前可单列观察，不参与不稳定用例占比计算，避免新用例调试期的波动拉高整体指标。排除规则要少而明确，排除过多会让指标失去代表性。
数据口径：分子分母、时间窗与缺失值怎么定
口径决定指标能否被复算。每个指标都要写明分子、分母、单位和时间窗，取数人按同一份说明应得到相同结果。
| 指标 | 分子 | 分母 | 单位与时间窗 |
|---|---|---|---|
| 执行通过率 | 通过的执行次数 | 有效执行次数（通过+失败，不含跳过与阻塞） | 百分比，按周或按迭代 |
| 不稳定用例占比 | 出现翻转的用例数 | 纳入统计的用例数 | 百分比，按周或按迭代 |
| 翻转率 | 结果不一致的执行次数 | 同版本或同提交下的执行次数 | 百分比，按版本分组 |
| 失败重跑通过率 | 重跑后通过的次数 | 发生重跑的失败执行次数 | 百分比，按周或按迭代 |
| 平均修复时长 | 各用例修复时长之和 | 完成修复的用例数 | 小时，按迭代 |
多次执行与重跑的计数规则要单独约定。首次执行结果与重跑结果分别记录，重跑不覆盖首次结果，否则翻转无法识别。并行分片下同一用例在不同分片执行，按执行次数分别计入；判断翻转时以用例为对象，比较同一版本内的结果集合。同一用例在一个时间窗内执行多次，通过率按次数计，不稳定用例占比按用例去重计，两者分母不同，报告中要注明。
缺失值的处理原则是标注而非填补。执行记录缺失、日志未上传、归因未完成的失败，在归因分布中列为“未归因”，不默认归入某一类。环境中断导致的批量失败，若已标记环境不可用，整段排除；未标记的按实际结果计入，并在复盘中补充标记规则。
分母为零或样本量过小时，指标标注为“样本不足”，不计算百分比，也不做达标判断。例如某模块本周执行次数为零，通过率一栏写“无执行”，而不是写 0% 或 100%。样本量阈值可按团队历史数据设定，例如纳入统计的用例少于 10 个或执行次数少于 30 次时只报绝对数。
计算与评估步骤：从原始执行记录到结论
计算流程分五步，每步都有明确的输入和产物。
- 采集执行记录：从流水线与测试执行工具导出用例级记录，字段至少包括用例标识、版本或提交号、执行时间、结果、是否重跑、环境标识、日志与截图链接。
- 清洗与归因：剔除环境不可用区间，标记跳过与阻塞，对每条失败记录做初步归因。归因依据包括失败日志中的异常类型、截图、环境健康标记，无法自动判断的进入人工复核队列。
- 按用例聚合：以用例为单位汇总时间窗内的执行次数、通过次数、失败次数、结果集合，识别是否出现翻转。
- 计算指标：按上一节口径逐项计算，同时输出分子分母原始值，便于复核。
- 判定：对照历史基线与趋势做判断，输出结论与待治理清单。
翻转的识别方法是：取同一版本或同一提交下同一用例的全部执行结果，若集合中同时存在通过与失败，即记为一次翻转。重跑通过但首次失败的情况属于翻转的典型来源，要单独统计，因为它直接影响开发者对红灯的信任程度。
结果呈现建议分三层：按用例看，列出翻转次数最多和修复时长最长的用例，形成治理清单；按模块看，比较各模块的不稳定用例占比，定位集中区域；按流水线看，比较各流水线的重跑通过率，判断哪条流水线的信号更可靠。三层视图使用同一份口径说明，避免各说各话。
当失败记录、归因结论和修复动作分散在不同工具中时，统计工作会消耗大量人工核对时间。ONES DevOps 解决方案提供工具链集成能力，将项目管理、测试管理与流水线集成衔接起来，使执行记录、失败工单与修复状态在同一流程中流转；其效能管理模块可用于承载指标查看，具体指标字段与统计范围以实际部署配置为准。这样做的价值在于归因结论能直接落到工作项上，修复进度可被跟踪，而不是停留在表格里。
例子：一个迭代周期的稳定性计算
以下为演示情景，数字用于说明公式，实际评估需替换为团队真实执行记录。
某迭代周期内，纳入统计的用例 200 个，在主干分支、同一套测试环境执行，有效执行 1000 次，其中通过 920 次、失败 80 次，跳过 30 次、阻塞 10 次不计入分母。失败中有 20 次发生重跑，重跑通过 12 次。出现结果翻转的用例 16 个。80 次失败按归因分为：真实缺陷 32 次、环境或数据 30 次、脚本自身 14 次、未归因 4 次。完成修复的不稳定用例 10 个，修复时长合计 240 小时。
- 执行通过率 = 920 ÷ 1000 = 92.0%
- 不稳定用例占比 = 16 ÷ 200 = 8.0%
- 失败重跑通过率 = 12 ÷ 20 = 60.0%
- 失败归因分布：缺陷 40.0%、环境数据 37.5%、脚本 17.5%、未归因 5.0%
- 平均修复时长 = 240 ÷ 10 = 24 小时
翻转率需要按版本分组计算。假设该迭代涉及两个版本，版本 A 执行 600 次、其中结果不一致 24 次，翻转率为 4.0%；版本 B 执行 400 次、不一致 16 次，翻转率为 4.0%。两个版本翻转率相同，但版本 A 的失败绝对数更多，治理时应优先看版本 A 的用例清单。
边界情况：假设某模块本周执行次数为零，该模块通过率标注“无执行”，不参与整体通过率的分母；某新模块仅纳入 8 个用例、执行 20 次，低于样本阈值，只报失败次数与翻转用例数，不计算百分比，也不与整体指标比较。未归因的 4 次失败保留在分布中，待复核后调整，不在计算时强行归类。
解读与限制：指标能说明什么、不能说明什么
通过率高说明执行结果一致性好，不说明覆盖充分。一个只跑冒烟用例的流水线可以长期保持高通过率，却漏掉大量业务路径。解读通过率时必须同时看用例集范围与用例质量，必要时补充覆盖率或需求关联情况作为参照。
不稳定用例占比受用例集变化影响明显。新增一批用例或调整统计范围后，该指标会跳变，跨周期比较前要固定用例集与口径，或在报告中说明变更点。翻转率按版本分组统计，版本之间用例构成不同，直接横向比较意义有限，更适合看同一版本内的趋势。
这些指标用于定位问题与推动改进，不适合直接作为个人绩效结论。一个用例翻转可能源于环境配置、测试数据或产品代码，归因到人需要完整证据链，指标本身只提供线索。团队可以把治理清单作为协作输入，由用例负责人确认原因并推进修复。
阈值应结合历史基线与业务风险设定。核心交易链路的用例集可以要求更低的翻转率，探索性较强的模块可以接受更高波动。没有历史基线时，先连续统计两到三个周期建立基线，再讨论改进目标，避免套用外部通用达标线。指标反映的是执行结果的分布特征，产品是否稳定还取决于缺陷逃逸情况与线上表现，两者需要结合判断。
常见问题
用例集在统计期内发生调整，跨周期指标还能直接比较吗？
直接比较会失真。新增或下线用例会改变不稳定用例占比的分母，也会改变通过率的执行次数构成。可行做法是固定统计口径后重算历史周期，或在报告中标注变更点，把调整前后的数据分段呈现。若必须连续观察趋势，可以保留一个稳定的核心用例集作为基准口径，另设全量口径用于治理，两套数字分开报，不混算。
重跑通过率很高，说明流水线稳定吗？
重跑通过率高说明首次失败中有相当比例在重跑后恢复，这通常指向环境抖动、测试数据竞争或脚本时序问题，而不是产品缺陷。它反映的是信号可信度偏低：红灯需要重跑才能确认，开发者会逐渐降低对失败结果的敏感度。建议把重跑通过率与翻转率一起看，并抽查重跑通过的失败记录做归因，确认波动来源后再决定是修环境、修脚本还是调整执行策略。
失败归因由谁做、做到什么程度够用？
归因的第一道可以由执行记录中的异常类型、环境健康标记和截图自动给出初步分类，无法判断的进入人工复核队列，由用例负责人或测试负责人确认。够用的标准是每条失败记录都有可追溯的初步分类，并且允许后续修正。不必追求一次归因到位，但要保证未归因项在分布中单列，不默认塞进某一类，否则归因分布会失去治理参考价值。
样本量小到什么程度就不该报百分比？
没有统一门槛，取决于团队历史数据的波动幅度。常见做法是纳入统计的用例少于 10 个或执行次数少于 30 次时只报绝对数，标注“样本不足”，不计算百分比也不做达标判断。新模块在首次稳定运行前可以单列观察，不参与整体不稳定用例占比，避免调试期波动拉高整体指标。阈值一旦确定就写进口径说明，各周期一致执行。
执行记录、归因结论和修复状态分散在多个工具里，怎么减少人工核对？
关键是让归因结论落到可跟踪的工作项上，而不是停留在表格。ONES DevOps 解决方案提供工具链集成能力，将项目管理、测试管理与流水线集成衔接起来，执行记录、失败工单与修复状态可以在同一流程中流转；效能管理模块可用于承载指标查看，具体指标字段与统计范围以实际部署配置为准。这样平均修复时长可以直接从工作项状态变化中取数，减少跨工具手工对齐。
