Claude + Playwright MCP 实战：让 UI 自动化测试脚本编写效率翻倍

自动化测试脚本写起来不累，累的是手工重复那些“找按钮、等加载、对数据、改选择器”。尤其项目进入稳定迭代期之后，真正的成本不是功能测试本身，而是每次页面一改，测试脚本就跟着碎一地。我身边很多团队早就把主流程测试切到了 Playwright 这类浏览器自动化框架，但脚本本身还是靠人肉维护，一个用例从写到跑通，顺利的话一两个小时，遇到动态元素和登录态，半天就交代了。

最近我一直在用 Claude 配合 Playwright MCP 来加速这个环节。所谓 MCP，简单理解就是把浏览器本身变成一个可供模型直接调用的工具箱，Claude 不再只是“凭空生成一段代码”，而是能实时打开被测页面、观察真实 DOM、点按钮、填表单，最后把整个操作过程沉淀成可以直接放进项目里的自动化测试脚本。这篇就把我在实际项目里怎么配置、怎么描述需求、怎么让生成的脚本少返工的经验完整写出来，踩过的坑也一并交代。

1. 为什么我最后把手写脚本这事交给了 MCP

1.1 手工维护脚本的真正痛点

UI 自动化测试脚本最耗时的从来不是写 Playwright 语法，而是两件事：一是把需求翻译成一连串可操作的浏览器动作，二是处理页面特征不明显时那些不稳定因素。

举个很常见的例子。产品经理给的需求一句话：“登录后进入订单列表，能看到上个月的订单编号。”落到脚本里，你得先确认登录框是 label 关联还是 placeholder 关联，登录按钮是 button 还是 div 伪装的，进入列表后表格是静态渲染还是接口返回来再灌进 DOM。这个过程听起来简单，实际做起来，每个人一天能产出四五个稳定用例已经算快的了，而且写出来的代码带着大量个人习惯，后续别人接手也费劲。

更要命的是维护成本。前端同学只要把某个按钮的 class 重命名，或者把表格列头从中文改成英文 key，脚本第二天就红了。你拿到失败报告，先得花时间判断是功能回归还是脚本定位失效，运气不好还要逐条查 DOM。这些时间累积起来，比最初写脚本的时间还要多。

1.2 没有 MCP 之前和之后的区别

没用 MCP 之前，我也试过直接把需求丢给通用大模型让它生成脚本。模型确实能写出语法正确的 Playwright 代码，但准确率非常看页面结构。它看不到真实页面，只能靠我喂给的 HTML 片段或者凭经验猜测，生成出来的选择器经常是 playwright 里那种长长的div.container > div:nth-child(3) > button，脆弱得离谱，页面稍微调整就完蛋。

有了 MCP 之后，整个工作流变成了“模型 + 真实浏览器”的协作。Claude 通过 MCP 协议调用浏览器里面的一组工具，先把页面加载出来，再读取当前页面可交互元素的快照，然后像真人一样思考下一步该点什么、该填什么。因为它能直接看到页面结构，生成的选择器就不会靠猜，而是基于真实 DOM 去构造，准确率和可维护性完全是两个层级。

这个差异本质上和“看着代码改 bug”与“凭记忆改 bug”的差别是一样的。模型能力再强，看不到现场也只能瞎蒙，而 MCP 把现场信息实时喂给了模型。

1.3 这套方案适合谁

不是所有场景都适合这套组合。我个人的经验是：如果项目里已经有成熟的 Playwright 用例集，只是想在新增用例时提速，那这套方案几乎是降维打击；如果团队正准备从零引入 UI 自动化，也可以用它先快速铺一批主流程用例，再逐步人工优化。反过来，如果被测系统还处于前端结构每天都在调的状态，不管用不用 MCP，脚本维护成本都会很高，这套方案只能帮你缩短“写”的时间，不能帮你解决“页面不稳定”本身。

另外，如果你是那种只想让工具完全替你思考的人，那我建议先打消这个念头。Claude 生成脚本、定位元素、排查报错，但测试策略、断言边界、数据准备这些还得人来定，它更像一个手脚麻利的初级测试开发，不是测试负责人。

2. 开始前需要先搞明白的三件事

2.1 环境要求与工具选型

在配置之前，先把环境理清楚。基础组合是 Claude 客户端加 Playwright MCP 服务端。

Playwright MCP 是官方维护的 MCP 服务，它会把浏览器能力封装成一组可供模型调用的工具，核心能力包括：打开指定 URL、读取页面快照、点击元素、输入文本、选择下拉选项、等待元素出现、执行 JavaScript，以及把当前页面保存为 PDF 或截图。所有这些操作都会转换为结构化结果返回给 Claude，Claude 再根据结果决定下一步动作。

项目里目前最省事的启动方式是通过 npx 直接运行，不需要单独安装仓库，前提是本机有 Node.js 环境，建议版本不低于 20。如果没有 npx 或者网络拉包不方便，也可以把@playwright/mcp安装到项目里，以本地模块方式启动。两种方式最终效果一致，我倾向后者，因为锁版本更容易，团队协作时不会出现某天某个人的 npx 拉到了不兼容的新版本。

浏览器方面，Playwright MCP 自带 Chromium 的下载和管理能力，首次启动会自动拉取浏览器内核。如果团队已经统一在用某个浏览器，也可以配置成使用已有的 Chrome 或 Edge，这样能更好地贴近线上真实环境。

2.2 把 Playwright MCP 接到 Claude 中

我这里以 Claude Desktop 为例，整个配置过程是写一个 JSON 文件，声明要加载哪些 MCP 服务。不同客户端入口可能不同，但核心都是同一段配置。

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

把这段配置放到客户端的 MCP 配置文件里，重启客户端，在工具列表里就能看到 playwright 相关的工具。如果配置不正常，通常会在启动后立刻报错，常见原因两个：npx 不在系统 PATH 里，或者首次下载 Playwright 内核时网络中断。前者需要把 Node.js 的 bin 目录加进 PATH，后者直接重新执行一次启动命令，让它续传即可。

服务启动之后，不需要写任何代码，直接在对话里让 Claude“打开某个网址”，它就会自动调用浏览器工具。第一次跑通这个流程，你基本就能理解 MCP 带来的体验差异：模型不再是纸上谈兵，而是真的把页面打开给你看了。

2.3 让 Claude 能连接浏览器的验证方式

配置完成之后，先不要急着生成完整测试脚本，先做一轮简单的连通性测试。我会让 Claude 打开一个本地静态页面或者任意一个稳定的对外页面，然后要求它描述当前页面结构和主要可交互元素。

如果 Claude 能准确说出页面上有哪些按钮、输入框、导航链接，说明浏览器工具链已经打通。这时候我习惯让它再执行一个小动作，比如点击某个链接，等待页面跳转后再次描述页面状态，确认连续动作没有断。

这一步虽然简单，但能避免后面生成脚本时才暴露“模型根本没连上浏览器”的尴尬。很多时候模型一样会煞有介事地生成貌似合理的代码，但它并没有真正观察页面，全靠训练经验补全，这种脚本看着不错，跑起来全是坑。所以验证连接非常有必要，不要跳过去。

3. 从自然语言到可运行脚本的完整工作流

3.1 把需求描述成“给测试员下任务”的方式

很多人用大模型生成脚本，效果不好，第一个原因就是描述太模糊。你说“帮我测一下登录功能”，模型能给你的只能是一个泛泛而谈的模板，因为它不知道你的登录页面长什么样、登录成功后跳去哪、错误提示文案是什么。

换个思路，你不是在跟模型聊天，而是在给一个不太熟悉项目的测试员下任务。任务描述至少要包含：目标地址、前置条件、要执行的操作序列、每一步的预期结果。举个例子：

“打开 https://example.com/login，在用户名输入框输入 test_user，密码框输入 Test@123，点击登录按钮，等待页面跳转到工作台，验证页面标题包含‘工作台’，然后点击左侧菜单‘订单管理’，等待表格加载完成，读取第一行订单编号。”

这段描述一旦给到 Claude，配合它已经打开的浏览器快照，它能非常准确地把操作映射到具体元素上，并生成可运行的脚本。如果你连页面上有什么都不确定，就让模型先把页面快照展示出来，再基于快照逐步表达你的意图。

3.2 一个典型测试用例的完整对话拆解

我以登录后查订单这个场景为例，讲讲完整对话怎么推进。第一步，我会先让 Claude 打开登录页，并且把页面可交互控件列表给出来。它通常会返回类似“页面上有文本框，标签为用户名；文本框，标签为密码；按钮，文本为登录”这类结构信息，这时候就确认了元素定位依据。

第二步，我直接让它执行操作：“在用户名字段输入 test_user，在密码字段输入 Test@123，然后点击登录按钮。”它会逐项执行，遇到 label 关联不上的情况会自动尝试相邻节点，执行完还会把当前页面结果反馈回来。

第三步，等它确认跳转成功后，我再追加指令：“验证当前页面是否包含标题‘工作台’。如果包含，点击左侧菜单里的‘订单管理’。”到这一步为止，整个过程已经有点像真人在操作了。

最后一步，我跟它说：“把刚才整个过程整理成一个 Playwright 测试脚本，使用 expect 做断言，等待使用自动等待，定位方式优先 getByRole 和 getByLabel。”这时候它会把实际操作过的选择器和动作序列组合成一段标准测试代码。整个过程不需要我手动写一行脚本，但我心里很清楚每一步在做什么。

3.3 脚本生成之后的检查清单

Claude 生成的脚本不是拿来就能直接跑的，至少要做下面几项检查，不然很容易出现误报或者漏报。

第一，断言是否符合业务预期。模型往往只能根据页面表现生成“标题正确”“元素可见”这类基础断言，但业务上你可能更关心接口返回码、数据库状态或者某个数值范围，这些信息是模型在浏览器里看不到的，需要你手动补。第二，数据是否需要隔离。自动化测试通常要在测试环境跑，账号密码、订单号这些数据如果写死了，哪天数据清理就得改脚本，建议把数据抽到变量或者配置里。第三，选择器是否聚焦。如果生成出来的选择器特别长，考虑改成带>