如果你写过端到端（E2E）测试，一定对这个场景不陌生：功能改了一个按钮的文案，昨天还是绿色的 CI 今天全线飘红，你花了一上午时间不是在开发新功能，而是在修那些"看起来没坏、其实是选择器坏了"的测试。 Playwright 1.56 带来了一个新东西——**Test Agents**，专门用来解决这个痛点。它内置三个 AI 助手：负责规划的 🎭 **planner**、负责写代码的 🎭 **generator**、负责修复的 🎭 **healer**。三者配合，能把"从零开始写测试"到"测试挂了自动修好"这条链路基本交给 AI 来做。 这篇文章会带你从零上手 Test Agents，包含环境准备、三个 agent 的具体用法、如何让它们自动串联运行，以及一些实际使用中的注意事项。 ## 一、这三个 Agent 分别做什么 | Agent | 输入 | 输出 | 适合用在 | | ----------- | ----------------------------------- | ---------------------------- | ---------------------------- | | 🎭 Planner | 一个能跑起来的 seed 测试 + 你的应用 | Markdown 格式的测试计划 | 新功能测试覆盖、梳理测试场景 | | 🎭 Generator | Planner 生成的 Markdown 计划 | 可执行的 `.spec.ts` 测试文件 | 快速把计划变成代码 | | 🎭 Healer | 一个跑失败的测试 | 修好之后能通过的测试 | UI 改版、选择器失效 | 三者可以单独使用，也可以按顺序串起来，形成"从一句需求到一套能跑的测试"的完整流水线。 ## 二、准备工作 在开始之前，确认几件事： - **Playwright 版本 ≥ 1.56** - 如果你用 **VS Code**，需要 **VS Code v1.105** 及以上版本，agent 体验才能正常工作 - 你需要一个支持 agent 模式的 AI 编码工具，比如 VS Code Copilot Chat、Claude Code 或 OpenCode - 目前 Test Agents 只支持 **JS/TS 的 Playwright Test runner**，Python 版暂时还没有官方支持 ## 三、五分钟完成初始化 ### 1. 安装最新版 Playwright ```bash npm install -D @playwright/test@latest npx playwright install chromium ``` ### 2. 初始化 Agent 定义 根据你用的 AI 工具，选择对应的 `--loop` 参数： ```bash # VS Code（Copilot / Cursor 也适用） npx playwright init-agents --loop=vscode # Claude Code npx playwright init-agents --loop=claude # OpenCode npx playwright init-agents --loop=opencode ``` 执行后会自动生成： - 三个 agent 的定义文件（提示词 + 可用工具），比如 Claude Code 下会放在 `.claude/agents/` 里 - 对应的 MCP 配置文件，用来让 AI 连接到真实浏览器 - 一个空的 seed 测试文件 ⚠️ **提醒**：每次升级 Playwright 之后，建议重新跑一遍 `init-agents`，把新的工具和指令同步进来。 ### 3. 写好 seed 测试 Seed 测试是所有 agent 工作的起点——planner 会先跑这个测试，完成登录之类的初始化，然后才开始探索你的应用。 ```ts // tests/seed.spec.ts import { test } from '@playwright/test'; test('seed', async ({ page }) => { await page.goto('https://your-app.com'); // 如果应用需要登录，把登录流程写在这里 }); ``` ## 四、三个 Agent 怎么用 ### 🎭 Planner：让 AI 帮你梳理测试场景 在你的 AI 工具聊天窗口里，把 seed 测试带入上下文，然后提需求，比如： ``` 请探索一下应用，为登录功能生成一份测试计划， 用 tests/seed.spec.ts 作为起点。 ``` Planner 会真的打开浏览器，像一个 QA 工程师一样点来点去，把正常路径、异常输入、边界情况都摸一遍，最后在 `specs/` 目录下生成一份 Markdown 文档，类似这样： ```markdown # 登录功能测试计划 ## 场景 1：正确账号密码登录 1. 打开登录页 2. 输入正确的用户名和密码 3. 点击登录按钮 预期结果： - 跳转到首页 - 页面显示欢迎语 ## 场景 2：密码错误 ... ``` 这份文档人类能看懂，同时又足够精确，可以直接喂给下一步的 generator。 ### 🎭 Generator：把计划变成能跑的代码 把上一步的 Markdown 文件带入上下文，告诉它： ``` 请根据 specs/login.md 里的测试计划生成 Playwright 测试代码。 ``` Generator 不是照着模板套代码，而是真的打开应用，一边走场景一边在真实 DOM 里验证选择器和断言是否成立，所以生成出来的代码相对稳，不容易是"拍脑袋"写的。输出大概长这样： ```ts // spec: specs/login.md // seed: tests/seed.spec.ts import { test, expect } from '../fixtures'; test.describe('登录功能', () => { test('使用正确的用户名密码登录成功', async ({ page }) => { await page.getByRole('textbox', { name: '用户名' }).fill('testuser'); await page.getByRole('textbox', { name: '密码' }).fill('123456'); await page.getByRole('button', { name: '登录' }).click(); await expect(page.getByText('欢迎回来')).toBeVisible(); }); }); ``` 刚生成的测试有可能跑不过——这很正常，接下来交给 healer 处理。 ### 🎭 Healer：测试挂了，它自己会修 当测试失败时，把失败的测试名交给 healer： ``` 运行 tests/login.spec.ts，如果失败，帮我修复并验证通过。 ``` Healer 会： 1. 重放失败的步骤，检查当时的页面、日志和网络请求 2. 判断是"测试本身写错了"还是"应用真的坏了" 3. 如果是选择器过时、等待时间不够这类"测试问题"，它会更新代码并重新跑，直到通过 4. 如果发现是应用功能真的出了问题，它不会硬修，而是把测试标记为跳过，并提示你这是个真 bug 这一点很关键：healer 不会为了让 CI 变绿而掩盖真实的产品问题。 ## 五、让三步自动串起来，而不用你手动发三次请求 Playwright 本身没有提供一个"一键全自动"的命令，串联三个 agent 靠的是你所用编码工具（Claude Code、Copilot 等）自身的多步自主执行能力。做法是： **把三步写进同一个 prompt**，让 AI 自己依次调用 planner、generator、healer，而不是你分三次手动触发： ``` 请按顺序完成以下工作，中途不要停下来等我确认： 1. 用 planner 探索应用，为登录和结账流程生成测试计划 2. 用 generator 根据计划生成测试代码 3. 运行生成的测试，如果有失败，用 healer 自动修复直到全部通过 4. 最后把生成了哪些文件、修复了什么问题总结给我 ``` **关键是要打开"自动批准"模式**。很多编码工具默认会在每次写文件、执行命令前停下来等你点确认，即使你写了一次性 prompt，它中途还是会一步步问你。想真正做到"发一次消息、跑完整个流程"，需要提前开启对应工具的自动批准/自动接受设置（比如 Claude Code 的 auto-accept edits 模式，或 VS Code Copilot agent 模式里的自动批准选项）。 如果你想要完全无人值守（比如每天定时跑一次 healer，检查有没有因为 UI 改动产生的失败），可以用编码工具的**无交互 CLI 模式**，把同样的 prompt 写进脚本，挂到定时任务或 CI 里执行，而不用打开聊天界面。 ## 六、生成后的项目结构 ``` your-project/ ├── .claude/ # agent 定义（VS Code 下是 .github/） ├── specs/ # AI 生成的 Markdown 测试计划 │ └── login.md ├── tests/ │ ├── seed.spec.ts # 环境初始化用的 seed 测试 │ └── login.spec.ts # AI 生成的测试 ├── playwright.config.ts └── .mcp.json # MCP 服务配置 ``` 这个结构很直白：`specs/` 放人能看懂的计划，`tests/` 放机器能跑的代码，两者一一对应，方便审查和追溯。 ## 七、生成的测试怎么接入 CI Agent 本身是给你在开发阶段交互使用的工具，但它们生成出来的文件就是**标准的 Playwright 测试**，跟平时手写的测试一样接入 CI，不需要额外配置： ```yaml # .github/workflows/playwright.yml name: Playwright Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 18 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test - uses: actions/upload-artifact@v4 if: always() with: name: playwright-report path: playwright-report/ ``` ## 八、几个实际使用中要留心的点 - **生成代码要过一遍眼**：同样的 prompt 跑两次，断言写法、变量命名可能不完全一致，别不加审查就合并。 - **不用每次 PR 都跑一遍完整循环**：一次完整的 plan → generate → heal 会消耗不少 token，成本会累积。比较实际的做法是新功能上线时用 planner + generator 建立覆盖，healer 按周或按需触发，而不是每次提交都跑一遍。 - **healer 修的是"测试"，不是"产品"**：如果是大的界面改版，不只是换了个选择器，healer 修不了测试逻辑，这部分还是需要人工介入重写。 - **敏感信息别写进 seed 测试或计划文件里**：agent 定义和生成文件本质上是会被 AI 读取和处理的文本，账号密码这类敏感信息建议走环境变量。 ## 小结 Playwright Test Agents 把"写测试"这件重复劳动的大头交给了 AI：planner 帮你把测试场景想全，generator 把场景变成能跑的代码，healer 让测试在应用变化后还能自己活下去。它不是让你完全撒手不管——生成的代码依然需要你审查、维护，但对于团队里"需要覆盖的场景太多、人手却不够"的情况，这是一个很实际的效率工具。 如果你还没试过，不妨从一个小功能开始：写一个 seed 测试，让 planner 探索一遍，看看它给你的测试计划靠不靠谱。