关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集导读
Playwright MCP 如何让 AI Agent 找到正确的输入框、按钮和复选框？关键是浏览器提供的可访问性快照：它将元素角色、名称、层级关系和引用提供给模型。本文结合 TodoMVC 和可复现的重复元素定位实验，介绍 Playwright MCP 的页面感知机制、动态 DOM 处理、MCP 工具调用，以及如何将 Agent 的探索结果转换为可维护的自动化测试代码。
一、AI Agent 为什么能找到页面上的按钮？
传统 Playwright 自动化测试主要依靠测试工程师编写 Locator，例如 getByRole()、getByLabel() 或 CSS 选择器。
在使用 Playwright MCP 后，AI Agent 可以先观察页面，再根据测试任务选择需要操作的元素。
例如，测试要求是：
“将‘编写测试用例’这条任务标记为已完成。”
如果页面上只有一个复选框，定位非常容易。
但如果有三条任务，每条任务都对应一个名称为 Toggle Todo 的复选框，Agent 就需要确定哪个复选框属于目标任务。
Playwright MCP 默认通过 Accessibility Snapshot（可访问性快照）提供页面结构信息，而不是要求模型通过截图猜测按钮坐标。
快照包含元素角色、可访问名称、层级关系和临时引用。
模型结合业务任务与这些信息选择目标，再调用 Playwright MCP 工具完成操作。
这里的页面语义理解主要发生在模型的目标选择环节，并不意味着 MCP Server 本身能够自动理解所有业务规则。
二、Accessibility Snapshot 如何实现页面语义定位？
页面快照是理解 Playwright MCP 元素定位机制的基础。
2.1 页面快照包含什么信息？
以 TodoMVC 为例，Playwright MCP 返回的结构可以简化为：
- list [ref=e8]:
- listitem [ref=e9]:
- checkbox "Toggle Todo" [ref=e10]
- text: 编写测试用例
- listitem [ref=e13]:
- checkbox "Toggle Todo" [ref=e14]
- text: 执行自动化测试
以上引用编号用于说明结构，实际以当前浏览器快照为准。
从这个快照中，Agent 能够得到四类信息：
例如：
checkbox "Toggle Todo" [ref=e10]
表示当前快照中存在一个复选框，名称为 Toggle Todo，其元素引用为 e10。
当 Agent 确认这个复选框属于“编写测试用例”后，就可以执行：
{
"target": "e10"
}
对应的 MCP 工具为：
browser_click
Playwright MCP Server 根据目标引用执行浏览器操作，再将新的页面状态返回给 Agent。
2.2 ref 和传统 Locator 有什么区别？
这里需要特别注意：
快照中的 ref 不是长期稳定的元素定位器。
传统 Playwright Locator 通常描述一种持续有效的查找规则，例如：
page.getByRole('button', {
name: '提交'
});
而快照中的 ref=e10 指向的是当前页面状态下的某个元素。
页面重新渲染、元素被移除或者结构发生变化后，之前的引用可能失效。
因此：
- ref 适合 Agent 当前的浏览器交互。
- Locator 更适合沉淀为长期维护的自动化脚本。
- 页面变化后，应根据最新页面状态确认引用是否仍然有效。
这也是 Agent 浏览器自动化需要持续接收页面反馈的原因。
三、三个同名复选框，AI 如何准确选择目标？
这是本篇文章最值得深入讨论的一个场景。
假设 TodoMVC 页面已经创建三条任务：
- 编写测试用例
- 执行自动化测试
- 查看测试报告
每条任务都有一个复选框。
这些复选框的可访问名称完全相同：
Toggle Todo
如果只根据控件名称进行定位，就无法区分需要操作哪一个。
3.1 只按元素名称定位，可能发生什么？
假设直接使用：
await page.getByRole('checkbox', {
name: 'Toggle Todo'
}).check();
当页面存在三个匹配元素时，Playwright 的严格模式会抛出多元素匹配错误。
这说明单凭控件角色和名称，无法唯一确定业务目标。
在复杂业务系统中，这种情况非常普遍。
例如一个订单管理页面可能存在几十个“编辑”按钮，每条订单还有“详情”“审核”“删除”等操作。
如果 Agent 只识别按钮文字，就很容易出现目标歧义。
3.2 结合父级业务对象进行定位
更可靠的方式是先找到业务对象，再确定这个对象内部的操作控件。
例如：
const task = page.getByRole('listitem')
.filter({ hasText: '编写测试用例' });
await task.getByRole('checkbox').check();
这段代码包含两个定位步骤。
第一步，查找包含“编写测试用例”的列表项。
第二步，在这个列表项内部查找复选框。
这样就将操作目标限定在正确的业务上下文中。
对于 AI Agent 而言，对应的判断逻辑也是如此：
先理解任务名称，再读取包含该名称的列表节点，最后选择该节点对应的复选框引用。
3.3 实验验证：直接定位与上下文定位
为了验证这个问题，我们构建了一个包含三个同名复选框的本地演示页面，并使用 Chromium 和 Playwright Python 执行测试。
完成操作后，还需要增加断言：
await expect(
task.getByRole('checkbox')
).toBeChecked();
这个断言用于确认目标任务确实进入已完成状态。
本地实验还检查了另外两条任务没有被误操作。
这个案例说明，元素定位不能只解决“找到一个能够点击的元素”，还要解决“找到业务真正要求操作的那个元素”。
对于订单表格、用户列表、审批记录等页面，列表项、表格行、卡片标题和对话框区域，都可以成为重要的上下文线索。
四、动态 DOM 更新后，Agent 如何避免引用失效？
现代 Web 应用通常使用 React、Vue 等框架。
新增任务、切换筛选条件、打开弹窗、翻页等操作，都可能导致页面结构发生变化。
假设 Agent 第一次读取页面时获得：
checkbox "Toggle Todo" [ref=e10]
随后页面执行了新增任务操作，组件发生重新渲染。
如果 Agent 继续使用旧引用：
{
"target": "e10"
}
工具可能提示：
Ref e10 not found in the current page snapshot.
Try capturing new snapshot.
因此，不应该将第一次快照中的元素引用一直沿用到测试结束。
【插入配图 4：动态 DOM 与元素引用更新策略】
4.1 页面变化后重新获取状态
推荐的处理顺序是：
执行页面操作
↓
读取最新页面状态
↓
确认目标元素
↓
获取当前元素引用
↓
执行下一次操作
大多数 Playwright MCP 交互工具会在执行后返回更新的快照，因此无需机械地在每一次工具调用后都额外调用 browser_snapshot。
但遇到导航、复杂重新渲染或目标引用失效时，应重新观察页面。
4.2 使用 browser_find 缩小查找范围
在复杂后台管理系统中，一个页面可能包含大量菜单、表格、按钮和文本。
如果每次都获取完整页面快照，会增加上下文消耗。
Playwright MCP 提供了 browser_find，可以搜索当前页面快照中的目标内容。
例如：
{
"text": "编写测试用例"
}
browser_find 会返回匹配节点及附近的层级上下文。
模型据此可以进一步确定目标控件。
它还支持通过正则表达式查找内容，适合长列表和复杂管理页面。
另外，browser_snapshot 也支持 depth 和 target 参数，可以限制快照深度或只读取指定元素的子树。
这类按需检索策略有助于减少无关页面信息进入模型上下文。
五、页面语义定位与视觉定位，应该怎么选择？
并不是所有 Web 页面都能够通过可访问性快照完整表达。
例如：
- Canvas 绘制的图形界面；
- WebGL 交互页面；
- 没有正确配置 ARIA 属性的自定义控件；
- 需要理解空间布局的图表操作。
对于这些场景，快照提供的语义信息可能不够充分。
Playwright MCP 也支持截图和 Vision 模式。
如果需要坐标交互，可以在 MCP 配置中启用：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest",
"--caps=vision,testing"
]
}
}
}
Vision 模式提供坐标点击、移动和拖拽等工具。
不过坐标定位容易受到屏幕尺寸、页面缩放、滚动位置及布局变化影响。
对于普通 Web 表单，建议优先使用语义快照。
还有一个值得关注的工程问题：页面本身的可访问性设计，会直接影响 AI Agent 获取有效定位线索的能力。
如果页面中的每个按钮都有明确的语义名称，表单字段配置了正确的 Label，业务组件具有清晰的层级结构，Agent 通常更容易识别正确的操作目标。
因此，提高 AI 自动化测试的稳定性，有时需要同时改进前端页面的可访问性设计。
六、实战：使用 Playwright MCP 验证页面语义定位
接下来使用 Playwright 官方提供的 TodoMVC 在线演示应用。
测试地址：
https://demo.playwright.dev/todomvc
沿用第一篇已经配置好的 Playwright MCP 环境，在支持 MCP 的 AI Agent 对话窗口中输入下面的测试任务。
请使用 Playwright MCP 打开 https://demo.playwright.dev/todomvc。测试任务：
- 检查页面初始状态，清理已有待办任务。
- 新增“编写测试用例”“执行自动化测试”“查看测试报告”三条任务。
- 获取当前页面的 Accessibility Snapshot。
- 找到“编写测试用例”对应的列表项。
- 根据列表项层级关系找到对应的复选框。
- 只将“编写测试用例”标记为已完成。
- 验证另外两条任务仍未完成。
- 验证页面显示 2 items left。
执行约束：不要仅凭多个复选框相同的名称选择元素。应结合任务文本、父级列表和当前页面快照确定目标。页面发生变化后，使用最新快照中的元素引用。最终输出工具调用记录、元素定位依据、断言结果和失败信息。如果已启用 --caps=testing，还可以使用测试验证工具检查结果。
例如：
browser_verify_value
验证目标复选框：
{
"type": "checkbox",
"element": "编写测试用例对应的复选框",
"target": "当前快照中的目标ref",
"value": "true"
}
其中 target 必须替换为实际快照中的元素引用。
剩余任务数量可以使用：
{
"text": "2 items left"
}
对应工具：
browser_verify_text_visible
需要注意，剩余数量正确，并不能单独证明指定任务被正确勾选。
还必须确认“编写测试用例”处于已完成状态，其余两条任务保持未完成。
这也是自动化测试区别于简单浏览器操作的地方：操作完成之后，必须验证具体业务结果。
七、如何将 Agent 的探索结果转化为稳定的自动化脚本？
在企业实际应用中，不建议长期依赖模型重复探索同一条固定测试路径。
一种可行的工程方式是将流程分为三个阶段。
探索阶段： Agent 根据测试需求观察页面、定位元素、完成交互并确认操作路径。
脚本沉淀阶段： 将有效的定位逻辑和操作步骤整理为 Playwright 测试代码。
持续回归阶段： 使用传统 Playwright 在 CI/CD 流水线中执行测试，并通过明确断言判断结果。
Playwright MCP 的 Testing 能力还提供 browser_generate_locator，可根据选中的页面元素生成 Playwright Locator。
不过生成的 Locator 仍需要检查唯一性、稳定性及业务语义。
例如，下面的代码可以成为长期回归用例的一部分：
import { test, expect } from'@playwright/test';
test('指定任务完成状态验证', async ({ page }) => {
await page.goto(
'https://demo.playwright.dev/todomvc'
);
const input = page.getByPlaceholder(
'What needs to be done?'
);
for (const name of [
'编写测试用例',
'执行自动化测试',
'查看测试报告'
]) {
await input.fill(name);
await input.press('Enter');
}
const task = page.getByRole('listitem')
.filter({ hasText: '编写测试用例' });
await task.getByRole('checkbox').check();
await expect(
task.getByRole('checkbox')
).toBeChecked();
await expect(
page.locator('.todo-count')
).toContainText('2 items left');
});
这段测试以空白初始页面为前提。实际接入持续集成时，应进一步配置测试数据隔离和初始化逻辑。
通过这种方式，Agent 可以辅助探索页面交互，传统 Playwright 则负责稳定、可重复的回归执行。
八、总结
Playwright MCP 的页面语义定位建立在浏览器可访问性信息之上。
模型根据元素角色、名称、层级关系和当前页面状态选择目标，再通过 MCP 工具执行浏览器操作。
对于测试开发工程师，需要重点掌握三个问题：
第一，重复元素如何消歧？
通过父级业务对象和页面层级关系确定正确的操作目标。
第二，动态 DOM 如何处理？
页面状态变化后，使用最新快照重新确认元素，不应长期复用旧的 ref。
第三，如何保证测试可维护？
将探索过程中形成的定位规则转换为稳定的 Playwright Locator，并通过独立断言验证业务结果。
理解这些机制之后，就可以进一步研究 AI 如何根据自然语言需求自动生成测试用例，以及生成的测试步骤如何转化为可执行的 E2E 测试代码。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
