Playwright 三大“不稳定”元凶及修复指南

作为测试工程师，我们都经历过那种令人沮丧的时刻：一个自动化测试用例，昨天还运行得好好的，今天却无缘无故地失败了。再次运行，它又通过了。这种时而成功、时而失败的“不稳定测试”（flaky tests）是自动化测试中最令人头痛的问题之一。它们不仅消耗了宝贵的调试时间，更会逐渐侵蚀整个团队对自动化测试套件的信任。

本文将深入剖析导致 Playwright 测试不稳定的三个最常见元凶，并为你提供直接、可行的解决方案。我们的目标是帮助你构建更可靠、更稳定的测试，让你彻底告别那些难以捉摸的失败。

---

1. 元凶一：时序错乱

现代 Web 应用是动态和异步的，而测试脚本本质上是线性的。当脚本的线性执行与应用的异步状态更新发生冲突时，不稳定性就产生了。这是最常见的不稳定原因：Playwright 脚本的执行速度，有时会超过前端应用的异步状态更新速度，尤其是在涉及 API 数据加载的场景中。

让我们来看一个具体的“宠物诊所”测试场景：测试需要点击“编辑”，将宠物类型从“cat”改为“rabbit”，然后点击“更新”并断言更改成功。

然而，测试失败了。回放执行过程我们发现了一场典型的“竞态条件”（Race Condition）：脚本以毫秒级的速度填入了“rabbit”并点击更新，自以为大功告成。但就在此时，那个姗姗来迟的 API 响应才抵达战场，带着旧值“cat”，毫不留情地覆盖了我们的新输入。断言执行时，看到的是这个被“幽灵”数据复原的现场，测试失败便不足为奇。问题的核心在于，脚本没有等待应用的真实数据状态同步完成，就执行了后续操作。

解决方案 1：使用定位器断言进行同步

一个有效的修复方法是在修改输入框之前，先强制 Playwright 等待应用状态就绪。我们可以通过添加一个定位器断言来实现这一点，确保输入框已经加载了我们预期的旧值。

之所以有效，是因为 expect(locator)... 是一种定位器断言 (locator assertion)，它内置了自动等待和重试机制，这与一次性的通用断言 (generic assertion) 完全不同。这行代码的真正含义是：“请不断重试，直到这个输入框的值变为‘cat’，或者超时后再失败。” 这正是我们实现同步所需要的核心机制。

// 在填充新值之前，先断言旧值已加载
await expect(page.getByRole('textbox')</