AI 生成的端到端测试该审哪些坑

我让一个 LLM 为一个简单的登录流程写一条 Playwright 测试。第一次运行就通过了。接着，我把按钮文字从“Sign in”改成“Continue”，重新跑了一遍。测试失败了。模型用了一个依赖 class 名称的 CSS 选择器，还加了固定时长的等待。都是典型的脆弱写法，只不过生成速度比初级工程师手写更快。这种情况正变得越来越常见。团队开始用 AI 起草 Playwright 测试，而 AI 出现之前就存在的那些问题，依然在反复出现。区别只在于数量更多、速度更快。如果不审查生成的代码，你就是明知测试不稳定，还把它们送进 CI。下面就来看看该检查什么，以及怎么修。

AI 通常会写错什么

大多数模型默认会采用训练数据中经常出现的写法：

• 基于位置或 CSS 的定位方式——page.locator('.btn-primary')、按第几个子元素定位，或者很长的 XPath 路径。DOM 结构一变，或者 class 一改名，这些定位方式就会失效。
• 固定时长的等待——await page.waitForTimeout(2000) 或类似写法。模型想“等页面稳定下来”，却不知道 Playwright 的自动等待机制是怎么工作的。
• 断言太弱，甚至没有断言——测试一路点击走完流程，却从不检查用户真正关心的结果，例如是否显示了“Order confirmed”。
• 没有考虑抗变化能力——它优化的是“在我眼前这个页面上能跑通”，而不是“页面稍微改版之后还能跑通”。

生成的代码往往看起来像那么回事，甚至第一次运行还能通过。这恰恰是它危险的地方。

一份实用的审查清单

接受 AI 编写的测试之前，先逐项检查这些问题：

• 定位策略——是否优先使用 getByRole、getByLabel 或 getByText？还是在用 CSS、XPath 或 nth？
• 等待方式——有没有 waitForTimeout、设置了硬性超时的 waitForSelector，或者其他固定延迟？优先使用会自动重试的 web-first 断言，例如 expect(...).toBeVisible()。
• 实际断言了什么——测试检查的是用户能看到的结果，还是仅仅确认执行了点击？
• 应对改版的能力——如果按钮文字变了、多套了一层 div，或者元素顺序调整了，测试还能通过吗？如果你不确定，那它多半就过不了。

你不需要重写整个测试。找出最脆弱的定位方式或等待逻辑，先修它。一次扎实的修改，往往就能消除测试的不稳定性。

下面是一条典型的 AI 生成的登录测试：

test('user can log in', async ({ page }) => { await page.goto('https://example.com/login'); await page.waitForTimeout(2000); await page.locator('#username').fill('test@example.com'); await page.locator('div.form-group:nth-child(2) input').fill('password123'); await page.locator('.btn-submit').click(); await page.waitForTimeout(3000); await expect(page.locator('.success-message')).toBeVisible(); });

问题包括：固定时长的等待、CSS 和基于位置的定位方式，以及薄弱的断言。修改后的版本如下：

test('user can log in', async ({ page }) => { await page.goto('https://example.com/login'); await page.getByLabel('Email').fill('test@example.com'); await page.getByLabel('Password').fill('password123'); await page.getByRole('button', { name: 'Sign in' }).click(); await expect(page.getByText('Welcome back')).toBeVisible(); });

流程相同，但定位依据变成了用户和辅助技术能感知到的内容，断言也会等待实际结果出现。面对 class 重命名、DOM 顺序调整和按钮文字变化，这个版本能更可靠地继续运行。

阅读检查清单很有用。在有压力的情况下亲自做审查，效果更好。LocatorLeague 的 Foundations 学习路线免费开放，你可以针对真实页面编写并运行 Playwright 定位表达式，立即得到通过或失败的反馈，还能观看运行过程的视频。即将推出的学习路线会加入 AI 编写测试的审查练习，让你专门训练这项技能。

最近 AI 给你写过的最糟糕的定位方式或等待逻辑是什么？欢迎贴到评论区——多看几个例子，你通常就会发现这些套路都很眼熟。

这篇文章的篇幅和语气与上一篇大致相同。你可以原样发布到 Dev.to（或 Hashnode），也可以同步发布到其他平台。LocatorLeague 的链接自然地放在了实用内容之后。

如果还想采取进一步行动，可以考虑屏蔽此人和／或举报其滥用行为。