让 AI 接管浏览器自动化测试

让 AI 接管浏览器自动化测试：我开发了 3 个 Skill，覆盖了全量、标准、轻量三种模式

调研了 Chrome DevTools MCP 和 Playwright MCP 之后，我做了个决定：不选边站，而是设计一个三层梯度方案。

一、问题的根源

去年我做 BS 架构系统的自动化测试时，踩了两个大坑：

第一个坑：只能"操作"不能"检查"

用 Playwright MCP 能完美模拟用户点击、输入、导航，但测试通过只是表面现象——后台可能有 5 个 XHR 请求返回了 500，Console 里塞满了 JS 错误，只是前端做了容错没表现出来。这种测试，通过了也不能上线。

第二个坑：只能"检查"不能"操作"

Chrome DevTools MCP 能抓包、能看 Console、能做性能分析，但它无法可靠地驱动用户流程。让它帮你测试登录？它连"找到用户名输入框"这一步都走不顺畅。

更不用说 Token 消耗的问题——两个 MCP 同时跑，一次完整测试吃掉 15,000 个 Token。但有些场景其实就一句话的事："导航到首页，确认页面标题包含 Dashboard"，3,000 Token 就够了。

二、调研过程

我深入研究了两个官方项目：

Chrome DevTools MCP

定位
：给 AI 一双眼睛，看浏览器内部
能力
：网络抓包、Console 日志、性能追踪、DOM 检查、JS 执行
底层
：Chrome DevTools Protocol (CDP)
短板
：无法可靠驱动用户流程

Playwright MCP

定位
：让 AI 像用户一样操作浏览器
能力
：无障碍快照、表单填充、断言验证、多 Tab 管理、状态持久化
底层
：Playwright 自动化引擎
短板
：看不到网络请求和 Console 错误

结论很清晰：两个工具不是竞争关系，而是互补关系。

三、我的方案：三层梯度

既然两个互补，那就都上。但不是所有场景都需要双 MCP 全开，所以我设计了三层：

第一层：全量模式（bs-ai-e2e）

双 MCP 并行，一边操作一边检查。

Playwright MCP 操作          Chrome DevTools MCP 检查─────────────────           ──────────────────────导航 → 点击 → 输入           网络请求是否正常表单填充                     Console 有无错误断言验证                     性能指标是否达标多 Tab 切换                  DOM 状态是否一致

适用场景：复杂业务流程（登录 → 下单 → 支付 → 确认）、需要同时验证功能+性能+网络的全面测试。

第二层：标准模式（bs-ai-standard）

单 Playwright MCP + 能力组扩展。开启 testing、network、storage、forms 四个能力组。

testing
：断言验证
network
：API 检查/Mock
storage
：Auth 状态持久化
forms
：批量表单填充

适用场景：日常功能验证、表单测试、API 集成测试。性价比最高的方案。

第三层：轻量模式（bs-ai-lightweight）

纯 Playwright CLI，不跑 MCP Server。通过 SKILL 文件提供 Prompt 模板，CLI 直接执行。

Token 对比：

双 MCP 全量：~15,000 Token/次
单 MCP 标准：~8,000 Token/次
CLI 轻量：~3,000 Token/次

轻量模式比全量模式省 80% Token。

适用场景：冒烟测试、CI/CD 批量回归、快速验证。

四、实战效果

全量模式：订单流程测试

步骤 1：导航到商品列表  → [操作] 导航到 /products  → [检查] 确认 /api/products 返回 200，耗时 < 500ms步骤 2：选择商品  → [操作] 快照 → 找到商品卡片 → 点击  → [检查] 确认 /api/products/123 返回 200步骤 3：加入购物车  → [操作] 找到"加入购物车"按钮 → 点击  → [检查] 确认 POST /api/cart 返回 200  → [检查] Console 无警告步骤 4：结账  → [操作] 批量填充订单表单 → 提交  → [检查] 确认 POST /api/orders 返回 201  → [检查] 性能追踪：TTI < 3 秒步骤 5：最终验证  → [操作] 断言"Order confirmed"文本出现  → [操作] 生成可复用的 Playwright 测试代码

每一步，操作和检查并行执行，互不阻塞。

标准模式：注册流程 + Auth 复用

第一次测试（完整注册）：  1. 导航到 /register  2. 快照 → 找到表单字段 ref  3. browser_form 批量填充  4. 点击注册 → 断言成功  5. browser_storage_save 保存登录状态后续测试（跳过登录）：  1. browser_storage_restore 恢复状态  2. 直接进入功能页面测试

轻量模式：部署后冒烟测试

目标：部署完成后 5 分钟内验证核心路径CLI 执行：  "导航到 http://app.example.com，确认页面标题包含 'Dashboard'"  → PASS  "导航到 /login，确认登录表单存在"  → PASS  "填写 admin/admin123，点击登录，确认包含 'Welcome'"  → PASS

3 个检查，不到 10,000 Token。

五、本地 Chromium 怎么集成

如果你本地部署了 Chromium，3 个模式都支持直接连接：

1# 1. 启动本地 Chromium（带远程调试端口）
2chromium --remote-debugging-port=9222 --user-data-dir="%TEMP%\chrome-debug"
3
4# 2. 全量模式：Chrome DevTools MCP 连接
5npx chrome-devtools-mcp@latest --remote-debugging-port=9222
6
7# 3. 标准模式：Playwright MCP 自动管理浏览器实例
8npx @playwright/mcp@latest --caps=testing,network,storage,forms
9
10# 4. 轻量模式：Playwright CLI 直接使用
11playwright test--browser=chromium --scenario="..."

六、使用方式

部署到 ~/.claude/skills/ 后，随时通过 / 命令调用：

模式	命令	适用场景
全量	`/bs-ai-e2e`	复杂业务流、性能+功能+网络全面覆盖
标准	`/bs-ai-standard`	日常功能验证、表单测试、API Mock
轻量	`/bs-ai-lightweight`	冒烟测试、CI/CD 批量回归

七、为什么要做 3 个而不是 1 个

有人可能会问：为什么不做一个"大而全"的 skill？

因为不同场景的成本差异太大。

一个订单流程的全面测试，双 MCP 跑下来吃掉 15,000 Token。但如果你只是想确认"部署后首页能不能打开"，为了这一个检查跑双 MCP，就是浪费。

反过来，如果你要排查"为什么用户点击支付按钮后页面卡住了"，用轻量模式只告诉你"按钮没响应"，但 Chrome DevTools MCP 会告诉你"POST /api/payments 返回 503，Console 报了 Unhandled Promise Rejection"。

三个梯度不是冗余，而是按需选择。

八、与传统自动化的区别

维度	传统 Playwright	AI MCP 自动化
元素定位	CSS/XPath 选择器	无障碍快照 → 语义 ref
等待策略	手动写 waitForTimeout	条件等待（自动感知）
失败处理	测试失败 → 人工排查	AI 分析 Console + Network → 自动定位
流程变化	选择器变了 → 全改	AI 通过语义理解 → 自动适配
自愈能力	无	有（选择器变化 → 自动找新元素）

AI 自动化的核心价值不是"代替人点击"，而是理解失败原因并自动修复。

九、开源项目

ChromeDevTools/chrome-devtools-mcp
microsoft/playwright-mcp
Playwright 官方文档

十、后续计划

AI 自愈增强
：选择器变化时自动通过语义理解定位新元素
测试报告自动化
：自动生成功能+性能+网络的标准化测试报告
从需求文档生成测试用例
：PRD → 可执行的 AI 测试用例
性能基准线告警
：每次测试自动对比历史性能数据，发现回归自动告警

如果你也在做 BS 架构的自动化测试，欢迎交流。三个 Skill 的源码已经部署，可以直接拿来用。