告别"薛定谔的测试"：Flaky Test 全链路治理实战告别"薛定谔的测试"：Flaky Test 全链路治理实战，我

你的测试今天绿了，明天红了，后天又绿了——这不是量子力学，这是 Flaky Test。

前言

在持续集成（CI）流水线中，你是否遇到过这样的场景：代码没有任何改动，测试结果却在通过和失败之间反复横跳？当你满怀信心地提交了一个功能分支，CI 却因为一个"莫名其妙"的测试失败而亮起红灯，重跑一次又神奇地通过了——这就是 Flaky Test（不稳定测试），测试界的"薛定谔之猫"。

本文将从 Flaky Test 的本质出发，深入剖析其成因与危害，并最终引出我们项目 yuantest-playwright 中构建的一套企业级 Flaky Test 全链路治理体系。

一、什么是"不稳定"测试

"不稳定"测试（Flaky Test）是指表现出间歇性或偶发失败的测试，其行为似乎是非确定性的。有时它会通过，有时会失败，且原因不明。

用更直观的方式理解：

第1次运行: ✅ 通过
第2次运行: ❌ 失败
第3次运行: ✅ 通过
第4次运行: ❌ 失败
第5次运行: ✅ 通过

同样的代码、同样的测试，结果却不一致——这就是 Flaky Test 最核心的特征：非确定性。

二、Flaky Test 的危害：比你想象的更严重

不稳定测试在使用持续集成（CI）服务器时尤其麻烦，因为在合并新的代码更改之前，所有测试都必须通过。如果测试结果不是可靠的信号——即测试失败并不意味着代码更改导致了测试失败——开发人员可能会对测试结果产生不信任，从而忽视真正的失败。此外，这也会浪费时间，因为开发人员必须重新运行测试套件并调查虚假的失败。

具体来说，Flaky Test 带来的危害可以归纳为以下四个层面：

graph TD
    A[Flaky Test 危害] --> B[信任崩塌]
    A --> C[效率损耗]
    A --> D[质量风险]
    A --> E[团队士气]

    B --> B1["开发人员忽视失败信号"]
    B --> B2["CI 红灯变成'狼来了'"]

    C --> C1["反复重跑测试套件"]
    C --> C2["排查虚假失败耗时"]
    C --> C3["CI 资源浪费"]

    D --> D1["真正的 Bug 被掩盖"]
    D --> D2["回归缺陷逃逸到生产"]

    E --> E1["对测试体系失去信心"]
    E --> E2["减少编写测试的动力"]

Google 在 2016 年公开的数据显示，其约有 16% 的测试被标记为 Flaky，这些测试消耗了大量的工程资源。微软也曾在 2017 年分享过消除 Flaky Test 的实践经验，足见这一问题在工业界的普遍性和严重性。

三、原因分析：为什么会出现 Flaky Test

不稳定测试表明该测试依赖于一些未得到适当控制的系统状态——测试环境没有得到充分隔离。高级别的测试更容易出现间歇性，因为它们依赖于更多的状态。

3.1 过于严格的判断

过于严格的断言可能会导致浮点数比较和时间问题。例如：

浮点数精确比较：assert result == 0.1 而非 assert abs(result - 0.1) < epsilon
时间相关断言：assert response_time < 100ms，但网络波动导致偶尔超时
顺序依赖断言：假设 API 返回的数组顺序固定，但实际不确定

3.2 时序与竞态条件

这是最常见的 Flaky Test 根因之一。测试中存在隐式的等待或超时，但等待时间不够稳定：

UI 自动化中等待元素出现，但元素加载时间波动
异步操作未完全完成就进行断言
多线程/多进程下的数据竞争

3.3 环境依赖

测试对运行环境的假设过于理想化：

依赖外部服务（API、数据库），服务可用性不稳定
CI 节点资源波动（CPU、内存、磁盘 IO）
特定时间、时区或语言环境下的行为差异

3.4 测试执行顺序依赖

测试之间存在隐式依赖，单独运行通过，但与其他测试一起运行时失败：

共享数据库状态未清理
全局变量或单例被前序测试修改
测试数据被其他测试消费或污染

3.5 资源泄漏

长时间运行的测试套件中，资源逐步累积：

内存泄漏导致后续测试 OOM
文件句柄未关闭
端口占用未释放

3.6 根因分类总览

将上述原因系统化，我们可以将 Flaky Test 的根因归纳为 7 大类：

graph LR
    A[Flaky Test 根因] --> B[timing<br/>时序问题]
    A --> C[data_race<br/>数据竞争]
    A --> D[environment<br/>环境依赖]
    A --> E[external_service<br/>外部服务]
    A --> F[test_order<br/>执行顺序]
    A --> G[resource_leak<br/>资源泄漏]
    A --> H[assertion_flaky<br/>断言不稳定]

    style B fill:#ff6b6b,color:#fff
    style C fill:#ffa502,color:#fff
    style D fill:#7bed9f,color:#333
    style E fill:#70a1ff,color:#fff
    style F fill:#a29bfe,color:#fff
    style G fill:#fd79a8,color:#fff
    style H fill:#fdcb6e,color:#333

四、传统应对策略及其局限

面对 Flaky Test，业界常见的应对方式包括：

策略	做法	局限性
直接重试	失败后自动重跑 N 次	治标不治本，掩盖真实问题
跳过测试	`.skip()` 标记不稳定测试	测试覆盖率下降，风险积累
人工排查	开发者手动调查	耗时巨大，难以规模化
增加等待	`sleep()` / `waitFor()`	降低执行速度，仍不保证稳定
CI 重跑	失败后手动触发重新运行	浪费 CI 资源，延迟交付

这些策略的共同问题是：缺乏系统性的识别、分类、隔离和修复机制。它们更像是"头痛医头、脚痛医脚"的应急手段，而非根本性的治理方案。

我们需要的是一个 全链路的 Flaky Test 治理体系——从检测到分类，从根因分析到隔离策略，从趋势追踪到预测性防护。

五、yuantest-playwright：企业级 Flaky Test 全链路治理

yuantest-playwright 是一个基于 Playwright 的综合测试编排、执行和报告平台。它的核心理念是 "零学习曲线、零迁移成本、纯 Playwright 生态"——所有 CLI 参数与 Playwright CLI 完全一致，不依赖任何内部 API，用户可随时无缝切换回原生 Playwright。

其中，Flaky Test 智能管理 是该项目的核心差异化能力。下面我们将逐一拆解这套全链路治理体系。

5.1 整体架构

flowchart TB
    subgraph 输入层
        A[测试执行结果] --> B[FlakyTestManager]
    end

    subgraph 检测与分类
        B --> C[分类器<br/>Wilson 置信区间<br/>时间衰减加权]
        C --> D{6 种分类}
        D --> D1[flaky]
        D --> D2[broken]
        D --> D3[regression]
        D --> D4[monitor]
        D --> D5[stable]
        D --> D6[insufficient_data]
    end

    subgraph 深度分析
        D1 --> E[根因分析器<br/>7 种根因检测]
        D1 --> F[关联分析<br/>Jaccard 共现聚类]
        D1 --> G[趋势分析<br/>CUSUM 变点检测]
        D1 --> H[因果依赖图<br/>影响分析]
    end

    subgraph 决策与执行
        E --> I[分级隔离策略<br/>根因感知重试]
        F --> I
        G --> J[健康评分<br/>A-F 等级]
        H --> K[预测性检测<br/>多信号融合]
    end

    subgraph 输出层
        I --> L[执行器集成<br/>自动过滤隔离测试]
        J --> M[Dashboard 可视化<br/>REST API]
        K --> N[高风险预警<br/>建议操作]
    end

    style B fill:#4ecdc4,color:#fff
    style C fill:#45b7d1,color:#fff
    style E fill:#f7dc6f,color:#333
    style I fill:#e74c3c,color:#fff
    style J fill:#2ecc71,color:#fff
    style K fill:#9b59b6,color:#fff

5.2 智能分类器：不只是"通过"和"失败"

传统的 Flaky Test 检测往往只看"是否有时通过、有时失败"，但实际情况远比这复杂。yuantest-playwright 的分类器基于 Wilson 置信区间 和 时间衰减加权失败率，将测试细分为 6 种类型：

分类	含义	判定条件
flaky	不稳定测试	加权失败率 ≥ 0.3，Wilson 下界超过阈值
broken	已损坏测试	连续失败 ≥ 5 次
regression	回归测试	前期稳定（历史失败率 ≤ 20%），近期持续失败（近期失败率 ≥ 60%）
monitor	需关注测试	加权失败率在 0.1 ~ 0.3 之间
stable	稳定测试	加权失败率 < 0.05
insufficient_data	数据不足	运行次数 < 5 次

为什么用 Wilson 置信区间？ 因为小样本情况下，简单的失败率计算会产生误导。比如一个测试跑了 2 次失败 1 次，50% 的失败率看起来很严重，但 Wilson 区间会告诉你：置信度不够，不要过早下结论。

为什么用时间衰减加权？ 因为一个测试 3 个月前经常失败、最近一直通过，和最近才开始频繁失败，是完全不同的情况。时间衰减确保最近的测试结果权重最高：

weight = exp(-decayRate × ageInDays)

分类决策流程如下：

flowchart TD
    A[测试结果输入] --> B{运行次数 ≥ 5?}
    B -- 否 --> C[insufficient_data]
    B -- 是 --> D{连续失败 ≥ 5 次?}
    D -- 是 --> E[broken]
    D -- 否 --> F{近期失败率 ≥ 60%<br/>且历史失败率 ≤ 20%?}
    F -- 是 --> G[regression]
    F -- 否 --> H{加权失败率 ≥ 0.3?}
    H -- 是 --> I[flaky]
    H -- 否 --> J{加权失败率 ≥ 0.1?}
    J -- 是 --> K[monitor]
    J -- 否 --> L[stable]

    style C fill:#95a5a6,color:#fff
    style E fill:#e74c3c,color:#fff
    style G fill:#e67e22,color:#fff
    style I fill:#f39c12,color:#fff
    style K fill:#3498db,color:#fff
    style L fill:#2ecc71,color:#fff

5.3 根因分析器：7 种根因自动检测

识别出 Flaky Test 只是第一步，更重要的是回答"为什么 Flaky"。yuantest-playwright 的根因分析器能自动检测 7 种常见根因，并为每种根因提供专属建议：

根因类型	检测方法	典型建议
timing	超时关键词 + 持续时间变异系数(CV>0.5)	增加等待时间，使用显式等待替代固定 sleep
data_race	不同分片间通过率差异 ≥ 30%	增加同步机制，避免共享可变状态
environment	失败时间聚集 + 特定 CI 节点失败率 ≥ 50%	改善环境隔离，使用容器化
external_service	网络/5xx 错误关键词	增加 Mock/Stub，实现服务降级策略
test_order	前置测试在 ≥ 50% 失败中出现	确保测试独立性，重置共享状态
resource_leak	内存关键词 + 持续时间递增趋势	添加资源清理逻辑，检查内存泄漏
assertion_flaky	断言关键词（排除时序错误为主的情况）	放宽断言精度，使用模糊匹配

根因分析流程：

flowchart LR
    A[Flaky Test] --> B[错误消息分析]
    A --> C[持续时间分析]
    A --> D[分片结果对比]
    A --> E[时间聚集分析]
    A --> F[执行顺序分析]

    B --> G{含超时/网络<br/>关键词?}
    G -- 超时 --> H[timing]
    G -- 网络/5xx --> I[external_service]
    G -- 断言 --> J[assertion_flaky]

    C --> K{CV > 0.5?}
    K -- 是 --> L[timing]
    K -- 递增趋势 --> M[resource_leak]

    D --> N{分片间差异 ≥ 30%?}
    N -- 是 --> O[data_race]

    E --> P{时间聚集 +<br/>节点特异性?}
    P -- 是 --> Q[environment]

    F --> R{前置测试<br/>共现率 ≥ 50%?}
    R -- 是 --> S[test_order]

5.4 分级隔离策略：不是一刀切的跳过

传统做法遇到 Flaky Test 要么跳过、要么重试，但不同根因需要不同的处理策略。yuantest-playwright 提供了 4 级隔离级别 和 5 种隔离策略，并实现了 根因感知重试：

隔离级别：

级别	行为	适用场景
none	正常执行	稳定测试
monitor	继续执行，增加观察	轻度不稳定，需关注
soft_quarantine	允许重试，不计入主流程	中度不稳定，可容忍
hard_quarantine	完全跳过不执行	严重不稳定，影响主流程

根因感知重试策略（核心创新点）：

不同根因需要截然不同的重试策略。例如，时序问题需要增加延迟后重试，而数据竞争则应该"仅通过时重试"（即只有当测试首次通过时才重试验证是否真的稳定）：

根因类型	最大重试	延迟倍数	退避倍数	仅通过时重试
timing	3	×2	2	❌
external_service	3	×3	2	❌
data_race	2	×1	1	✅
environment	3	×2	2	❌
resource_leak	1	×5	1	✅
test_order	0	-	-	-
assertion_flaky	1	×1	1	✅

隔离预算管理：

为了防止大量测试被隔离导致覆盖率骤降，系统引入了隔离预算机制：

最大隔离比例：20%（即使测试全都不稳定，也最多隔离 20%）
最小可隔离数：3（即使 20% 不足 3 个也允许隔离）
预算不足时自动降级为 monitor 模式

自动释放机制：

被隔离的测试不会永远被"关押"：

软隔离：连续通过 3 次后自动释放
硬隔离：连续通过 5 次后自动释放
隔离过期：30 天后自动降级（hard → monitor, soft → monitor），而非直接释放，避免刚释放又 Flaky

完整的隔离决策流程：

flowchart TD
    A[测试执行完成] --> B[分类器判定]
    B --> C{分类结果}

    C -->|flaky| D[触发根因分析]
    C -->|broken| E[硬隔离]
    C -->|regression| F[软隔离]
    C -->|monitor| G[仅监控]
    C -->|stable| H[检查是否可释放]

    D --> I{根因类型}
    I -->|timing/external_service| J[软隔离 + 延迟重试]
    I -->|data_race/assertion_flaky| K[软隔离 + 仅通过时重试]
    I -->|resource_leak| L[硬隔离 + 长延迟重试]
    I -->|test_order| M[硬隔离 + 不重试]
    I -->|environment| N[软隔离 + 标准重试]

    J --> O{隔离预算检查}
    K --> O
    L --> O
    M --> O
    N --> O

    O -- 预算充足 --> P[执行隔离策略]
    O -- 预算不足 --> Q[降级为 monitor]

    H --> R{连续通过次数}
    R -- 软隔离: ≥ 3次 --> S[自动释放]
    R -- 硬隔离: ≥ 5次 --> S
    R -- 隔离 ≥ 30天 --> T[自动降级]

    style E fill:#e74c3c,color:#fff
    style F fill:#e67e22,color:#fff
    style G fill:#3498db,color:#fff
    style S fill:#2ecc71,color:#fff

5.5 关联分析：发现 Flaky Test 背后的系统性问题

有时候，多个 Flaky Test 并非独立事件，而是同一根因的不同表现。yuantest-playwright 使用 Jaccard 共现系数 和 并查集（Union-Find）聚类 来发现这种关联：

flowchart LR
    A[多个 Flaky Test] --> B[计算两两<br/>Jaccard 共现系数]
    B --> C{共现系数 ≥ 0.6?}
    C -- 是 --> D[合并到同一关联组]
    C -- 否 --> E[独立处理]
    D --> F[并查集聚类]
    F --> G[输出关联组]

    G --> H[关联类型]
    H --> H1[same_error_pattern<br/>相同错误模式]
    H --> H2[same_file<br/>同一文件]
    H --> H3[same_run<br/>同次运行]
    H --> H4[same_time_window<br/>同一时间窗口]

    style G fill:#9b59b6,color:#fff

举个例子：如果测试 A、B、C 总是在同一次运行中一起失败，Jaccard 系数会很高，系统会将它们聚类为一个关联组，提示你它们可能共享了某个不稳定的外部依赖。

5.6 趋势分析：从"事后救火"到"事前预警"

yuantest-playwright 的趋势分析器提供了多层次的洞察：

能力	方法	价值
趋势方向检测	线性回归 + R² 判断	判断 Flaky 是在改善还是恶化
变点检测	CUSUM 算法	精确定位失败率突变的时间点
季节模式检测	按小时/天/周分析	发现周期性波动（如高峰期服务不稳定）
代码变更关联	变点与提交时间关联	快速定位引入 Flaky 的代码变更
7 天预测	线性回归 + 季节调整	预判 Flaky 走势，提前干预

趋势方向分为 4 种：

improving 📈：失败率在下降，R² ≥ 0.3
stable ➡️：失败率基本不变
degrading 📉：失败率在上升，R² ≥ 0.3
volatile 🌊：失败率剧烈波动，无明确趋势

5.7 健康评分：量化测试质量

如何一眼判断一个 Flaky Test 的严重程度？yuantest-playwright 提供了 四维加权健康评分体系：

健康评分 = 稳定性 × 35% + 趋势 × 25% + 可恢复性 × 20% + 可预测性 × 20%

维度	权重	含义
稳定性	35%	1 - 加权失败率，越稳定越高
趋势	25%	improving=1, stable=0.7, degrading=0.3, volatile=0.2
可恢复性	20%	通过率 × 1.5（上限 1），能否自我恢复
可预测性	20%	R² 决定系数，行为是否可预测

最终映射为 A-F 等级：

等级	分数范围	含义
A	≥ 0.9	优秀，几乎无 Flaky 风险
B	≥ 0.75	良好，轻微不稳定
C	≥ 0.6	一般，需要关注
D	≥ 0.4	较差，建议优先修复
F	< 0.4	危险，应立即处理

5.8 预测性检测：在失败发生前预警

这是 yuantest-playwright 最"黑科技"的能力之一。通过 多信号融合，在测试真正失败之前就能预警：

flowchart TD
    A[测试历史数据] --> B[持续时间异常检测<br/>Z-Score 方法]
    A --> C[失败模式信号<br/>近期 vs 历史失败率]
    A --> D[环境偏移信号<br/>持续时间分布偏移]
    A --> E[资源压力信号<br/>持续时间递增趋势]

    B --> F[信号加权融合]
    C --> F
    D --> F
    E --> F

    F --> G{融合概率}
    G --> H[输出预测结果]
    H --> I[是否将失败]
    H --> J[失败概率]
    H --> K[置信度]
    H --> L[建议操作]

    style F fill:#e74c3c,color:#fff
    style H fill:#9b59b6,color:#fff

四种预测信号：

信号	检测方法	阈值
持续时间异常	Z-Score	> 2.0
失败模式	近期失败率 - 历史失败率	> 10%
环境偏移	持续时间分布偏移	> 30%
资源压力	持续时间线性趋势斜率	显著正斜率

5.9 因果依赖图：找到 Flaky 的"幕后黑手"

当多个测试同时 Flaky 时，谁是因、谁是果？因果依赖图通过 入度分析 来识别根因节点：

flowchart LR
    subgraph 因果依赖图示例
        A[共享数据库] -->|same_environment| B[测试 A]
        A -->|same_environment| C[测试 B]
        A -->|same_environment| D[测试 C]
        E[外部支付 API] -->|same_environment| C
        E -->|same_environment| F[测试 D]
    end

    style A fill:#e74c3c,color:#fff
    style E fill:#e74c3c,color:#fff

根因识别逻辑：入度低（没有其他节点指向它）、出度高（它指向很多其他节点）的节点更可能是根因。在上图中，"共享数据库"和"外部支付 API"就是根因节点。

影响分析：从根因节点出发，通过 BFS 遍历计算直接和间接影响范围，输出风险等级（critical / high / medium / low）。

5.10 完整的治理闭环

将上述所有能力串联起来，yuantest-playwright 形成了一个完整的 Flaky Test 治理闭环：

flowchart TD
    A[测试执行] --> B[结果记录]
    B --> C[智能分类]
    C --> D[根因分析]
    D --> E[分级隔离]
    E --> F[执行器集成<br/>自动过滤隔离测试]

    C --> G[关联分析]
    G --> H[发现系统性问题]

    C --> I[趋势追踪]
    I --> J[健康评分]

    I --> K[预测性检测]
    K --> L[高风险预警]

    D --> M[因果依赖图]
    M --> N[根因定位]

    F --> O[自动释放/降级]
    O --> A

    J --> P[Dashboard 可视化]
    L --> P
    N --> P
    H --> P

    P --> Q[开发者决策]
    Q --> R[修复 Flaky Test]
    R --> A

    style A fill:#4ecdc4,color:#fff
    style P fill:#3498db,color:#fff
    style R fill:#2ecc71,color:#fff

六、开箱即用：零配置即可享受

yuantest-playwright 的 Flaky Test 管理能力是 开箱即用 的，无需额外配置即可启动。所有参数都有精心调优的默认值，同时支持三种方式自定义：

6.1 配置文件

在 user-preferences.json 中自定义判定参数：

{
  "flakyCriteria": {
    "flakyThreshold": 0.25,
    "monitorThreshold": 0.08,
    "brokenConsecutiveThreshold": 5,
    "minimumRuns": 5
  },
  "quarantineCriteria": {
    "maxQuarantineRatio": 0.15,
    "autoReleaseSoftQuarantinePasses": 3,
    "autoReleaseHardQuarantinePasses": 5,
    "quarantineExpiryDays": 30
  }
}

6.2 Dashboard 可视化调整

通过 Web Dashboard 的可视化对话框，拖拽滑块即可调整参数，无需编辑配置文件。

6.3 REST API

提供 20+ 个 Flaky 相关 API 端点，方便与 CI/CD 和其他系统集成：

# 获取 Flaky 测试列表
GET /api/v1/flaky

# 获取已隔离测试
GET /api/v1/flaky/quarantined

# 隔离指定测试
POST /api/v1/flaky/:testId/quarantine

# 释放指定测试
POST /api/v1/flaky/:testId/release

# 获取根因分析
GET /api/v1/flaky/:testId/root-cause

# 获取关联分析
GET /api/v1/flaky/correlations

# 获取健康评分
GET /api/v1/flaky/health

# 获取失败预测
GET /api/v1/flaky/prediction/:testId

# 获取因果依赖图
GET /api/v1/causal-graph

# 重跑单个测试
POST /api/v1/runs/:runId/tests/:testId/rerun

七、实战效果

让我们看一个真实场景的治理效果：

场景：一个 E2E 测试套件中有 200 个测试，其中约 15 个经常间歇性失败。

阶段	传统方式	yuantest-playwright
识别	人工观察 CI 历史，逐个标记	自动分类：7 个 flaky + 3 个 broken + 2 个 regression + 3 个 monitor
根因	开发者逐个排查，耗时数天	自动检测：5 个 timing + 4 个 external_service + 3 个 test_order + 3 个 environment
处置	全部 .skip() 或盲目重试	根因感知重试 + 分级隔离，保留 85% 的测试覆盖率
关联	未发现关联	发现 5 个测试因共享数据库关联，1 个因外部 API 关联
趋势	无追踪	发现 2 个测试在每周五下午失败率飙升（高峰期服务不稳定）
预测	无	提前预警 3 个高风险测试
修复	修复后无法验证	健康评分从 D 升至 B，连续通过后自动释放

八、总结

Flaky Test 是测试工程中的顽疾，传统的人工排查和简单重试无法从根本上解决问题。我们需要的是一套 系统化、自动化、智能化 的治理体系：

flowchart LR
    A[检测] --> B[分类]
    B --> C[根因分析]
    C --> D[隔离策略]
    D --> E[趋势追踪]
    E --> F[预测预警]
    F --> G[修复验证]
    G --> A

    style A fill:#e74c3c,color:#fff
    style C fill:#f39c12,color:#fff
    style D fill:#3498db,color:#fff
    style F fill:#9b59b6,color:#fff
    style G fill:#2ecc71,color:#fff

yuantest-playwright 正是这样一套方案，它提供了：

🎯 Wilson 置信区间 + 时间衰减加权 的 6 种智能分类
🔍 7 种根因自动检测，每种配有专属建议
🛡️ 4 级隔离 + 根因感知重试，不是一刀切
🔗 Jaccard 共现 + 并查集聚类，发现系统性问题
📈 CUSUM 变点 + 季节模式 + 代码关联，追踪趋势
💯 四维健康评分，量化测试质量
🔮 多信号融合预测，在失败前预警
🕸️ 因果依赖图，定位幕后黑手

最重要的是——零学习曲线、零迁移成本。所有 CLI 参数与 Playwright CLI 完全一致，你可以随时无缝切换回原生 Playwright。

项目地址：github.com/yuandiv/yua…
文档地址：yuantest-playwright.readthedocs.io

告别"薛定谔的测试"，从今天开始 🚀

参考资料

Gao, Zebao, et al. "Making system user interactive tests repeatable: When and what should we control?" ICSE, 2015. www.cs.umd.edu/~atif/pubs/…
Palomba, Fabio, and Andy Zaidman. "Does refactoring of test smells induce fixing flaky tests?" ICSME, 2017. drive.google.com/file/d/10Hd…
Bell, Jonathan, et al. "DeFlaker: Automatically detecting flaky tests." ICSE, 2018. www.jonbell.net/icse18-defl…
Dutta, Saikat, et al. "Detecting flaky tests in probabilistic and machine learning applications." ISSTA, 2020. www.cs.cornell.edu/~saikatd/pa…
No more flaky tests on the Go team by Pavan Sudarshan, 2012
Flaky Tests at Google and How We Mitigate Them by John Micco, 2016
Where do our flaky tests come from? by Jeff Listfield, 2017
Eliminating Flaky Tests by Munil Shah, 2017