构建变红，有人点击“重新运行”，它通过了，每个人都继续前进。这看起来无害，但是片状测试慢慢地破坏了测试套件最有价值的东西：人们对它的信任。当故障通常只是噪音时，真正的错误也会被忽视。

本指南介绍了测试变得不稳定的原因以及如何正确修复每个原因。我们在 Python 3.13 中运行了计时和共享状态演示，显示的数字来自这些运​​行。它们是小型演示，旨在使不稳定的情况变得容易看到，因此您自己的故障率会有所不同。

什么是片状测试？

片状测试对相同的代码给出不同的结果。尽管产品中没有任何变化，但它在一次运行中通过，在下一次运行中失败。测试可能有错误，或者代码可能包含真正的间歇性错误。第二种可能性正是你不应该简单地忽略它们的原因。

为什么片状测试成本如此之高

• 失去信任。一旦人们认为红色意味着“可能不稳定”，他们就会停止调查真正的失败。
• 浪费时间。开发人员花费数小时重新运行管道并检查与他们的更改无关的故障。
• 交付速度较慢。 合并和发布会等待重新运行，从而破坏了 CI/CD 的要点。
• 隐藏的错误。 产品中的竞争条件看起来就像测试噪音，而这些正是在生产中造成损害的。

常见原因一览

原因1：定时和固定睡眠

这是最常见的原因。测试假设后台工作将在固定延迟后完成。为了查看效果，我们编写了一个小测试，其中工作最多需要 2 毫秒，而测试在检查之前只等待 1 毫秒：

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

解决办法是等待实际情况，并设定一个慷慨的上限：

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

我们运行每个版本 200 次：

结果不仅仅是可靠性。固定版本在工作完成后立即移动，因此通常也更快。较长的睡眠时间将使第一个版本失败的频率降低，但每次运行都会变慢，并且在繁忙的 CI 机器上仍然可能失败。

在浏览器测试中，同样的原则也适用。使用 Playwright 的自动等待，或显式 Selenium waits，而不是 time.sleep：

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

原因 2：共享状态和测试顺序

当测试共享数据时，一个测试可以影响另一个测试，结果取决于它们运行的顺序。这两个测试使用一个共享列表：

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

我们的运行证实了这一点，这就是为什么一个套件可以运行数月，然后在有人添加并行运行或随机排序插件时中断。治疗方法是隔离：

• 使用一个固定装置来设置和清理数据，为每个测试提供新的数据。我们的 pytest 教程 展示了如何操作。
• 创建唯一的记录，例如带有随机后缀的电子邮件，代替共享的“测试用户”。
• 将数据库测试包装在 事务 中，并在您的设置允许的情况下回滚。
• 定期以随机顺序运行测试，以便尽早发现这些问题。

原因 3：日期、时区和随机性

整个星期都通过的测试可能会在周六、午夜或该月的最后一天失败。将时间作为输入，而不是读取逻辑中的时钟：

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

这些测试在任何一天都会给出相同的答案。同样，在测试中为随机值设置固定种子，并在使用随机数据时记录它，以便可以重现故障。不要假设来自外部源的集合、字典或没有 ORDER BY 的数据库查询的特定顺序。

原因 4：选择器脆弱

查找带有 div:nth-child(3) > span 的按钮的测试会因任何布局调整而中断，并且仅对于某些屏幕尺寸或变体可能会失败。首选基于用户所见或专用测试属性的定位器。我们的 Playwright 定位器 指南解释了尝试它们的顺序。动画是另一个常见的麻烦来源，因此请考虑在测试环境中禁用它们。

原因 5：外部服务和网络

如果测试调用真实的支付提供商或第三方 API，那么其结果取决于其他人的正常运行时间和速率限制。模拟大多数测试的这些调用，并针对实际服务保留少量单独的合同检查，以便您仍然可以了解它是否发生变化。我们的单元测试与集成测试指南解释了如何将它们分开。

如何诊断片状测试

1. 确认。多次运行测试，没有任何变化。使用 pytest，一个简单的 shell 循环就可以工作，并且像 pytest-repeat 这样的插件可以为您提供 --count=100。
2. 记录证据。保存每次故障的日志、屏幕截图和痕迹。 Playwright 的跟踪查看器在这里特别有用。
3. 强调条件。 使用有限的 CPU 并行或以随机顺序运行它。经常失败会让学习变得更容易。
4. 单独测试。 如果它总是单独通过但在套件中失败，则怀疑共享状态。
5. 寻找模式。检查涉及哪些机器、一天中的时间以及邻近的测试。
6. 检查产品。 诚实地询问这是否可能是您的应用程序中真正的竞争条件。

自动重试可以修复吗？

重试是一个有用的短期安全网，但并不是治愈方法。 CI 中的单次自动重试可以在您调查时保持工作顺利进行，但需要重试才能通过的测试仍然会告诉您一些信息。更糟糕的是，真正的间歇性产品错误在 20% 的时间内失败，通常会在不被注意到的情况下重试。

使用这些规则的重试：将重试限制为一两次，记录需要重试的每个测试，并将该列表视为您的待办事项列表。报告为“重试通过”的测试应视为需要调查的问题，而不是成功。

片状测试的团队流程

1. 测量。 跟踪哪些测试失败，然后通过相同的提交。许多 CI 工具和测试报告程序都可以证明这一点。
2. 隔离。 将已确认的片状测试移出阻塞运行，以便它停止干扰每个人，但继续运行并跟踪它。
3. 指定所有者和截止日期。 没有截止日期的隔离区只会变成墓地。
4. 修复或删除。如果测试不值得修复，请将其删除，并检查其覆盖范围是否仍然存在于其他地方。
5. 预防。 在合并之前多次运行新测试。每五十次运行失败一次的测试现在比六个月后更容易被捕获。

将不稳定的测试视为优先的错误，而不是背景噪音。严重性和优先级也适用于此，如 严重性与优先级 中所述。如果不稳定现象很普遍，请阅读更广泛的测试自动化错误，并考虑您是否在浏览器级别进行了太多测试。

最后的话

片状测试让人感觉是随机的，但实际上很少如此。几乎每个人都可以归结为关于时间、顺序、数据或环境的假设，但这些假设并不总是正确的。选择本周管道中最常失败的测试。运行五十次，找到假设，并永久修复它。一次真正的修复可以教会团队超过一百次的重新运行。

常见问题

继续学习