Playwright Test Agents 来了：UI 自动化测试，终于不只是“写脚本”

做 UI 自动化测试的人，应该都遇到过这种场景：

脚本刚写完，页面一改，挂了。 选择器昨天还能用，今天失效了。 本地能跑，CI 上失败。 失败截图看了半天，最后发现只是等待时机不稳定。 好不容易让用例跑绿了，过两周又开始红。

更尴尬的是，很多团队的 UI 自动化并不是没人写，而是写完以后没人敢长期维护。

因为大家心里都清楚：

自动化用例生成出来不难，难的是它能不能稳定运行，能不能真实覆盖业务，能不能放心放进 CI。

这也是为什么很多测试开发同学用 AI 写 Playwright 脚本时，会有一种“看起来提效了，但还是很累”的感觉。

AI 可以帮你生成代码，但它经常不知道你的业务边界在哪里，不知道哪些断言有价值，也不知道哪些失败是真缺陷，哪些失败只是脚本不稳定。

所以，Playwright 官方推出的 Test Agents，真正值得关注的地方，不是“它又能生成代码了”，而是它开始把 UI 自动化测试拆成了一条更完整的工作流：

先规划测试，再生成代码，最后修复失败。

这件事对测试开发岗位来说，信号很明显：

以后自动化测试的重点，可能不再只是“我会不会写 Playwright 脚本”，而是“我能不能设计一套稳定的测试智能体工作流”。

一、以前用 AI 写自动化，为什么总是差点意思？

很多人用 AI 写自动化脚本，大概是这个流程：

你说：帮我写一个登录测试。 AI 生成一段 .spec.ts。 你一跑，失败。 你把报错贴回去。 AI 再改。 你再跑。 还是失败。

最后你会发现，所谓“AI 写自动化”，经常变成了：

你在旁边一步步指挥，AI 在旁边一点点试错。

它确实能帮你省掉一部分敲代码的时间，但没有真正解决 UI 自动化的核心问题：

• 测试场景到底有没有覆盖完整；
• 业务流程理解得对不对；
• 断言是不是有价值；
• 测试数据能不能重复执行；
• 用例之间有没有隐式依赖；
• 失败以后到底该修脚本，还是该提缺陷；
• 这批用例能不能进 CI 长期运行。

这也是很多 UI 自动化项目最后变成“演示时很好看，落地时很难用”的原因。

因为只生成代码，不等于自动化测试建设完成。

二、Playwright Test Agents 改变了什么？

Playwright Test Agents 官方内置了三个 Agent：planner、generator、healer。它们可以单独使用，也可以串成一条 agentic loop：planner 负责探索应用并生成 Markdown 测试计划，generator 负责把测试计划转成 Playwright 测试文件，healer 负责执行测试并自动修复失败用例。

这个设计很有意思。

它不是让 AI 直接生成一堆 .spec.ts，而是在代码之前，先产出一份人能看懂的测试计划。

这一步非常关键。

以前 AI 直接写代码，错了以后你要改 TypeScript。

现在先生成 Markdown 测试计划，计划不对，先改计划。

对测试工程师来说，改一份测试计划，比改一堆选择器、等待条件、断言逻辑，成本低太多。

这就是 Playwright Test Agents 比“直接生成测试代码”更接近工程落地的地方。

三、三个 Agent 分别干什么？

这里一定要分清楚：

Planner 解决的是测试设计问题。Generator 解决的是代码生成问题。Healer 解决的是执行稳定性问题。

不要把 Healer 当成万能修复器。

如果页面选择器变了、等待不足、测试数据过期，Healer 可以尝试修。

但如果需求变了、业务规则变了、接口字段变了、页面流程重构了，那就应该回到 Planner 阶段，重新调整测试计划，而不是让 Healer 硬修。

否则很容易出现一种危险情况：

用例是跑绿了，但真正的业务问题被“修没了”。

四、怎么初始化 Test Agents？

在项目根目录执行：

npx playwright init-agents

更推荐根据你使用的工具链明确指定：

# VS Code
npx playwright init-agents --loop=vscode

# Claude Code
npx playwright init-agents --loop=claude

# Codex
npx playwright init-agents --loop=codex

# opencode
npx playwright init-agents --loop=opencode

Playwright 官方发布说明里也给出了通过 npx playwright init-agents 为不同 agentic loop 生成最新 Agent 定义文件的方式。([Playwright][2])

这些 Agent 定义文件，可以理解成 Playwright 官方给 AI 准备的“角色说明书”。

它会告诉 AI：

• Planner 应该如何探索页面；
• Generator 应该如何根据计划生成测试；
• Healer 应该如何处理失败用例；
• 测试计划应该放在哪里；
• 测试代码应该放在哪里；
• Agent 之间如何交接上下文。

这里补充一个容易踩坑的点：

Playwright 升级后，建议重新执行 init-agents。

因为 Agent 定义文件不会自动跟着版本升级。如果 Playwright 已经新增了能力，但你本地的 Agent 定义还是旧的，Agent 可能仍然按旧规则执行。

另外，VS Code 使用相关 agentic 能力时，官方文档要求版本在 v1.105 及以上。

五、seed.spec.ts 是成败关键

很多人用 AI 做 UI 自动化失败，不是因为 AI 不会写脚本，而是因为一开始没有给它一个稳定入口。

企业后台系统通常都有一堆前置条件：

• 登录；
• 验证码；
• 权限；
• 租户；
• 菜单；
• 测试账号；
• 初始化数据；
• 前置配置。

如果这些没有处理好，Planner 可能一直停留在登录页，或者生成一堆偏离目标模块的测试计划。

所以在跑 Test Agents 之前，建议先写好 seed.spec.ts。

它不是业务测试用例，而是环境入口。

你可以把它理解成：

告诉 Agent：从哪里开始，以什么身份进入系统，用什么数据做测试。

示例：

import { test, expect } from'./fixtures';

test('seed: 商品管理模块入口', async ({ page }) => {
// 1. 登录后台系统
await page.goto('/admin/login');
await page.getByPlaceholder('请输入账号').fill('test_admin');
await page.getByPlaceholder('请输入密码').fill('123456');
await page.getByRole('button', { name: '登录' }).click();

// 2. 确认进入首页
await expect(page.getByText('首页')).toBeVisible();

// 3. 进入目标模块
await page.getByText('商品管理').click();
await page.getByText('商品列表').click();

// 4. 确认页面到达可测试状态
await expect(page.getByRole('button', { name: '添加商品' })).toBeVisible();
});

这个 seed 不一定要写复杂断言。

它的核心价值是：

• 固定登录方式；
• 固定页面入口；
• 固定测试账号；
• 固定 fixture；
• 固定代码风格；
• 减少 Agent 探索成本。

对测试开发来说，seed.spec.ts 写得稳不稳，往往直接决定后面生成的测试计划和测试代码是否靠谱。

六、推荐的实际工作流

我不建议一上来就让 AI 直接生成完整测试代码。

这套流程里，测试工程师不是被替代了，而是换了一个位置。

以前你主要是在写脚本、调脚本、修脚本。

现在你更像是在管理一条测试生产线：

• 你负责定义测试目标；
• 你负责审核测试计划；
• 你负责判断断言质量；
• 你负责控制哪些用例可以进 CI；
• 你负责判断失败到底是脚本问题，还是产品缺陷。

这才是测试开发真正应该升级的地方。

七、Planner：先规划，再写代码

我个人非常建议先跑 Planner。

原因很简单：

测试计划偏了，改 Markdown 很便宜；测试代码偏了，返工成本就高了。

你可以这样给 Planner 提需求：

基于 tests/seed.spec.ts，
为 CRMEB 商城后台的“添加商品”流程生成测试计划。

要求覆盖：
1. 正常添加商品流程；
2. 必填字段为空的校验；
3. 商品价格、库存等边界值；
4. 图片上传异常；
5. 保存成功后的列表展示；
6. 数据清理或避免污染后续用例。

一个好的测试计划，不应该只是：

点击新增。 填写表单。 点击保存。 校验保存成功。

这太浅了。

真正有价值的测试计划，至少应该包含：

• 场景名称；
• 前置条件；
• 操作步骤；
• 测试数据；
• 预期结果；
• 异常情况；
• 断言点；
• 是否适合自动化；
• 数据清理策略；
• 和 seed 的关系。

如果 Planner 生成的计划只停留在页面点击层面，那就说明还需要继续补充业务规则和测试边界。

测试开发要做的不是盲目接受 AI 生成结果，而是用测试经验去审它。

八、Generator：把测试计划落成可执行代码

当 specs/ 目录下的 Markdown 测试计划经过评审后，再交给 Generator。

可以这样提示：

请基于 specs/product-create.md 生成 Playwright 测试代码。

要求：
1. 使用 tests/seed.spec.ts 中的 fixture 和登录方式；
2. 优先使用 getByRole、getByLabel、getByText 等稳定定位方式；
3. 每个核心业务步骤都要有有效断言；
4. 不要让多个用例依赖同一份脏数据；
5. 生成的测试文件放到 tests/product-create.spec.ts。

这里不要只关心代码能不能跑通。

更要看代码是否符合团队自动化规范：

• locator 是否稳定；
• 是否避免硬编码等待；
• 是否有清晰断言；
• 是否能重复执行；
• 是否方便失败排查；
• 是否和已有 fixture、Page Object、测试数据工厂保持一致；
• 是否会污染环境数据。

AI 可以生成代码，但自动化测试代码能不能长期维护，还是要靠测试开发把关。

九、Healer：适合修执行失败，不适合修需求变化

Healer 很适合处理下面这些问题：

• 按钮文案轻微变化；
• 选择器失效；
• 页面加载慢导致等待不足；
• 测试数据过期；
• 弹窗遮挡；
• 元素位置或层级变化；
• 断言时机不稳定。

可以这样使用：

帮我修复 tests/product-create.spec.ts 中失败的测试。

请先分析失败原因，再尝试修复选择器、等待条件或测试数据。
如果判断是功能缺陷，不要强行修改测试逻辑，请说明原因。

但下面这些问题，不应该交给 Healer 硬修：

• 需求逻辑变了；
• 页面流程重构了；
• 接口字段变了；
• 权限模型调整了；
• 商品创建规则变化了；
• 原来的断言已经不符合业务预期。

这类问题应该回到测试计划层重新修。

否则 Healer 可能会为了让测试通过，把原来有价值的断言删弱。

比如原来是：

await expect(page.getByText('商品创建成功')).toBeVisible();

结果被改成：

await expect(page.locator('body')).toBeVisible();

这类代码虽然可能“跑绿”，但测试价值已经没了。

自动化测试最怕的不是红，而是绿得没有意义。

十、它和 Playwright MCP、CLI怎么区分？

现在很多测试同学会同时接触 Playwright MCP、Playwright CLI、Test Agents，容易混在一起。

可以这样理解：

Playwright 官方介绍 playwright-cli 时，也强调它是面向 coding agents 的命令行浏览器自动化工具，特点是通过简洁 CLI 命令提供更节省 Token 的浏览器控制。([Playwright][3])

所以三者不是互相替代关系。

更合理的组合方式是：

• MCP：用于探索页面、调试单条用例、辅助定位元素；
• CLI：用于低成本命令式浏览器控制，适合工程化和 CI 场景；
• Test Agents：用于一个业务模块从测试计划到可执行回归集的建设。

简单来说：

MCP 更像 AI 的眼睛和手。CLI 更像 AI 的命令行工具箱。Test Agents 更像一套测试建设流程。

十一、从测试开发视角看，它真正补上了什么？

从测试开发角度看，Playwright Test Agents 真正补上的不是代码生成。

代码生成早就有了。

它真正补的是两个东西。

1. 测试计划可审计

以前 AI 直接生成代码，测试工程师经常很难判断它到底理解了什么。

现在中间有 Markdown 测试计划，团队可以先评审测试设计，再决定是否生成代码。

这对企业级测试资产非常重要。

因为自动化测试不是跑一次就完事，而是要长期维护、持续执行、服务版本交付。

2. 失败修复更闭环

以前自动化失败后，很多团队会陷入一个尴尬状态：

失败了没人看； 看了没人修； 修了不敢合； 最后 CI 里长期挂着一堆红色用例。

Healer 至少让执行层面的失败有机会进入一个自动分析和自动修复流程。

但这里一定要加一个前提：

Healer 只能提高维护效率，不能替代失败归因。

失败到底是测试脚本问题、环境问题、数据问题，还是产品缺陷，最后仍然需要测试开发判断。

十二、哪些项目适合先试？

不建议一开始就拿复杂业务全量试。

更推荐从下面这类模块开始：

• 登录；
• 用户管理；
• 商品新增；
• 订单查询；
• 购物车；
• 基础配置；
• 后台列表页；
• 简单审批流；
• 表单新增和编辑流程。

这些模块有几个特点：

• 页面路径清晰；
• 测试数据可控；
• 业务规则相对稳定；
• 正向和异常场景容易拆；
• 适合沉淀成回归用例。

不太建议一开始就拿下面这些场景试：

• 强依赖第三方支付；
• 强依赖短信、邮箱、验证码；
• 页面频繁改版；
• 权限和租户关系复杂；
• 测试数据难清理；
• 业务规则还没定稿；
• 大量图形化、Canvas、复杂拖拽类页面。

这类场景不是不能做，而是不适合作为第一批试点。

十三、团队落地时，建议加上这几条规范

如果团队真的准备尝试 Test Agents，建议提前加几条规范。

否则很容易变成“AI 生成一堆没人维护的测试代码”。

1. specs 和 tests 文件名尽量一一对应

例如：

specs/product-create.md
tests/product-create.spec.ts

这样失败回溯时，能快速知道这条自动化用例对应哪份测试计划。

2. 每个测试计划都要人工评审

不要 Planner 生成完就直接交给 Generator。

至少要看这几个点：

• 场景是否真实；
• 预期是否准确；
• 断言是否有效；
• 数据是否可重复；
• 是否遗漏异常路径；
• 是否适合自动化。

3. Generator 生成的代码不能直接进主干

生成代码后至少做一次 code review。

重点看：

• locator 是否稳定；
• 是否有硬等待；
• 是否有无意义断言；
• 是否复用了团队 fixture；
• 是否存在用例间数据依赖；
• 是否会污染测试环境。

4. Healer 修复后的代码也要 review

Healer 自动修复不代表一定正确。

尤其要警惕一种情况：

它为了让测试通过，把原本有价值的断言删弱了。

一旦断言被弱化，用例虽然变绿，但质量防线也被拆掉了。

5. CI 里不要一上来就高并发

Playwright 本身支持并发执行，但对新生成的 UI 自动化测试来说，不建议一开始就在 CI 中高并发运行。

尤其是后台系统、管理系统、测试数据共享较多的项目，先保证稳定性，再逐步提高并发。

自动化测试的第一目标不是跑得快，而是跑得可信。

十四、测试工程师会被替代吗？

很多测试同学看到 Test Agents，第一反应可能是：

这是不是又要替代测试工程师了？

我反而觉得，它替代的是低质量、重复性的脚本劳动。

但它替代不了测试工程师真正有价值的部分。

比如：

• 业务风险判断；
• 测试策略设计；
• 场景优先级判断；
• 缺陷归因；
• 断言质量评审；
• 数据隔离设计；
• 自动化资产治理；
• CI 准入标准；
• 质量风险沟通。

AI 可以帮你生成测试计划，但计划是否合理，需要人判断。

AI 可以帮你生成测试代码，但代码是否能长期维护，需要人判断。

AI 可以帮你修失败用例，但失败到底是脚本问题还是产品缺陷，仍然需要人判断。

所以测试开发岗位不会因为 Test Agents 消失。

但岗位能力模型会变化。

以后更有价值的测试开发，不只是会写 Playwright，而是能设计一套稳定的测试智能体工作流。

十五、写在最后

UI 自动化这些年一直有个老问题：

脚本越写越多，信心却没有同步变强。

因为很多团队缺的不是工具，而是一套从测试设计、代码生成、失败修复到 CI 准入的完整链路。

Playwright Test Agents 值得关注，正是因为它开始把这条链路拆清楚了：

Planner 负责测试计划。Generator 负责测试代码。Healer 负责失败修复。

但最终能不能落地，还是取决于测试工程师。

你要会写 seed，知道怎么给 Agent 一个稳定入口； 你要会审测试计划，判断场景覆盖是否合理； 你要会看生成代码，判断断言和数据是否可靠； 你还要会分析失败，判断是脚本问题、环境问题，还是产品缺陷。

未来自动化测试不会只是“写脚本”。

它会越来越像一套由 AI Agent 参与的测试工程体系。

会用 Playwright，只是基础能力。

真正拉开差距的是：

你能不能把 AI、测试设计、自动化框架、测试数据、CI 和质量策略，串成一条能在真实项目里跑起来的工程链路。

霍格沃兹测试开发学社，是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区