用一个真实案例告诉你：Playwright三大AI助手，有多香！

近期测试圈有一个爆火的AI小团体，它就是Playwright 的团队研发的3个AI小助手，名字挺唬人：Planner、Generator、Healer。

但说白了，就是三个干脏活累活的“小弟”：

• Planner：打开你的应用，到处点点看看，输出一份测试计划（Markdown）；
• Generator：把测试计划翻译成 .spec.ts 测试代码；
• Healer：跑失败的测试，尝试自己修。

它们统称为：Playwright Test Agents ，就是 Playwright 框架在原生版本集成的三款 AI 助手，主要用来解决自动化测试的核心难题：帮你“想”（Planner）、帮你“写”（Generator）、再帮你“修”（Healer）。

今天咱们从一个实际经历出发，看看他实操下来到底顺不顺利，碰到哪些麻烦，怎么搞定的，最后学到了啥。

项目背景

公司有个内部数据中台，因为开发换了好几拨，文档几乎等于没有，公司最近规范文档，需要把核心流程（登录 → 数据源配置 → 创建数据集 → 发布 API）的 E2E 测试补上。

拿行内的话说，这简直就是一个“屎山”项目。

实践过程分享

第一步：Seed 测试

操作步骤：

官方文档说，先写一个 seed.spec.ts，用来做环境初始化和前置验证。

因为项目里需要先登录，登录之后还要等几个异步权限加载完成才能进到主页。

所以一开始写得很简单：

test('seed', async ({ page }) => { await page.goto('https://xxx.com/login'); await page.fill('#username', 'myuser'); await page.fill('#password', 'mypass'); await page.click('button:has-text("登录")'); await page.waitForURL('**/dashboard');});

跑一下，通过。然后开始执行 npx playwright init-agents --loop=vscode，初始化 Agent。

结果展示：

结果 Planner 开始探索时，直接在登录页卡住。

因为 Seed 里没有把登录态保存下来，Planner 每次启动都会重新走一遍 seed 流程，但不知道哪里没处理好，总是登录失败。

原因分析：

Planner 在探索的时候，会重新运行 seed 测试中的每一步，但它是通过 MCP 工具来操作浏览器的，和本地手动跑 test 的环境不一样。比如项目的登录接口有 CSRF token，seed 测试里用了 page.context() 的 cookie 复用，但 MCP 工具没有自动带上。

重试过程：Seed 测试不能只保证“能跑通”，还要保证能够被 Agent 正确重放。最好的实践是：Seed 里只做最简单的页面打开和基本元素检查，把登录和认证放到 自定义 fixture 里，然后在 playwright.config.ts 里配置 storageState。

改成如下：

// fixtures.tsimport { test as base } from '@playwright/test';export const test = base.extend({ authenticatedPage: async ({ page }, use) => { await page.goto('/login'); // 登录逻辑 await page.context().storageState({ path: 'auth.json' }); await use(page); },});

然后在 seed 里直接 test.use({ storageState: 'auth.json' })。这样 Planner 就不会每次都被登录流程拖累了。

经验总结：Seed 测试是为 Agent 服务的，不是简单为了测通一个场景。 需要理解 Agent 的执行模型，才能把基础打牢。

第二步：Planner输出测试计划

操作步骤：

把 Planner 指向了数据源配置页面，让它生成测试计划。提示词如下：

@planner 为数据源配置页面生成测试计划。主要功能：添加 MySQL 数据源，填写 host、port、用户名、密码，测试连接，保存。覆盖异常场景：连接超时、认证失败、必填项为空。

Planner 确实打开了页面，到处点点点，最后生成了一份 Markdown 计划，看着挺全：什么“TC001 正常添加数据源”“TC002 密码错误时提示”“TC003 测试连接按钮在未填 host 时应禁用”……

出现问题：

老项目里，“测试连接”按钮的启用/禁用逻辑根本不是由前端验证的，而是后端实时返回的权限字段控制的。所以 Planner 生成的 TC003 在现实中根本不成立——因为即便 host 为空，按钮也可能是启用的（后端说这个用户有权限，前端就亮着）。

如果把这个计划直接交给 Generator 生成代码，跑起来必然失败，而且不是 UI 变化导致的失败，是业务逻辑和 Plan 不符。

原因分析：

Planner 再聪明，它也只是一个基于可访问性树和页面交互的表层探索。它看不到业务规则，看不到代码里的 if-else 逻辑。所以它生成的测试计划，必须要人工过滤和修正，不能全盘接收。

最后只采用了 Planner 给出的 60% 的场景，删掉了那些涉及复杂业务规则的，自己又补了几个真实容易出错的边界（比如“保存数据源时网络断开”这种 Planner 根本不会主动去测的）。

第三步：Generator 生成测试代码

操作步骤：

Generator 根据修改后的计划，生成了 datasource-add.spec.ts。

几秒后，tests/datasource-add.spec.ts 生成了。我打开一看，定位符竟然用的是 getByRole 和 getByText，而不是我担心的 hash 类名。

test('搜索无结果时显示空状态', async ({ page }) => { await page.goto('/users'); await page.getByRole('searchbox').fill('一个不存在的用户名'); await page.getByRole('button', { name: '搜索' }).click(); await expect(page.getByText('暂无数据')).toBeVisible();});test('分页切换后搜索条件应保留', async ({ page }) => { await page.goto('/users'); await page.getByRole('searchbox').fill('张三'); await page.getByRole('button', { name: '搜索' }).click(); await page.getByLabel('第 2 页').click(); // 验证搜索框内容依然是“张三” await expect(page.getByRole('searchbox')).toHaveValue('张三');});

它避开了Ant Design 3 那种 ant-select-dropdown-xxxxx 的class名，而是用了组件自带的 ARIA 属性（比如 getByLabel 对应 label 标签）。这是因为它读取的是可访问性树，不是 DOM 结构。

太爽了——这意味着即使前端升级Ant Design版本，这些定位符大概率依然有效。

出现问题：

当然也有小问题。比如它生成的断言里用了page.waitForTimeout(1000)，改成了 waitForSelector。还有一个断言期望文案是“成功”，实际接口返回的是“操作成功”，改了一下。但这些修改量很小，比自己从零写快太多了。

总结：

Generator 生成的代码质量已经超过很多初级测试工程师。把它当草稿，人工优化断言和等待，效率至少提升 80%。

第四步：Healer修复

生成代码后，跑了一遍全量测试。17个测试通过了14 个，挂了3个。把失败信息发给Healer：

@healer 修复 tests/user-list.spec.ts 中失败的用例

Healer 修复过程如下：

• 失败 1：“测试连接”按钮定位超时。原因是该项目的 Ant Design 3 在加载中会替换按钮 DOM 结构，原来的 getByRole('button', { name: '测试连接' }) 找不到。Healer 重新分析了页面，发现加载期间按钮的 aria-label 变成了“加载中”，加载完成后恢复。它把定位改成了 page.getByRole('button').filter({ hasText: /测试连接|加载中/ })，并加了一个 waitForState 等待按钮可用。重跑，通过。
• 失败 2：保存数据源后，断言“列表中出现新数据源”超时。Healer 发现是因为保存后列表刷新较慢，原来的 waitForSelector 超时时间太短。它自动把超时从 5 秒增加到 15 秒，并加了一个 waitForResponse 等待保存接口返回。重跑，通过。
• 失败 3：添加重复名称时，断言“提示重复”失败。Healer 尝试了几次，发现提示文案实际是“数据源名称已存在”，而预期是“重复”。它没有擅自改断言，而是报告“预期文案与实际不符，请确认业务逻辑”，然后把测试标记为 skip。检查了一下，发现是产品后来改了提示文字，但测试计划没更新。当更新了计划中的期望文案，重新生成，就过了。

思考：Healer 不会盲目让测试变绿。它能区分“定位问题”“超时问题”和“业务逻辑变化”，前两种它会自动修，第三种它不会强绕。这让人很放心。

总结

什么人适合用？怎么用效果最好？

适合的场景：

• 你要给一个Web应用从零开始写E2E测试，尤其是你不熟悉业务细节的时候（Planner 帮你探索）。
• 你的项目UI频繁变化，手动维护选择器成本高（Healer 是真救星）。
• 你想快速验证一个新功能的核心路径是否稳定（Generator 几分钟出一版脚本）。

不太适合的场景：

• 你的应用有复杂的非标准交互（比如 Canvas、WebGL），Agent 可能探索不到。
• 你需要深度定制断言逻辑（比如数据库校验），AI 生成的代码只能做基础验证。

最佳实践建议：

1. Seed 测试里不要放复杂登录，用 storageState 保存认证状态。
2. Planner 生成的计划要人工过滤，它不懂你的业务优先级。
3. Generator 生成的代码当草稿用，断言和等待你自己优化一遍。
4. 给 Healer 设好保护上限（比如最多自动修3次），避免它乱改预期。
5. 最终代码提交前，一定要跑一遍全量测试，确保修复没有引入新问题。

看到这，大家还觉得AI能取代自己吗？它只是从“写定位符、调超时、改class 名”这种重复劳动中解放了出来。省下来的时间，去思考更深层次的测试策略，比如怎么造数据、怎么覆盖更多边界。

如果你也在被E2E测试折磨，花一下午试试 Playwright Test Agents。不保证完全无痛，但保证比你硬写爽得多。

☑️想了解更多涨薪技能提升方法

✔️可以到公主号【Atstudy技术社区】,即可加入领取 ⬇️⬇️⬇️

☑️转行、入门、提升、需要的各种干货资料

☑️内含AI测试、 车载测试、AI大模型开发、BI数据分析、银行测试、游戏测试、AIGC