自动化测试稳定性可以用一组可复算的指标来度量：以固定时间窗内的执行批次为分母，统计执行通过率波动、失败重跑后通过比例、非代码变更导致的失败占比、环境与数据类失败占比、执行时长波动和用例级连续失败次数。评估时先固定统计口径，再按“采集—分类—计算—对比趋势—定位改进”的步骤执行，最后结合失败原因分布解释结果。本文给出指标定义、失败原因分类规则、计算步骤与一个两周窗口的算例，并说明这些指标的解释边界；度量结果如何落到日常协同与改进跟踪，也会在最后一节交代，其中会自然提及ONES在测试管理与效能管理方向上的承载方式。
要点总览（TL;DR）
- 稳定性度量先固定口径：明确纳入的流水线、用例集、环境、分支，统一时间窗与单位，再计算指标，保证不同批次可复算、可比较。
- 核心指标共六个：执行通过率、重跑通过率、非代码变更失败占比、环境与数据类失败占比、执行时长波动、用例连续失败次数，每个指标都写明分子、分母与时间窗。
- 失败原因按产品缺陷、脚本/用例问题、环境问题、测试数据问题、依赖服务问题、超时与资源问题六类标注，保留日志、截图、重跑结果和变更记录作为证据，未分类失败单列。
- 评估按“确定时间窗与批次—采集执行记录—标注失败原因—按公式计算—对比基线与趋势—形成结论”六步执行，看趋势和失败结构变化，不用单点通过率下结论。
- 稳定性指标用于定位改进方向，需结合缺陷发现与逃逸情况解读；样本少、环境变更时标注可比性限制，不宜直接作为个人绩效考核依据。
评估目标：稳定性要回答什么问题
稳定性评估的对象是自动化测试执行结果的可靠程度，即同一批用例在相近条件下重复执行时，结果是否一致、失败是否可解释。它不衡量脚本数量多少，也不衡量覆盖率高低。明确这一点，才能避免用“用例越写越多”代替“结果越来越可信”。
一次有效的稳定性评估要回答三个问题：
- 结果是否可信：当前通过率能否作为发布判断的依据，还是被环境抖动、数据问题稀释了。
- 波动来自哪里：失败集中在哪些用例、哪些环境、哪些失败类型，是产品缺陷还是执行条件问题。
- 改进是否有效：治理动作上线后，失败结构是否变化，波动是否收窄。
这三个问题对应不同的使用者与决策场景。测试负责人关心结果可信度，用于判断能否放行；测试开发或平台维护者关心波动来源，用于排优先级；研发管理者关心改进趋势，用于评估治理投入是否值得继续。覆盖率回答“测了多少”，用例数量回答“规模多大”，稳定性回答“测得准不准、稳不稳”，三者不能互相替代。
| 评估问题 | 主要使用者 | 对应决策 |
|---|---|---|
| 结果是否可信 | 测试负责人、发布评审人 | 是否采信本次执行结果作为放行依据 |
| 波动来自哪里 | 测试开发、平台维护者 | 优先修复哪些用例、环境或数据问题 |
| 改进是否有效 | 研发管理者、测试负责人 | 治理动作是否延续、资源是否继续投入 |
指标与范围：用哪些指标、统计哪些对象
建议用六个指标组成稳定性度量集合，每个指标都明确分子、分母、时间窗与单位，保证任何人拿到原始记录都能复算出相同结果。时间窗默认取自然周或两周，单位统一为“百分比”或“次”，同一份报告内不混用。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 执行通过率 | 通过执行次数 ÷ 总执行次数 | 状态为通过的执行次数 | 窗口内全部执行次数（含重跑） | 周/两周 | % |
| 重跑通过率 | 重跑后通过次数 ÷ 重跑总次数 | 首次失败、重跑后通过的次数 | 窗口内发生重跑的总次数 | 周/两周 | % |
| 非代码变更失败占比 | 非代码变更类失败次数 ÷ 总失败次数 | 失败原因归为环境、数据、依赖、超时资源的次数 | 窗口内全部失败次数 | 周/两周 | % |
| 环境/数据类失败占比 | 环境与数据类失败次数 ÷ 总失败次数 | 失败原因归为环境问题与测试数据问题的次数 | 窗口内全部失败次数 | 周/两周 | % |
| 执行时长波动 | 批次执行时长的标准差 ÷ 平均时长 | 各批次执行时长的标准差 | 各批次执行时长的平均值 | 周/两周 | % |
| 用例连续失败次数 | 按用例统计连续失败批次数 | 该用例连续失败的批次数 | 不适用（按用例计数） | 连续批次 | 次 |
统计范围要在评估开始前写清楚：纳入哪些流水线、哪些用例集、哪些环境、哪些分支。常见做法是只统计主干分支上每日定时触发的回归流水线，排除个人分支的手动触发记录；预发与生产验证环境分开统计，不合并成一个通过率。范围一旦确定，整个评估周期内保持不变，中途新增流水线要在报告中单独标注，避免前后数据不可比。
数据口径与证据：失败原因怎么分类
稳定性指标是否可比，取决于失败原因分类是否统一。建议固定六类失败原因，并为每类规定判定依据和必须保留的证据，分类时以证据为准，不凭印象归类。
| 失败原因 | 判定依据 | 需保留的证据 |
|---|---|---|
| 产品缺陷 | 失败可复现，且与本次代码变更或既有功能缺陷相关 | 失败日志、复现步骤、关联缺陷单 |
| 脚本/用例问题 | 断言、定位方式或用例逻辑本身有误 | 脚本变更记录、失败截图 |
| 环境问题 | 被测服务、中间件或执行机异常，与用例无关 | 环境监控记录、服务日志、执行机状态 |
| 测试数据问题 | 数据缺失、被污染或前置数据未就绪 | 数据准备记录、数据库查询结果 |
| 依赖服务问题 | 外部或上游依赖不可用、返回异常 | 依赖服务调用日志、超时记录 |
| 超时与资源问题 | 执行超时、内存或并发资源不足 | 执行时长记录、资源监控曲线 |
分类判定要保留可追溯的证据链：失败日志与截图用于确认现象，重跑结果用于区分偶发与稳定复现，变更记录用于判断是否与代码相关。同一失败如果同时符合多类原因，按“最接近根因”的一类归档，并在备注中写明关联类别，不重复计数。
缺失值和未分类失败需要单独处理：无法判定的失败归入“未分类”，在报告中单列占比，不并入任何一类，也不从分母中剔除。人工标注要记录标注人和标注时间，便于复核。当未分类占比超过总失败的一定比例时，应先补足证据再下结论，否则失败结构分析的可信度不足。这个比例阈值由团队根据自身证据完整度约定，不设通用标准。
计算与评估步骤：从原始记录到稳定性结论
计算流程分六步，每一步都有明确的输入和产物，保证结果可复算、可复核。
- 确定时间窗与批次：选定统计周期和纳入的流水线、用例集、环境、分支，形成批次清单。
- 采集执行记录：导出窗口内全部执行记录，包含用例标识、批次、执行状态、执行时长、重跑标记。
- 标注失败原因：按上一节的六类规则逐条标注，保留证据，未分类单独记录。
- 按公式计算：逐项代入指标公式，保留分子分母原始数值，便于核对。
- 对比基线与趋势：与上一周期或治理前基线对比，观察指标方向和失败结构变化。
- 形成结论：写明主要波动来源、可比性限制和改进建议，不只给一个通过率数字。
几种特殊情况需要提前约定处理方式。分母为零时，该指标记为“不适用”，不写 0%，也不写 100%；批次过少时（例如少于五个批次），结论中标注样本不足，只做描述不做趋势判断；统计周期内发生环境迁移、用例集大改或流水线重构时，前后数据可比性下降，应分段统计或在报告中注明断点。
判断改进是否有效，看趋势和分布，不看单点数值。可观察的信号包括：连续多个周期通过率抬升且波动收窄；非代码变更失败占比下降；重跑通过率下降（说明首次执行更可靠）；高连续失败次数的用例数量减少。单个周期通过率突然升高，可能只是失败用例被临时禁用，需要结合用例集变更记录一起看。
算例：一个两周窗口的稳定性评估
以下为一组演示数据，用于说明计算过程，不代表任何真实团队的实际水平。
某回归流水线在两周内共执行 20 个批次，累计执行 2000 次，其中通过 1760 次，失败 240 次。失败中有 60 次在重跑后通过，重跑总次数为 100 次。240 次失败按原因分类为：产品缺陷 96 次，脚本/用例问题 48 次，环境问题 36 次，测试数据问题 24 次，依赖服务问题 18 次，超时与资源问题 12 次，未分类 6 次。各批次执行时长平均 42 分钟，标准差 6.3 分钟。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 执行通过率 | 1760 ÷ 2000 | 88.0% |
| 重跑通过率 | 60 ÷ 100 | 60.0% |
| 非代码变更失败占比 | (36+24+18+12) ÷ 240 | 37.5% |
| 环境/数据类失败占比 | (36+24) ÷ 240 | 25.0% |
| 执行时长波动 | 6.3 ÷ 42 | 15.0% |
| 未分类失败占比 | 6 ÷ 240 | 2.5% |
结果解读：通过率 88.0% 单独看尚可，但重跑通过率 60.0% 说明首次执行中有相当比例的失败并非稳定复现，执行结果的可信度打了折扣。非代码变更失败占比 37.5%，其中环境与数据类合计 25.0%，是当前最主要的波动来源，优先治理方向应是环境稳定性和测试数据准备，而不是继续增加用例。执行时长波动 15.0%，处于可接受范围，暂不作为主要问题。未分类失败占比 2.5%，证据完整度基本可用，但仍有少量失败需要补充标注。
若上一周期通过率为 85.0%、环境与数据类失败占比为 31.0%，则本周期通过率上升、环境数据类占比下降，方向一致，可以初步判断环境治理动作产生了效果；同时要核对用例集是否有删减，排除通过率被稀释的可能。
解读与限制：指标能说明什么、不能说明什么
稳定性指标说明的是执行结果的可靠程度，不直接说明产品质量。通过率高可能因为用例覆盖的场景有限，也可能因为失败用例被长期跳过；判断缺陷情况仍需结合缺陷发现数量、逃逸到线上的问题以及用例评审记录。把通过率当作质量结论，容易掩盖覆盖盲区。
可比性受三类因素影响：样本量、环境差异和用例变更。批次少、执行次数少的周期，百分比波动会被放大，一两次失败就能让通过率变化几个百分点；不同环境的硬件配置、依赖版本不同，合并统计会掩盖单环境的真实问题；用例集新增、删除或断言调整后，前后周期的通过率不再同口径，需要分段或重新建立基线。
指标适合用于定位改进方向，不适合直接作为个人绩效考核依据。用例失败往往由环境、数据、依赖等多方因素共同造成，按失败次数考核个人会诱导隐藏失败或跳过用例，反而降低数据可信度。更合理的用法是把指标作为团队复盘的事实输入，讨论失败结构、治理优先级和验证方式。
把度量落到协同流程：任务、结果与改进的衔接
指标算得出来，还要能持续算下去。稳定性度量对协同流程有三个要求：自动化任务与执行结果有统一记录，失败原因标注能随结果一起留存，改进事项能从度量结论流转到责任人和验证环节。这三件事如果分散在多个工具里，每次评估都要人工拼数据，口径也很难保持一致。
在工具承载上，可以把定时回归任务、执行批次和结果记录放在测试管理模块中统一组织，流水线集成负责把执行记录回传，效能管理模块汇总周期指标，失败原因标注作为结果记录的一部分保留证据。度量结论形成后，通过项目管理模块建立改进事项，明确负责人、预期验证周期和完成标志，下一周期用同一口径复算，确认改进是否生效。ONES DevOps 解决方案提供项目管理、测试管理、效能管理、流水线集成、代码集成和流程自动化的模块组合，并支持整合 DevOps 工具链、集中可视化展现 CI/CD 全过程，可作为这类流程的承载方向；具体字段与操作方式需结合团队实际配置确认。
一个可执行的衔接方式是：每个评估周期结束后，测试负责人输出指标报告和失败结构分析，在复盘会上确认主要波动来源；测试开发把治理事项拆成可跟踪的任务，关联到具体用例或环境；下一周期复算时，把改进前后的指标并列展示，作为复盘的事实依据。这样度量结果就进入了“采集—分析—改进—验证”的循环，而不是停留在一次性报表上。
常见问题
统计周期内流水线或用例集发生大改，前后数据还能直接比较吗？
不宜直接比较。用例集新增、删除或断言调整，以及流水线重构、环境迁移，都会改变统计口径，前后周期的通过率不再同口径。处理方式有两种：一是以变更点为界分段统计，变更前后各自计算指标并分别说明；二是在变更后重新建立基线，把变更后的第一个完整周期作为新基线，后续周期与它对比。无论采用哪种方式，报告中都要注明断点位置和变更内容，避免读者把口径变化误读为稳定性变化。
重跑通过率高，说明自动化测试稳定还是不稳定？
重跑通过率高，说明首次执行中有较多失败在重跑后消失，这些失败通常与环境抖动、数据未就绪或依赖服务瞬时异常有关，执行结果的可信度因此下降。它反映的是首次执行的可靠性不足，需要结合非代码变更失败占比和环境/数据类失败占比一起看，定位波动来源。反过来，重跑通过率下降且通过率保持稳定，往往意味着首次执行更可靠，是改进生效的信号之一。单看这一个指标容易误判，应放在指标集合里解读。
批次很少的周期，指标还能用来判断趋势吗？
批次过少时，百分比会被放大，一两次失败就可能让通过率变化几个百分点，趋势判断的依据不足。常见做法是：批次少于五个时，结论中标注样本不足，只做描述性说明，不做趋势判断；把相邻几个短周期合并成一个较长窗口再计算，扩大样本量；或者改用绝对次数呈现，例如连续失败批次数、失败次数分布，减少百分比带来的误导。样本量恢复到可用水平后，再恢复周期对比。
失败原因标注由谁来做，如何保证不同人标得一致？
标注通常由熟悉用例和环境的测试开发或平台维护者承担，也可以由执行失败的第一响应人初标、测试负责人复核。保证一致性靠三件事：一是分类规则写成文档，每类给出判定依据和必须保留的证据；二是标注时同步留存日志、截图、重跑结果和变更记录，以证据为准；三是定期抽查已标注记录，发现分歧就回到规则文档补充示例。人工标注要记录标注人和标注时间，便于追溯和复核。未分类失败单独统计，不并入任何一类，也不从分母中剔除。
度量结果怎样进入日常改进流程，避免只停留在报表上？
关键是让度量结论有明确的承接对象。每个评估周期结束后，测试负责人输出指标报告和失败结构分析，在复盘会上确认主要波动来源；测试开发把治理事项拆成可跟踪的任务，关联到具体用例、环境或数据准备环节，明确负责人和预期验证周期；下一周期用同一口径复算，把改进前后的指标并列展示，作为复盘的事实依据。这样度量就进入“采集—分析—改进—验证”的循环。ONES DevOps 解决方案提供项目管理、测试管理、效能管理、流水线集成等模块组合，可作为这类流程的承载方向，具体配置需结合团队实际确认。
