跳至主要內容

E2E 测试稳定性实战——Flaky Test 的根本原因与系统性解决方案

老张2026/4/30大约 8 分钟

E2E 测试稳定性实战——Flaky Test 的根本原因与系统性解决方案

适读人群：被 Flaky Test 折磨的测试工程师 / 研发团队 | 阅读时长：约 17 分钟 | 核心价值：从根本上消灭 Flaky Test，建立稳定可信任的 E2E 测试体系

Flaky Test 是团队信任的慢性杀手

我见过太多团队的 E2E 测试走向这个结局：

第一个月，大家兴致勃勃写了几十个测试用例，CI 流水线上线了。

第二个月，测试开始偶发失败，大家重跑一下，通过了，"估计是环境抖动"，标记为 Known Flaky，继续。

第三个月，失败率上升到 20%，每次 CI 失败大家第一反应不是"有 BUG"，而是"又是那几个 Flaky Test"，重跑一下再说。

第四个月，没人相信测试结果了。真正的 BUG 混在 Flaky Test 里，被淹没了。

半年后，团队决定"暂时禁用"这些 E2E 测试，等"有空了再修"。然后就再也没有修。

这就是 Flaky Test 的危害——它不只是让你多重跑几次，它会系统性地摧毁团队对自动化测试的信任。

我花了将近一年系统性地解决这个问题，今天把经验全部写出来。

Flaky Test 的七大根本原因

原因一：硬等待（Thread.sleep）

这是最常见的原因，也是最容易修的。

// 典型的问题代码
driver.findElement(By.id("submit-button")).click();
Thread.sleep(3000); // "等待 3 秒让页面加载完"
String resultText = driver.findElement(By.cssSelector(".result")).getText();

问题： 3 秒在快网络环境够，在慢 CI 服务器上不够；在快 CI 服务器上浪费时间。加多少秒永远是一个猜测。

解法： 用条件等待替代时间等待：

// Playwright 版本（自动等待，无需显式等待）
page.locator("#submit-button").click();
// assertThat 自动重试，直到条件满足或超时
assertThat(page.locator(".result")).isVisible();
String resultText = page.locator(".result").textContent();

// Selenium 版本（显式等待）
driver.findElement(By.id("submit-button")).click();
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));
WebElement result = wait.until(
    ExpectedConditions.visibilityOfElementLocated(By.cssSelector(".result"))
);
String resultText = result.getText();

原因二：测试顺序依赖

// 问题：测试 B 依赖测试 A 创建的数据
@Test
@Order(1)
void testA_createUser() {
    // 创建用户 "testuser"
}

@Test
@Order(2)
void testB_loginWithCreatedUser() {
    // 用 "testuser" 登录——如果 testA 失败了，testB 必然失败
}

解法： 每个测试完全独立，自己负责前提条件：

@Test
void testLoginWithUser() {
    // 方案一：通过 API 直接创建测试数据（最快）
    String userId = TestDataAPI.createUser("testuser@test.com", "Password123");
    
    // 方案二：UI 操作准备数据（较慢，但更接近真实）
    new RegistrationPage(page, BASE_URL)
        .registerUser("testuser@test.com", "Password123");
    
    // 执行测试
    new LoginPage(page, BASE_URL)
        .loginAs("testuser@test.com", "Password123")
        .verifyLoaded();
    
    // 清理数据
    TestDataAPI.deleteUser(userId);
}

原因三：环境状态污染

现象： 单独跑一个测试通过，和其他测试一起跑就失败。

原因： 其他测试修改了共享状态——数据库数据、缓存、Cookie、LocalStorage 等。

解法：

// 1. 使用独立的 BrowserContext（Playwright）
@BeforeEach
void createFreshContext() {
    // 每次测试都是全新的浏览器上下文，没有任何 Cookie 或 Storage
    context = browser.newContext();
    page = context.newPage();
}

// 2. 数据库操作在测试前清理特定数据
@BeforeEach
void cleanTestData() {
    TestDataAPI.deleteUserByEmail("testuser@test.com");
}

@AfterEach
void cleanupAfterTest() {
    TestDataAPI.deleteUserByEmail("testuser@test.com");
}

// 3. 使用随机化的测试数据，避免冲突
String uniqueEmail = "test_" + System.currentTimeMillis() + "@test.com";

原因四：动画和过渡效果

现象： 点击按钮时，按钮正在执行 CSS 动画，Playwright/Selenium 在动画中途操作导致不稳定。

解法：

// Playwright：等待元素稳定（不再移动）
page.locator(".modal-overlay").waitFor(
    new Locator.WaitForOptions().setState(WaitForSelectorState.VISIBLE)
);
// Playwright 的 click() 内置等待元素稳定，通常够用

// Selenium：注入 CSS 禁用动画（在测试环境）
JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript(
    "var style = document.createElement('style');" +
    "style.innerHTML = '*, *::before, *::after { animation-duration: 0s !important; transition-duration: 0s !important; }';" +
    "document.head.appendChild(style);"
);

或者在应用层面，当检测到 E2E 测试环境时禁用动画：

/* 应用的 CSS */
body.e2e-testing *, 
body.e2e-testing *::before, 
body.e2e-testing *::after {
    animation-duration: 0ms !important;
    transition-duration: 0ms !important;
}
// 在测试 setup 时注入 class
page.evaluate("document.body.classList.add('e2e-testing')");

原因五：异步操作时序问题

这是最难调试的 Flaky Test 类型。

现象： 提交表单后，后端接口还没返回，测试就去断言结果了。

// 问题代码
page.locator("button.submit").click();
// 没有等待接口返回就断言
assertThat(page.locator(".success-message")).isVisible(); // 有时候接口还没响应就执行这行

解法： 显式等待接口完成：

// 方案一：等待特定网络请求完成（Playwright）
Response apiResponse = page.waitForResponse(
    response -> response.url().contains("/api/order/submit") 
                && response.status() == 200,
    () -> page.locator("button.submit").click()
);

// 然后再断言 UI
assertThat(page.locator(".success-message")).isVisible();

// 方案二：等待 UI 状态变化（更可靠，不依赖具体 API 路径）
page.locator("button.submit").click();
// 等待提交按钮变为 disabled（表示请求已发出）
assertThat(page.locator("button.submit")).isDisabled();
// 等待 loading 消失
assertThat(page.locator(".loading-overlay")).isHidden();
// 等待成功提示出现
assertThat(page.locator(".success-message")).isVisible();

原因六：元素被遮挡（Element not interactable）

现象： Element is not interactable 或 Element is obscured by another element

原因： 按钮被另一个元素覆盖——可能是固定头部、Toast 通知、Cookie 弹窗等。

// Playwright 的处理
// 方案一：等待遮挡元素消失
page.locator(".cookie-banner .accept-btn").click(); // 先关闭 Cookie 弹窗
page.locator("#submit-btn").click();

// 方案二：滚动到元素可见区域
page.locator("#submit-btn").scrollIntoViewIfNeeded();
page.locator("#submit-btn").click();

// 方案三：使用 force 点击（绕过可见性检查，慎用）
page.locator("#submit-btn").click(new Locator.ClickOptions().setForce(true));

// Selenium 的处理
WebElement element = driver.findElement(By.id("submit-btn"));
Actions actions = new Actions(driver);
actions.moveToElement(element).click().perform(); // 移动到元素再点击

// 或者 JS 点击（绕过 WebDriver 可见性检查）
((JavascriptExecutor) driver).executeScript("arguments[0].click();", element);

原因七：日期时间依赖

现象： 测试在某些日期失败（比如月末、年末、节假日），其他时候正常。

原因： 测试逻辑依赖了当前时间，或者应用中有时间相关逻辑（节假日优惠、定时任务等）。

解法：

// Playwright：通过 context 固定时间
BrowserContext context = browser.newContext(new Browser.NewContextOptions()
    .setTimezoneId("Asia/Shanghai")
);

// 通过 JS 注入 Mock 时间
page.evaluate("""
    const fixedDate = new Date('2024-06-15T10:00:00');
    const originalDate = Date;
    Date = class extends originalDate {
        constructor(...args) {
            if (args.length === 0) return fixedDate;
            super(...args);
        }
        static now() { return fixedDate.getTime(); }
    };
""");

// 或者后端提供时间注入接口（测试环境专用）
TestDataAPI.setMockTime("2024-06-15T10:00:00");

系统性治理 Flaky Test 的方法论

知道原因还不够，关键是建立系统。

第一步：度量现状

不知道哪些测试是 Flaky 的，就无法有针对性地解决：

# 简单的 Flaky 统计脚本（Python）
import json
import os
from collections import defaultdict

def analyze_test_results(results_dir):
    test_history = defaultdict(list)
    
    for filename in os.listdir(results_dir):
        if filename.endswith('.json'):
            with open(os.path.join(results_dir, filename)) as f:
                results = json.load(f)
                for test in results['tests']:
                    test_history[test['name']].append(test['status'])
    
    flaky_tests = []
    for test_name, history in test_history.items():
        if 'PASS' in history and 'FAIL' in history:
            pass_rate = history.count('PASS') / len(history)
            flaky_tests.append({
                'name': test_name,
                'pass_rate': f"{pass_rate:.1%}",
                'total_runs': len(history)
            })
    
    flaky_tests.sort(key=lambda x: float(x['pass_rate'].rstrip('%')))
    return flaky_tests

第二步：优先级排序

治理 Flaky Test 是有成本的，按影响排优先级：

  • P0： 失败率 > 50%，每次几乎都要重跑，立即修复
  • P1： 失败率 20-50%，严重影响 CI 信心，本周内修复
  • P2： 失败率 5-20%，有干扰但还能用，规划修复
  • P3： 失败率 < 5%，保持观察

第三步：隔离与标注

修复期间，先把 Flaky Test 隔离，不让它影响主干：

// JUnit 5：添加 @Disabled 并说明原因
@Test
@Disabled("Flaky: P1 - 等待元素时序问题，预计 2024-02-15 修复 #ISSUE-1234")
void shouldCompletePaymentFlow() {
    // ...
}

// 或者使用 @Tag 标记，CI 中跳过
@Test
@Tag("flaky")
void shouldCompletePaymentFlow() {
    // ...
}
<!-- Maven Surefire 跳过 flaky 标签的测试 -->
<configuration>
    <excludedGroups>flaky</excludedGroups>
</configuration>

第四步：自动重试机制（临时措施）

在修复期间，可以配置自动重试减少误报，但这是治标不治本：

<!-- Maven Surefire 自动重试 -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <rerunFailingTestsCount>2</rerunFailingTestsCount>
    </configuration>
</plugin>
// JUnit 5 扩展实现重试
public class RetryExtension implements TestExecutionExceptionHandler {
    
    private static final int MAX_RETRIES = 3;
    private int retryCount = 0;
    
    @Override
    public void handleTestExecutionException(ExtensionContext ctx, Throwable t) throws Throwable {
        if (retryCount < MAX_RETRIES) {
            retryCount++;
            System.out.println("测试失败，第 " + retryCount + " 次重试: " + ctx.getDisplayName());
            ctx.getTestMethod().ifPresent(method -> {
                // 重新执行测试方法（需要反射）
            });
        } else {
            throw t;
        }
    }
}

第五步：建立预防机制

// Code Review Checklist 中加入 E2E 测试稳定性检查
// 1. 是否有 Thread.sleep？（禁止）
// 2. 是否有测试顺序依赖？（禁止）
// 3. 断言前是否等待了异步操作完成？（必须）
// 4. 测试数据是否会造成冲突？（必须使用唯一化数据）
// 5. 是否清理了测试数据？（必须）

踩坑实录总结

坑一：Playwright 的 waitForLoadState('networkidle') 导致测试超慢

现象： 用了 networkidle 后，测试稳定了，但每个测试慢了 3-5 秒。

原因： networkidle 要等待网络请求"静默"2 秒钟，任何后台请求（心跳包、埋点、监控上报）都会重置等待计时器。

解法： 用更精确的等待：等待特定元素，而不是等待网络静默。

坑二：并行测试时数据库冲突

现象： 单线程跑没问题，并行跑时出现"用户已存在"等数据冲突错误。

解法： 每个测试使用带时间戳或 UUID 的唯一测试数据：

String testRunId = UUID.randomUUID().toString().substring(0, 8);
String uniqueEmail = "test_" + testRunId + "@test.com";
String uniqueUsername = "user_" + testRunId;

坑三：截图时机不对导致截图没有帮助

现象： 测试失败时截了图，但截图显示的是失败后的空白页面，不是失败时的页面状态。

解法： 在 assertThat 失败抛异常之前截图，使用 JUnit 5 的 TestWatcher 扩展：

public class ScreenshotOnFailureExtension implements TestWatcher {
    @Override
    public void testFailed(ExtensionContext ctx, Throwable cause) {
        // 这里可以访问测试实例，获取 page 对象截图
        ctx.getTestInstance().ifPresent(instance -> {
            if (instance instanceof BaseTest) {
                ((BaseTest) instance).takeFailureScreenshot(ctx.getDisplayName());
            }
        });
    }
}

小结

Flaky Test 没有银弹，但有系统性的方法论：

  1. 度量：先知道哪些测试是 Flaky 的，失败率多少
  2. 分类：找出根本原因（等待？依赖？数据？）
  3. 修复：优先级驱动，P0 立即修，P3 观察
  4. 预防：Code Review + 编码规范，从源头减少 Flaky Test 引入

最重要的心态是：Flaky Test 是 E2E 测试体系的技术债，越早还越便宜。

编辑此页
最近更新:
贡献者: xiaozhangge