Claude 如何透過 Playwright MCP 在 10 分鐘內生成可執行的 E2E 測試

2026-10-29 9

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文介绍如何用Playwright MCP让Claude“先看页面再写代码”，解决AI凭空猜测导致E2E测试失败的痛点。通过“侦察→生成→执行→修正”闭环，10分钟即可从零产出可运行测试，大幅提升自动化测试效率与可靠性。

让 Claude 帮你点浏览器：10 分钟从零生成一套可运行的 E2E 测试

上个月，一个测试同学跑来找我，表情有点复杂。

“哥，我让 AI 写 E2E 测试，前十分钟很爽。它一口气生成了两百行，结构清晰，注释完整。然后我跑了一下，报错。改完一个，又冒出来两个。修到第三个小时，我把自己写脚本的时间算了一下——从零手写也就四十分钟。”

我问他：“你生成之前，让 AI 看过页面长什么样吗？”

他愣了一下：“没有。我就说‘帮我写一个登录的 E2E 测试’。”

这就是问题所在。AI 不是在“写错的代码”，它是在“写它想象中的代码” 。它没见过你的页面，不知道按钮叫什么名字、class 是稳定的还是哈希的、登录后是跳转还是弹 Toast。它只能按训练数据里最常见的写法给你猜一段。

Playwright MCP 解决的就是这个“想象”问题。它让 Claude 先“看”一眼页面，再“写”操作。不是让 AI 猜页面，是让 AI 操作浏览器、读取真实的页面结构，基于它实际看到的东西来生成脚本。

10 分钟，从零到一套能跑的 E2E 测试，靠的就是这个顺序。
核心思路：先侦察，再执行
Anthropic 在 Playwright MCP 里做了一个很关键的设计，叫 Reconnaissance-Then-Action——翻译成人话就是：别着急点，先看看页面到底长什么样。

传统方式是：你理解页面 → 找元素 → 写 Playwright 代码 → 机器执行。

MCP 方式是：你给目标 → Claude 操作浏览器 → Claude 读取页面快照 → Claude 基于快照生成代码 → 执行 → 失败就重新看页面、修脚本。

这个顺序一换，AI 就从“猜页面”变成了“看页面”。它写出来的定位器，是它实际在页面上见到的元素，不是你描述里“应该存在”的元素。

10 分钟四步走：从零到第一个可运行的 E2E
第 1 分钟：装 Playwright MCP
前置条件只有一个：Node.js 18+。

打开终端，在项目目录下执行一条命令：

claude mcp add playwright npx @playwright/mcp@latest
这条命令会在当前项目注册 Playwright MCP，Claude Code 重启后就能识别。也可以手动在项目根目录创建 .mcp.json：

{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
}
}
}
重启 Claude Code，在对话里输入 /mcp，确认 playwright 状态是 connected。

第 2 分钟：告诉 Claude 你的项目约束
这一步很多人会跳过，但它决定了生成代码的“风格”对不对。

在项目根目录放一个 CLAUDE.md，写清楚基本约束：

项目信息

前端：React + TypeScript
测试框架：Playwright
Base URL：http://localhost:3000

测试规范

使用 Page Object 模式
优先使用 getByRole 和 getByTestId
禁止使用 waitForTimeout
断言必须包含页面可见性和业务状态
为什么放在这里而不是每次都跟 AI 说？因为 Claude Code 每次进入项目会自动读取 CLAUDE.md。你写一次，它每次都按这个规范生成。

第 3-8 分钟：让 Claude 边看边写
现在给 Claude 一个具体的、有步骤的目标，而不是一句“帮我写登录测试”。

在 Claude Code 里输入：

打开 http://localhost:3000/login，先 snapshot 看看页面上有什么。
然后基于你看到的元素，生成一个 Playwright E2E 测试：

输入正确的邮箱和密码
点击登录
验证跳转到 /dashboard，且页面上出现 "Welcome"
再生成一个异常用例：密码错误时，应该看到错误提示
关键就在第一句“先 snapshot 看看页面上有什么” 。Playwright MCP 的 browser_snapshot 会返回当前页面的可访问性快照——不是截图，是结构化的文本，包含每个可交互元素的角色、名称和引用标识。Claude 拿到这份快照，就知道“页面上有一个 textbox，名字叫 Email，ref 是 e5”，而不是猜“这里应该有一个 input”。

Claude 会依次做这几件事：

打开浏览器（browser_navigate），获取快照（browser_snapshot），基于快照中的元素生成 Playwright 代码，执行代码，如果失败，重新快照、修定位器、再试。

你会在终端里看到它在“点”浏览器，每一步都有记录。

第 9-10 分钟：Review 生成的代码
Claude 生成完 .spec.ts 文件后，你只需要检查三件事：

定位器稳不稳。如果它用了 CSS class 或 XPath，改成 getByRole 或 getByTestId。Playwright MCP 的快照里本来就有可访问角色和名称，用 getByRole 不需要额外工作，而且 class 重构不会让它碎。

有没有 waitForTimeout。有就删掉，换成 Playwright 的自动等待或 web-first 断言。

断言够不够。只断言“元素可见”不够。至少要加一层业务状态校验——登录成功不只是页面显示了“Welcome”，可能还要看 cookie 或接口响应。

这三项检查，两分钟够用。

两个真实的生成示例
示例一：TodoMVC——5 分钟生成可运行测试
社区里有一个公开的 Playwright MCP 实测案例，用 TodoMVC 演示了完整的生成流程。Claude 通过 MCP 打开页面、获取快照，识别出 textbox “What needs to be done?” 和 checkbox “Toggle Todo”，然后基于这些元素生成了下面这段代码：

import { test, expect } from'@playwright/test';

test('add and complete a todo', async ({ page }) => {
await page.goto('https://demo.playwright.dev/todomvc');
await page.getByRole('textbox', { name: 'What needs to be done?' }).fill('Buy groceries');
await page.keyboard.press('Enter');
await expect(page.getByText('Buy groceries')).toBeVisible();
await page.getByRole('checkbox', { name: 'Toggle Todo' }).check();
await expect(page.getByText('1 item left')).toBeVisible();
});
这段代码第一次跑就通过了。因为定位器不是猜的，是 Claude 在快照里实际看到的。getByRole 和 getByText 都是基于快照中的可访问信息生成的，class 怎么变都不影响。

示例二：TestDino Demo Store——完整的购买旅程
有一个开源项目 pw-agent 用 Playwright MCP 让 Claude 自动探索一个电商演示站，生成从注册到下单的完整 E2E 测试。Claude 通过 MCP 操作浏览器，发现了真实的 data-testid 属性，生成了 complete-purchase.spec.ts，覆盖 11 个步骤：打开首页 → 注册 → 登录 → 浏览商品 → 加购 → 结算 → 填写地址 → 支付 → 验证订单 API。

这个项目的生成方式有一个值得参考的细节：它先让 Claude 用 MCP 探索，产出一份 Markdown 测试计划，再基于计划生成代码。计划里写清楚了每个步骤和对应的选择器，代码只是把计划翻译成可执行的 spec。计划和代码分离，出了问题能定位是“计划漏了”还是“代码写错了” 。

避坑指南
坑一：跳过快照直接生成。这是最大的坑。AI 不先看页面，就是在猜选择器。快照是 MCP 工作流的地基，不是可选项。

坑二：一次跑太多场景。一上来就让 Claude 生成“完整的购买流程”，它会在长链路里丢失上下文。一个场景一个场景跑，跑通一个再跑下一个，短循环比长循环稳定得多。

坑三：只让 AI 写，不 Review。 AI 生成的代码是初稿。定位器、等待策略、断言深度，每一项都需要人检查。MCP 让生成变快了，但没有让 Review 变得不必要。

坑四：以为“能生成”就等于“能进 CI”。本地跑通的 spec，进 CI 之前还要确认：测试是否独立、有没有依赖前一条用例的登录态、超时配置是否合理。生成是第一步，工程化是第二步。

坑五：CI 里忘了 --headless。本地开发用带界面模式没问题，CI 的 Linux runner 没有显示器。在 MCP 启动参数里加 --headless，或者用环境变量 PLAYWRIGHT_MCP_HEADLESS=true。

最后
回到开头那个问题：为什么他修了三个小时？

因为他让 AI 在“没有看过页面”的情况下写代码。 AI 写的每一行，都建立在一个它自己想象出来的页面上。他修的那三个小时，本质上是在逐个纠正 AI 的“想象”和真实页面之间的差距。

Playwright MCP 做的事情，是把“想象”变成“看见”。Claude 先操作浏览器、读取真实快照，再基于快照生成代码。你不需要写一行 Playwright 代码，也不需要告诉它按钮的 class 叫什么——它自己看。

10 分钟四步：装 MCP、写约束、让它边看边写、Review 三件事。

下次你面对一个页面要写 E2E 测试的时候，别打开编辑器了。打开 Claude Code，说一句：

“先 snapshot 看看页面上有什么，然后帮我生成登录的 E2E 测试。”

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。