Playwright MCP：让 UI 冒烟测试从“手点一遍”变成可复查的 Agent 工作流

这篇不是讲“AI 自动替你完成全部 UI 测试”。更现实的用法是：当 QA 今天要验证一个登录、下单、支付、配置保存这类主流程时，让 AI 通过 Playwright MCP 先把页面结构读出来，再执行点击、输入、截图和证据保存，最后由 QA 审查哪些动作值得沉淀成冒烟脚本。

适合的 QA 工作类型：UI 测试、Web/H5 冒烟、选择器稳定性检查、失败截图归因。

AI 直接参与的动作：把自然语言验证目标拆成页面操作步骤，基于页面可访问树选择元素，输出脚本草稿和失败证据清单。

官方资料里，Playwright MCP 被定义为通过 Model Context Protocol 提供浏览器自动化能力，让 LLM 使用结构化 accessibility snapshots 与页面交互，而不是依赖截图或视觉模型。安装入口也很轻，标准配置就是用 npx @playwright/mcp@latest 启动。

真实场景：提测前，QA 只是想快速跑一条主流程

常见情况是这样的：

产品说“配置页改了一个保存逻辑，不影响其他页面”。研发说“接口没动”。但 QA 不能只看一句话就放过，至少要点一遍：进入页面、切换开关、填输入框、保存、刷新确认状态还在，再看接口有没有 4xx/5xx。

原来的做法很机械：

1. 手动打开环境。
2. 找测试账号和测试数据。
3. 一步步点页面。
4. 失败时截图、开 DevTools、看 Network。
5. 如果要沉淀自动化，再回头写 Playwright 脚本。
6. 选择器不稳定时继续调 locator 和等待策略。

Playwright MCP 的价值不在于“神奇”，而在于它把第 3、4、5 步压到同一个可复查流程里。

原始做法 vs Agent 介入后的做法

原始做法里，QA 的脑子一直在做上下文切换：一会儿看需求，一会儿点页面，一会儿看接口，一会儿写脚本。真正有价值的是判断“这个断言是不是业务关键点”，但大量时间花在找元素、补等待、截图留证据上。

Agent 介入后，可以把任务拆成五段：

1. QA 输入验证目标，例如“用测试账号登录后台，把折扣开关打开，保存后刷新页面，确认开关仍为开启”。
2. AI 先请求页面快照，读取按钮、输入框、标题和可访问名称。
3. AI 通过 MCP 工具执行导航、点击、输入、截图。
4. 失败时保存截图、Network 线索、当前页面结构。
5. QA 审查脚本草稿，把真正稳定的步骤合入冒烟集。

这里最关键的是“先 observe，再 act”。如果 AI 不先读取页面结构，直接靠猜 CSS selector，最后很容易生成一堆只能在当前机器跑通的脆弱脚本。

最小验证路径：10-30 分钟可以这样试

不用先搭平台。找一个内部测试环境或者公开 demo 页，做一条最小链路即可。

准备条件：Node.js 18+，一个支持 MCP 的客户端，例如 VS Code、Cursor、Claude Code、Codex 或类似客户端。

MCP 配置可以从官方示例改起：

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

然后给 AI 一个非常窄的任务：

打开测试环境的登录页，用测试账号登录，进入设置页，把“消息提醒”打开，点击保存。执行过程中每一步先说明你看到了哪些可交互元素，失败时截图并输出可复现步骤。

第一次不要要求它直接写完整自动化工程。先看三件事：

1. 它能不能通过可访问树识别出正确元素。
2. 它失败时能不能留下足够证据，而不是只说“操作失败”。
3. 它输出的步骤能不能被 QA 改成可维护脚本。

提效点拆解：它具体少了哪些动作

第一，少反复找元素。

页面上按钮文案、输入框 label、role 信息都能进入结构化快照，AI 可以先基于这些信息做定位建议。QA 不再每次从 DevTools 里复制一段很长的 CSS selector。

第二，少漏证据。

一次失败如果只有一句“保存失败”，研发通常还要追问：哪个环境、哪个账号、页面是什么状态、接口返回什么。Agent 工作流应该强制保留页面状态、截图、关键请求和执行步骤。

第三，少从零写冒烟脚本。

AI 生成的脚本不能直接无脑合并，但它能提供一个草稿：导航、locator、断言、截图位置。QA 的工作从“从零写”变成“审查和加固”。

第四，少把一次性手工验证遗忘掉。

很多线上问题不是没人测过，而是测过以后没有沉淀。用 MCP 跑过的主路径，如果证据和脚本草稿被保留下来，下一次就能变成回归资产。

QA 必须人工校对什么

第一，断言是否有业务意义。

“页面出现保存成功”不一定代表数据真的保存。该看接口、数据库还是刷新后状态，要由 QA 决定。

第二，选择器是否稳定。

如果 AI 选的是临时文案、动态 DOM、列表第一个元素，后续一定会脆。QA 要把它改成更稳定的 role、label、test id 或业务唯一值。

第三，等待策略是否掩盖问题。

把 timeout 调到很长不是解决 flaky。真正要判断的是接口慢、前端状态没更新、还是环境数据脏。

第四，测试数据是否可回滚。

能让 Agent 点页面，不代表可以让它随便改共享环境。账号、订单、开关、余额这类数据要有隔离或回收策略。

和 Stagehand 这类 AI 浏览器自动化工具怎么区分

Stagehand 的官方定位是把 AI-powered actions 和 deterministic code 混合使用，并提供 Act、Extract、Observe、Agent 这些原语。它更像“用自然语言和代码写浏览器自动化”。

Playwright MCP 更适合已经在使用 MCP 客户端的 QA/测开：让现有 AI 助手拿到浏览器操作能力，把探索过程、截图证据和脚本草稿串起来。

我的建议是：

1. 如果你已有 Playwright 体系，先试 Playwright MCP。
2. 如果你正在做更开放的网页自动化任务，再评估 Stagehand。
3. 如果只是简单回归，不要为了 AI 把稳定脚本改成黑盒自然语言流程。

风险边界

Playwright MCP 不能替代 UI 测试策略。它解决的是“更快执行、记录和沉淀一条路径”，不是自动判断哪些路径最重要。

它也不适合一上来就跑完整回归。更合理的落地顺序是：先选 1 条高频主流程，跑通后沉淀脚本，再扩展到 3-5 条冒烟链路。

总结

Playwright MCP 对 QA 的实际价值，不是让测试岗位消失，而是把手工冒烟里最重复的部分变成可复查的 Agent 流程。

最值得落地的场景是：Web/H5 主流程冒烟、失败截图归因、选择器草稿生成、手工路径转自动化脚本。

不建议把它包装成“AI 全自动测试平台”。从一条主流程开始，能复跑、能留证据、能被 QA 审查，才是它真正有用的地方。

官方资料

• Playwright MCP 官方文档
• Stagehand 官方文档