自动化测试中的稳定性治理实践：从脆弱用例定位到持续集成中的误报降噪

自动化测试做久了，大家都会遇到一个很真实的问题：不是没有测试，而是测试“不可信”。

CI 一跑一片红，重新点一次又绿了；回归看起来覆盖很多，但真正线上出问题时，失败用例并没有提前预警；测试同学和研发同学每天都在“看红灯”，却越来越难判断到底是代码坏了，还是用例自己脆了。

我自己做过几轮测试稳定性治理，最大的感受是：稳定性问题不是单点故障，而是一个系统性问题。它通常混杂了环境波动、数据污染、异步时序、外部依赖不稳定、断言设计粗糙、以及 CI 流程策略不合理等因素。
所以这篇文章不只讲“怎么修一个 flaky case”，而是想带你从治理视角，把链路串起来：如何定位脆弱用例、如何给误报分层、如何在持续集成中降噪，又不牺牲真实缺陷的拦截能力。

背景与问题

在很多团队里，自动化测试最初的问题往往不是“数量不够”，而是“质量失真”。

典型现象包括：

• 同一个用例在同一分支上随机失败
• 夜间构建失败率很高，但白天手工重跑能通过
• UI 自动化在本地稳定，放到 CI 容器里就开始抖动
• 集成测试经常被外部接口限流、超时、数据污染拖垮
• 团队慢慢形成一种危险默契：先 rerun，再说

一旦这种情况持续，后果通常有三层：

1. 工程层面：CI 信号失真，流水线红绿灯不再可靠
2. 协作层面：研发对测试结果失去信任，失败告警被习惯性忽略
3. 业务层面：真正的回归缺陷可能被噪音掩盖，发布风险上升

稳定性治理的目标，不是让所有用例 100% 不失败——这是不现实的。
更实际的目标是：

• 尽量让失败结果可解释
• 将失败原因结构化分类
• 在 CI 中把真实缺陷和环境/用例噪音区分开
• 让测试系统产出的信号，重新具备决策价值

先统一几个概念

在往下走之前，先把几个容易混淆的概念说清楚。

什么是脆弱用例（Flaky Test）

脆弱用例的典型定义是：

在代码和环境没有实质变化的情况下，同一测试会随机通过或失败。

这类问题最麻烦的地方，不是它一定失败，而是它不稳定地失败。
它会消耗大量排查时间，还会污染团队对自动化测试体系的信任。

什么是误报

误报不完全等于 flaky。
误报更偏向“测试报警了，但并不是产品代码真实缺陷”。

比如：

• 测试环境网络抖动导致 API 超时
• 第三方服务限流
• CI 节点磁盘满了
• 测试数据被并发任务污染
• 页面元素渲染慢了一点，导致显式等待没配好

这里面有些是 flaky，有些是稳定可复现的基础设施问题。
所以治理时，不要把所有红灯都打包叫 flaky，否则后面很难归因和制定策略。

核心原理

稳定性治理不是一招鲜，通常要同时做四件事：

1. 识别：找出哪些用例、哪些模块最不稳定
2. 归因：判断失败是产品缺陷、测试脚本问题、环境问题还是外部依赖问题
3. 降噪：在 CI 流程中减少无意义失败对主流程的干扰
4. 修复与预防：通过设计规范、隔离策略、观测指标降低未来噪音

1. 稳定性治理的核心闭环

flowchart TD
    A[CI 执行测试] --> B[采集结果与日志]
    B --> C[失败分类]
    C --> D{是否疑似脆弱用例}
    D -- 是 --> E[重跑验证 + 历史波动分析]
    D -- 否 --> F[直接进入缺陷定位]
    E --> G[标记 flaky/环境问题/脚本问题]
    G --> H[治理动作: 修脚本、隔离依赖、优化数据、调整等待]
    F --> I[创建缺陷或阻断发布]
    H --> J[更新规则与指标]
    I --> J
    J --> A

这个闭环里，最关键的是两件事：

• 失败分类要结构化
• 治理动作要能回流到规则和流程中

很多团队卡住，是因为只做了“重跑”，没做分类，也没做闭环。
结果就是：今天 rerun，明天继续 rerun。

2. 脆弱用例定位的三个维度

要定位脆弱用例，我一般会从三个维度一起看。

维度一：历史通过率与波动性

不要只看最近一次失败，要看一段时间的数据：

• 最近 7 天/14 天通过率
• 在代码无变更前提下的失败次数
• 同一提交上的多次运行结果是否一致
• 失败是否集中在特定时间段、特定机器、特定环境

比如一个用例：

• 总通过率 92%
• 最近 20 次运行里有 4 次失败
• 失败分布在不同提交上
• 重跑后大多通过

那它大概率就是典型 flaky 候选。

维度二：失败签名聚类

失败日志不要只靠人工看。
可以抽取“失败签名”做聚类，比如：

• 异常类型
• 栈顶 3 行调用
• 关键错误码
• 页面定位失败的 selector
• API 响应状态码 + 业务错误码

这样你会发现，看起来是 100 个失败，实际上可能只是 4 类问题：

• TimeoutException
• Connection reset by peer
• AssertionError: expected 200 got 500
• ElementNotInteractableException

一旦聚类出来，处理效率会高很多。

维度三：运行上下文

这一步经常被忽略，但很重要。
失败并不一定来自用例本身，而是上下文触发了它。

要一起采集的上下文包括：

• 执行机器/容器 ID
• CPU、内存、磁盘使用率
• 网络时延
• 浏览器版本/驱动版本
• 测试环境版本
• 外部依赖状态
• 数据集版本
• 并发执行槽位

很多“玄学问题”，最后都是靠上下文字段破案的。

3. 在 CI 中降噪，但不放过真问题

误报降噪最怕走向两个极端：

• 极端一：所有失败都 rerun，最后总能绿
• 极端二：任何失败都阻断，团队每天都在修测试

合理做法是分层处理。

stateDiagram-v2
    [*] --> 初次失败
    初次失败 --> 失败分类
    失败分类 --> 真实缺陷候选: 业务断言失败/稳定复现
    失败分类 --> 噪音候选: 超时/环境抖动/依赖异常
    噪音候选 --> 自动重跑验证
    自动重跑验证 --> 标记为疑似脆弱用例: 重跑通过
    自动重跑验证 --> 升级为真实故障: 重跑仍失败
    真实缺陷候选 --> 阻断合并
    升级为真实故障 --> 阻断合并
    标记为疑似脆弱用例 --> 非阻断告警

这里有两个原则我非常建议坚持：

原则一：重跑不是为了“洗绿”，而是为了“分类”

如果失败后自动重跑 2 次：

• 3 次都失败：高概率是真问题
• 第 1 次失败、后 2 次通过：高概率是 flaky 或环境波动
• 3 次结果混乱：说明这个用例极不稳定，必须进入治理池

原则二：不同测试层级，用不同阻断策略

比如：

• 单元测试：应高阻断，理论上最稳定
• 集成测试：允许有限重试，但要记录失败分类
• 端到端/UI 测试：更适合分级阻断，不能一刀切全卡主干

否则会出现一个很常见的问题：
把最不稳定的 UI 自动化，放在最关键的 merge gate 上，最后整个研发效率被拖住。

方案分层：从“修一个用例”到“治理一类问题”

我建议把稳定性治理拆成 4 层：

如果只在用例层打补丁，通常治标不治本。
真正见效的是：让框架、环境和流程一起兜底。

实战代码（可运行）

下面我用一个简化版 Python 示例，演示如何做三件事：

1. 记录测试执行结果
2. 识别疑似脆弱用例
3. 在 CI 里对失败进行自动重跑和分类

这个例子不依赖复杂框架，直接可以跑，适合理解核心思路。

示例一：模拟测试结果并识别脆弱用例

import random
from collections import defaultdict
from dataclasses import dataclass
from typing import List


@dataclass
class TestResult:
    test_name: str
    commit_id: str
    passed: bool
    error_type: str
    duration_ms: int
    worker_id: str


def simulate_results() -> List[TestResult]:
    random.seed(42)
    results = []

    tests = [
        "test_login",
        "test_create_order",
        "test_refund_flow",
        "test_search",
    ]

    commits = ["c1", "c2", "c3", "c4", "c5"]
    workers = ["w1", "w2"]

    for commit in commits:
        for test in tests:
            for _ in range(3):  # 同一提交多次运行，观察稳定性
                if test == "test_login":
                    passed = True
                    error_type = ""
                elif test == "test_create_order":
                    # 模拟脆弱用例：偶发超时
                    passed = random.random() > 0.25
                    error_type = "" if passed else "TimeoutError"
                elif test == "test_refund_flow":
                    # 模拟真实缺陷：稳定失败
                    passed = False
                    error_type = "AssertionError"
                else:
                    # 模拟环境波动：少量网络错误
                    passed = random.random() > 0.15
                    error_type = "" if passed else "ConnectionError"

                results.append(
                    TestResult(
                        test_name=test,
                        commit_id=commit,
                        passed=passed,
                        error_type=error_type,
                        duration_ms=random.randint(100, 1200),
                        worker_id=random.choice(workers),
                    )
                )
    return results


def analyze_flaky(results: List[TestResult]):
    grouped = defaultdict(list)
    for r in results:
        grouped[r.test_name].append(r)

    report = []
    for test_name, items in grouped.items():
        total = len(items)
        passed_count = sum(1 for x in items if x.passed)
        pass_rate = passed_count / total

        # 同一 commit 下既有通过又有失败，判为波动
        commit_mixed = 0
        for commit in set(x.commit_id for x in items):
            commit_items = [x for x in items if x.commit_id == commit]
            if any(x.passed for x in commit_items) and any(not x.passed for x in commit_items):
                commit_mixed += 1

        error_types = defaultdict(int)
        for x in items:
            if not x.passed:
                error_types[x.error_type] += 1

        likely_flaky = (0 < pass_rate < 1) and commit_mixed > 0

        report.append({
            "test_name": test_name,
            "total_runs": total,
            "pass_rate": round(pass_rate, 2),
            "mixed_commits": commit_mixed,
            "likely_flaky": likely_flaky,
            "top_errors": dict(error_types),
        })

    report.sort(key=lambda x: (not x["likely_flaky"], x["pass_rate"]))
    return report


if __name__ == "__main__":
    results = simulate_results()
    report = analyze_flaky(results)

    print("=== Flaky 分析报告 ===")
    for item in report:
        print(item)

运行后你会看到类似结果：

• test_create_order：通过率不是 0 也不是 1，而且同一提交内有混合结果，典型 flaky
• test_refund_flow：稳定失败，更像真实缺陷或脚本逻辑错误
• test_search：可能表现为环境波动候选
• test_login：稳定通过

这个例子虽然简化，但已经体现了一个治理上的重要思路：

脆弱用例不只是“失败多”，而是“结果波动大”。

示例二：CI 中的自动重跑与分类

下面这个脚本模拟 CI 中的失败分类逻辑。

import random
from dataclasses import dataclass


@dataclass
class RunOutcome:
    passed: bool
    error_type: str


def run_test_once(test_name: str) -> RunOutcome:
    if test_name == "test_payment":
        # 假设是真实缺陷，稳定失败
        return RunOutcome(False, "AssertionError")
    elif test_name == "test_profile":
        # 假设是脆弱用例，偶发超时
        if random.random() < 0.4:
            return RunOutcome(False, "TimeoutError")
        return RunOutcome(True, "")
    else:
        return RunOutcome(True, "")


def classify_with_rerun(test_name: str, reruns: int = 2):
    outcomes = [run_test_once(test_name)]
    if outcomes[0].passed:
        return {
            "test_name": test_name,
            "final_status": "PASS",
            "category": "stable",
            "attempts": outcomes,
        }

    for _ in range(reruns):
        outcomes.append(run_test_once(test_name))

    fail_count = sum(1 for x in outcomes if not x.passed)
    error_types = list({x.error_type for x in outcomes if x.error_type})

    if fail_count == len(outcomes):
        category = "real_failure_candidate"
        final_status = "FAIL"
    elif fail_count < len(outcomes):
        category = "suspected_flaky"
        final_status = "NON_BLOCKING_WARN"
    else:
        category = "unknown"
        final_status = "FAIL"

    return {
        "test_name": test_name,
        "final_status": final_status,
        "category": category,
        "attempts": outcomes,
        "error_types": error_types,
    }


if __name__ == "__main__":
    random.seed(7)

    for test_name in ["test_payment", "test_profile", "test_settings"]:
        result = classify_with_rerun(test_name)
        print(f"\n=== {test_name} ===")
        print("final_status:", result["final_status"])
        print("category:", result["category"])
        print("error_types:", result.get("error_types", []))
        print("attempts:", result["attempts"])

这个脚本体现的不是“重试机制本身”，而是重试结果如何影响门禁策略：

• PASS：直接通过
• FAIL：阻断
• NON_BLOCKING_WARN：不阻断，但要进入治理池并告警

这比简单粗暴地“失败就自动重试直到通过”靠谱得多。

示例三：基于 pytest 的简单稳定性钩子

如果你的团队用的是 pytest，可以先从最小化落地做起：在测试完成后输出统一格式结果，方便后续采集。

# conftest.py
import json
import time
import pytest


@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_call(item):
    start = time.time()
    outcome = yield
    duration = int((time.time() - start) * 1000)

    result = {
        "test_name": item.nodeid,
        "duration_ms": duration,
        "status": "passed" if outcome.excinfo is None else "failed",
    }

    if outcome.excinfo is not None:
        result["error_type"] = outcome.excinfo.type.__name__

    print("TEST_RESULT_JSON=" + json.dumps(result, ensure_ascii=False))

配合 CI 日志采集，就可以把每次测试的结构化结果送到日志系统、时序数据库或者数据仓库中，再做：

• 稳定性看板
• 用例通过率排行
• 失败签名聚类
• 高频波动机器识别

这一步其实很关键。
很多团队不是不会治理，而是没有足够结构化的数据可用。

CI 中一条比较实用的治理流水线

把上面的原则串起来，一条可落地的 CI 治理流水线大概是这样：

sequenceDiagram
    participant Dev as 开发提交
    participant CI as CI 流水线
    participant Runner as 测试执行器
    participant Analyzer as 稳定性分析器
    participant Report as 报告/告警系统

    Dev->>CI: 提交代码
    CI->>Runner: 执行分层测试
    Runner-->>CI: 原始结果、日志、截图、上下文
    CI->>Analyzer: 发送失败记录
    Analyzer->>Analyzer: 失败签名聚类 + 历史稳定性判断
    Analyzer-->>CI: 返回分类结果
    alt 真实缺陷候选
        CI->>Report: 阻断并通知责任人
    else 疑似脆弱用例
        CI->>Runner: 自动重跑
        Runner-->>Analyzer: 重跑结果
        Analyzer-->>CI: 更新分类
        CI->>Report: 非阻断告警 + 纳入治理池
    end

这条链路里，真正产生价值的不是“会不会重跑”，而是：

• 测试结果能不能被结构化消费
• 分类结果能不能反馈到门禁策略
• 非阻断问题能不能持续进入治理池，而不是被遗忘

常见坑与排查

这一部分我尽量写得更接地气一点，因为很多问题真的不是理论不懂，而是线上总踩重复的坑。

坑一：把固定等待当成稳定性方案

比如 UI 自动化里常见的：

import time
time.sleep(3)

短期看似“修好了”，长期几乎一定反噬：

• 环境快的时候浪费时间
• 环境慢的时候 3 秒仍然不够
• 整体执行时长会越来越长

更好的方式是显式等待、轮询等待，等待的是“条件成立”，而不是“时间过去”。

坑二：断言过于脆弱

有些用例失败不是流程错了，而是断言太死板。

例如：

• 断言完整文案，结果文案里多了一个空格或动态时间
• 断言列表顺序完全固定，但接口并未承诺排序
• 断言整个 JSON 全量相等，但其中有动态字段

治理建议：

• 断言业务关键字段
• 对时间戳、traceId、随机 ID 做忽略或模式匹配
• 对无序集合做集合级断言，不强行比较顺序

坑三：测试数据没有隔离

这个问题在集成测试里极其常见。

典型现象：

• A 用例创建的数据被 B 用例复用
• 并发执行时，同一个用户名/订单号冲突
• 清理脚本不彻底，导致脏数据残留

排查时重点看：

• 数据主键是否唯一
• 用例是否幂等
• 数据是否按测试运行 ID 做命名空间隔离
• teardown 是否在失败场景也能执行

如果环境允许，最好使用：

• 每次运行独立数据集
• 独立数据库 schema
• 独立租户/命名空间
• 或者在关键依赖上使用 mock/stub

坑四：重试掩盖真实问题

我见过不少项目最后的问题不是 flaky 太多，而是“重试策略太宽松”。

比如：

• 一个失败重跑 5 次，只要有一次通过就算成功
• 最终 CI 一片绿色，但实际上真实失败已经被洗掉了

更合理的边界是：

• 限制重跑次数，通常 1~2 次足够
• 只对明确的噪音候选错误类型做重跑，如 TimeoutError、网络抖动类异常
• 对业务断言失败、数据校验失败、接口 500 等，优先视为真实问题候选

坑五：只盯用例，不看基础设施

如果失败总发生在某些 runner、某些时间段、某些浏览器版本，那就别再只修用例了。

建议直接拉以下指标：

• 节点 CPU steal
• 内存不足与 OOM
• 容器启动耗时
• 浏览器与 driver 版本匹配性
• 网络丢包与 DNS 延迟
• 外部依赖接口可用性

很多看似 flaky 的问题，本质上是基础设施不稳定导致测试结果漂移。

排查路径：我更推荐的顺序

如果一个失败刚出现，不要立刻改代码，也不要立刻贴 flaky 标签。
我更建议按这个顺序排查：

第一步：先判断是否可稳定复现

问自己几个问题：

• 同一提交上是否能稳定复现？
• 本地、测试环境、CI 是否一致复现？
• 重跑之后结果是否变化？

如果稳定复现，优先按真实问题处理。
如果不稳定，再进入 flaky 分析路径。

第二步：看失败签名是否单一

• 总是同一个错误类型？
• 栈顶位置是否一致？
• 页面失败是否总在同一个元素？
• API 是否总在同一个依赖接口超时？

如果失败签名不一致，说明可能是环境大类问题，而不是单个用例逻辑问题。

第三步：检查数据与并发

• 并发执行时才失败吗？
• 单独跑是否通过？
• 数据是否冲突？
• 是否存在共享账户、共享订单、共享库存等资源？

这一层的命中率非常高。

第四步：检查等待与异步时序

尤其是 UI 和异步集成测试：

• 页面是否真正加载完成？
• 消息队列/异步任务是否完成？
• 最终一致性是否被考虑？
• 轮询时间窗口是否足够？

第五步：回看环境上下文

到这一步还没定位，再看机器、网络、容器资源和依赖状态。
很多“偶现”就是在这里找到答案。

安全/性能最佳实践

自动化测试稳定性治理，说到底也是工程系统的一部分，所以安全和性能不能不提。

安全最佳实践

1. 不要在日志里直接输出敏感信息

测试日志非常容易被忽视，但它往往会包含：

• 用户手机号
• token
• cookie
• 数据库连接串
• 第三方凭证

建议统一做脱敏输出，例如：

• token 只保留前后几位
• 手机号中间打码
• 响应体按字段白名单打印，而不是全量落盘

2. 凭证按最小权限管理

自动化测试常常要连：

• 测试数据库
• 对象存储
• 消息队列
• 第三方沙箱服务

不要为了省事给全权限账号。
一旦 CI 日志或配置泄露，风险很大。

3. 对失败附件做权限控制

截图、HAR、视频、响应体快照很有帮助，但也可能包含敏感数据。
建议：

• 按项目和角色控制访问
• 设置保留期限
• 对高敏感场景禁用全量页面快照

性能最佳实践

1. 不要让“稳定性治理”把测试执行时间拖垮

治理里最容易引入性能开销的是：

• 过多重跑
• 过量日志
• 过细粒度截图/录屏
• 所有失败都采集全量上下文

建议分层采样：

• 首次失败采集基础信息
• 重跑仍失败时再补充重型附件
• 只对重点流水线开启完整追踪

2. 控制重试的预算

可以给流水线设一个总重试预算，例如：

• 每个用例最多重跑 2 次
• 每条流水线最多额外消耗 10% 执行时长
• 超预算后只分类不重跑

这样可以避免 CI 因为降噪策略反而变慢。

3. 优先治理高频高成本用例

不是所有 flaky 都值得马上修。
优先级建议按下面公式粗略评估：

治理优先级 = 失败频率 × 阻断影响 × 排查耗时 × 执行成本

那些：

• 经常失败
• 经常卡主干
• 每次都要多人协作排查
• 运行很慢

的用例，最值得优先治理。

一套可落地的治理指标

如果你准备在团队里推进这件事，建议不要一上来就喊“提升稳定性”，太空。
最好直接定义指标。

我比较常用的是这几类：

用例级指标

• 用例通过率
• 用例波动率
• 平均失败恢复时间
• 同提交混合结果率

流水线级指标

• 非真实缺陷失败占比
• rerun 后转绿比例
• 阻断失败中的误报率
• 平均 CI 反馈时长

治理效率指标

• flaky 用例总数趋势
• 本周新增 flaky 数量
• 已治理关闭数量
• Top 10 噪音模块

这些指标最好做成可视化看板，不然很难推动长期治理。
因为稳定性治理不是一天见效的，它更像“持续清理系统噪音”。

什么时候该 mock，什么时候该保留真实依赖？

这是实践里经常有争议的一点。

我的经验是：

优先 mock/stub 的场景

• 第三方接口不稳定
• 沙箱限流明显
• 调用成本高
• 失败不影响核心业务验证目标
• 只是为了验证本系统分支逻辑

尽量保留真实依赖的场景

• 核心交易链路
• 关键契约兼容性验证
• 发布前的少量高价值集成回归
• 需要验证真实网络协议、鉴权、证书、网关行为

边界条件是：

mock 的目标是隔离不必要噪音，不是制造虚假安全感。

如果所有依赖都 mock 掉，测试当然“稳定”，但价值也可能被 mock 掉了。

给中型团队的一套最小落地方案

如果你现在团队测试噪音已经比较明显，但又没有太多人力，我建议先做下面这套“最小治理组合”：

1. 结构化采集测试结果
   至少记录：用例名、状态、耗时、错误类型、执行节点、提交 ID

2. 建立 flaky 候选规则
   例如：最近 14 天通过率在 20%~95% 之间，且同提交混合结果超过 2 次

3. CI 分级门禁

   • 单测稳定失败：阻断
   • 集成测试疑似噪音：自动重跑 1~2 次
   • UI 测试重跑后转绿：非阻断但必须告警

4. 维护治理池
   每周看一次 Top flaky 用例，按影响排序修复，不要只靠临时救火

5. 统一用例设计规范
   包括等待策略、数据隔离、断言粒度、失败日志字段

这套方案不算花哨，但对大多数团队来说已经够用了。
关键在于先把“随机处理失败”变成“有规则地处理失败”。

总结

自动化测试稳定性治理，本质上是在解决一个工程信号问题：

• 测试结果是否可信
• 失败是否可解释
• CI 红灯是否值得大家立即停下来处理

如果让我把整篇文章压缩成几条最实用的建议，会是这几条：

1. 不要把所有失败都叫 flaky，先做结构化分类
2. 重跑的目标是分类，不是洗绿
3. 优先看“波动性”，而不是只看失败次数
4. 从用例、框架、环境、流程四层一起治理
5. 让疑似脆弱用例进入治理池，而不是长期带病运行
6. 在 CI 中分级阻断，避免最不稳定的测试层拖垮主干效率

最后提醒一句边界条件：
如果你的测试环境本身持续不稳定、数据不可控、外部依赖质量很差，那么光修测试脚本效果会非常有限。稳定性治理一定要争取研发、测试、平台甚至运维一起参与，否则很容易变成测试团队单方面“背锅”。

真正成熟的自动化测试体系，不是“从不失败”，而是失败时能快速告诉你：到底哪里坏了，值不值得阻断，以及接下来该怎么做。