Playwright MCP：基于 AI Agent 的测试失败诊断与自动修复机制

导读：

Playwright 自动化测试运行失败后，能不能让 AI Agent 自己查日志、定位问题，甚至修改测试脚本？本文结合 Playwright MCP、Trace Viewer 和大模型推理能力，通过一个真实可复现的 Web 自动化测试场景，介绍测试失败诊断、Locator 自动修复、回归验证的实现过程，以及 Self-Healing Testing 在实际项目中的应用边界。

一、自动化测试失败，最头疼的往往是排查

做过 Web 自动化测试的同学，应该都遇到过这种情况。

昨天 CI 流水线还是一片绿色，今天早上打开测试报告，突然有十几条用例失败了。

点开其中一条：

TimeoutError: locator.click: Timeout 30000ms exceeded

Call log:
  - waiting for locator('#submit-btn')

第一反应可能是：按钮怎么找不到了？

打开页面一看，按钮明明就在那儿。检查 DOM 才发现，前端昨天调整了组件结构，原来的 id 没了。

改个 Locator，重新运行，通过。

看起来也就几分钟的事。

可如果每天都有几十条自动化用例失败，情况就不一样了。有人负责看报告，有人负责找日志，有人反复尝试复现。排查一圈下来，发现大部分时间花在了同样的事情上。

更麻烦的是，测试失败不一定是脚本的问题。

比如下面这些情况：

以前这些问题主要靠测试开发工程师自己分析。

现在可以尝试让 AI Agent 先完成一轮排查：把失败日志交给它，再通过 Playwright MCP 查看页面实际状态，确认问题后生成修复建议。

这套思路通常被称为 Self-Healing Testing（自修复测试）。

不过，工程上必须明确一条规则：测试脚本可以修，业务断言不能为了通过测试随意修改。

二、Playwright MCP 怎么参与测试失败诊断？

先看一下整个处理过程。

图 1：基于 Playwright MCP 的测试失败诊断与自动修复架构

这里有三个组件需要分清。

Playwright Test 负责执行测试用例，记录失败信息。

Playwright MCP 负责让 Agent 操作浏览器，查看页面语义快照、控制台日志和网络请求，并验证页面当前的行为。

AI Agent 则根据收集到的证据，判断失败原因。具备代码操作权限时，还可以修改测试文件并调用测试命令进行验证。

微软官方的 Playwright MCP 已经提供 browser_snapshot、browser_find、browser_generate_locator 等工具，能够支持页面元素查找和定位器生成。

需要注意，MCP 并不会自动接管 Playwright Test 的所有失败任务。失败事件触发、Trace 读取、代码补丁和回归执行，需要在 Agent 工作流中另外实现。

三、动手验证：让 Agent 修复一个失效的 Locator

找一个简单的例子。

我们使用 Playwright 官方提供的 TodoMVC 示例网站：

https://demo.playwright.dev/todomvc/

测试目标很简单：在输入框中填写一条待办事项，按回车后检查新增内容是否显示。

1. 先写一条会失败的测试用例

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

test('新增待办事项', async ({ page }) => {
  await page.goto('https://demo.playwright.dev/todomvc/');

  // 故意使用错误的定位器
  const input = page.locator('#new-todo');

  await input.fill('学习 Playwright MCP');
  await input.press('Enter');

  await expect(
    page.getByText('学习 Playwright MCP', {
      exact: true
    })
  ).toBeVisible();
});

这里故意把输入框定位器写成 #new-todo，模拟前端结构发生变化后，旧定位器无法继续使用的情况。

执行：

npx playwright test tests/todo.spec.ts --trace on

测试会在寻找输入框时超时。

日志大致如下：

TimeoutError: locator.fill: Timeout 30000ms exceeded

Call log:
  - waiting for locator('#new-todo')

有经验的测试开发同学看到这里，基本就会怀疑 Locator 失效。

不过，Agent 不能只看一条报错就直接改代码。

页面有没有成功加载？是不是跳转到了别的地址？输入框是否还存在？

这些都需要确认。

2. 配置 Playwright MCP

在支持 MCP 的 Agent 客户端中，可以添加下面的配置：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@latest",
        "--caps=testing"
      ]
    }
  }
}

testing 扩展能力用于生成测试定位器及验证页面元素。不同客户端的配置位置可能不同。

官方工具配置和参数可以参考 Playwright MCP GitHub 仓库。

配置完成后，Agent 就能通过 MCP 工具打开页面并检查元素。

3. Agent 开始排查

给 Agent 的任务很明确：

请分析 todo.spec.ts 的测试失败原因。通过 Playwright MCP 检查当前页面，确认是否存在定位器失效问题。如果能够确认，请给出最小修改方案，保留原始业务断言，并重新执行测试。

接下来，Agent 可以按以下顺序排查。

首先，使用 browser_navigate 打开测试页面。

然后，调用 browser_snapshot 获取页面语义快照。

示例页面的相关信息大致如下：

- heading "todos"
- textbox "What needs to be done?"

页面中确实存在一个输入框，提示文字为 What needs to be done?。

接着，Agent 可以使用 browser_find 缩小搜索范围，再通过 browser_generate_locator 生成候选定位器。

检查之后，可以确认：

• 页面已经正常加载。
• 待办事项输入框存在。
• 原来的 #new-todo 无法匹配该元素。
• 可以通过输入框的 placeholder 定位。

到这里，定位器失效的判断才有了比较充分的依据。

4. 修改代码并验证

原来的代码：

const input = page.locator('#new-todo');

可以修改为：

const input = page.getByPlaceholder(
  'What needs to be done?'
);

修改后的完整测试：

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?'
  );

  await input.fill('学习 Playwright MCP');
  await input.press('Enter');

  await expect(
    page.getByText('学习 Playwright MCP', {
      exact: true
    })
  ).toBeVisible();
});

重新运行：

npx playwright test tests/todo.spec.ts

这次修复只涉及一个 Locator，新增待办事项的测试逻辑和原始断言没有变化。

如果回归通过，Agent 就可以输出代码 Diff 和修复报告，交给开发人员审核。

这个案例是人为构造的可复现示例，用来说明诊断流程；文中的修复结果是预期行为，不是实际运行记录。

还有一个细节值得注意：Agent 生成的定位器也需要验证唯一性和稳定性。

比如页面里有两个相同 placeholder 的输入框，简单替换可能引出新的定位冲突。

Playwright 官方建议优先采用语义定位、标签、占位符或明确的 data-testid 测试契约，避免过度依赖容易变化的 DOM 结构。

四、复杂一点的失败，还得看 Trace 和网络日志

前面的例子很好定位，因为错误直接指向了元素选择器。

实际项目里，很多失败没这么明显。

例如，一条订单提交测试报错：

Expected: "订单提交成功"
Received: "订单提交失败"

此时，页面元素都能找到，点击操作也执行成功了。

问题可能出在后端接口、测试数据、业务规则，或者前端状态更新。

光靠页面快照很难弄清楚。

这时候可以把 Playwright Trace 一起接入诊断流程。

在 playwright.config.ts 中增加：

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['html', { open: 'never' }]],

  use: {
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure'
  }
});

执行失败后，Playwright 会保留相关 Trace 文件。

如果项目启用了重试，retain-on-failure 也会保留失败尝试的 Trace，便于排查偶发问题。

Trace Viewer 可以查看操作时间线、DOM 快照、网络请求及控制台信息。

将这些信息结合起来，Agent 就能进行更细致的排查。

图 2：AI Agent 对测试失败进行分类处理

这里还有一个很常见的坑。

页面加载慢了，Agent 发现超时，然后把代码改成：

await page.waitForTimeout(10000);

看起来修好了，实际上可能只是把问题往后推了 10 秒。

对于页面异步状态，通常更适合使用 Playwright 的自动重试断言：

await expect(
  page.getByText('订单提交成功')
).toBeVisible();

Playwright 会在断言超时前持续检查条件是否成立。

如果根本没有成功提交订单，等待再久也没用。

所以诊断页面超时问题时，要先分清楚：究竟是页面还没准备好，还是业务请求本身失败了。

另外，通过 MCP 新建的浏览器会话，不一定保留原来失败时的登录状态、测试数据和网络条件。历史失败要依靠 Trace 等证据还原；复现结果需要结合环境差异判断。

五、自动修复有条红线：不能随便修改业务断言

这个问题在实际落地时比 Locator 修复更值得关注。

比如测试目标是验证支付成功：

await expect(
  page.getByText('支付成功')
).toBeVisible();

实际页面显示：

支付失败，请稍后重试

Agent 如果把断言修改成检查“支付失败”，测试可能就通过了。

但这条用例原本要验证的支付成功场景，已经失去了意义。

类似的风险还包括删除失败断言、增加 test.skip()、无条件 Mock 成功响应，以及不断增加超时时间。

建议在自动修复系统中设置明确的权限范围。

还有一点，Agent 的每次修复都应该留下记录，包括原始失败、诊断证据、代码差异以及回归结果。

否则过一段时间回头看，很难知道某个定位器为什么被修改过。

六、团队落地时，先做一个轻量版本就够了

已经在使用 Playwright Test 的团队，可以直接利用现有 CI 流水线实现第一版。

大致流程如下：

1. CI 运行失败后收集错误日志、Trace 和截图。
2. 将失败证据与对应测试代码提供给 Agent。
3. Agent 调用 Playwright MCP，检查页面并尝试复现。
4. 确认属于测试代码问题后，生成最小补丁。
5. 在隔离环境中执行回归，并输出诊断报告及代码 Diff。

建议先限定在 Locator 失效场景。原因很简单：诊断证据相对明确，修改范围小，也容易通过回归判断是否有效。

对于代码 Agent，可以使用下面这段任务约束：

你是一名 Playwright 自动化测试故障诊断工程师。

请根据失败日志、Trace 和测试源代码分析问题。

处理要求：

1. 先检查失败证据，必要时通过 MCP 复现。
2. 区分测试脚本、页面状态、环境与业务故障。
3. 只有确认属于测试代码问题，才允许修改。
4. 优先选择语义定位和稳定的测试属性。
5. 禁止删除断言、修改业务预期或跳过测试。
6. 禁止通过盲目增加固定等待掩盖问题。
7. 每次生成尽可能小的代码补丁。
8. 修改后重新执行相关测试。
9. 输出故障原因、修改内容与回归结果。
10. 证据不足时停止修改，提交人工排查。

如果要进一步评估这套方案有没有实际价值，建议重点记录三个数据：故障归因准确率、修复后通过人工审核的比例，以及错误修复率。

尤其要单独统计“Agent 把真实业务缺陷误判成脚本问题”的情况。

这类错误比单纯修复失败更值得警惕。

七、最后聊聊实际应用

Playwright MCP 已经能帮助 Agent 观察页面、查找元素、执行交互和检查浏览器状态。配合 Playwright Trace、代码操作工具与回归测试，一套基础的自动化测试失败诊断流程已经可以搭建起来。

如果团队现在维护着几百条甚至上千条 Web 自动化用例，不妨先从那些每天反复出现的定位器失效问题入手。

让 Agent 先分析失败日志，找到对应元素，生成修复补丁，再由测试开发人员审核。

等这部分稳定后，再逐步引入页面异步问题诊断、网络请求分析和 CI 自动触发。

在这个过程中，测试开发工程师仍然需要负责测试策略、业务预期和质量判断。Agent 能分担的是那些证据明确、可以重复验证的日常排查工作。

衡量这套机制的效果，也很简单：过去需要人工排查半小时的脚本问题，现在能不能通过自动诊断，在几分钟内得到一份可验证的修复方案。

能够持续做到这一点，自动修复机制就有了实际使用价值。