Browser QA — 自动化视觉测试与交互验证
何时使用
- 将功能部署到预发布/预览环境后
- 需要跨页面验证 UI 行为时
- 上线前——确认布局、表单、交互实际可用
- 审查涉及前端代码的 PR 时
- 可访问性审计与响应式测试
工作原理
使用浏览器自动化 MCP（claude-in-chrome、Playwright 或 Puppeteer）像真实用户一样与在线页面交互。
安全第一——爆炸半径（默认以只读模式运行）
Browser QA 驱动真实的认证和用户旅程，因此需明确对待爆炸半径。 默认为只读：绝对不要在正式环境 URL 上运行变更性旅程（下单、支付、删除、批量更新）——必须明确选择并且使用预发布/预览 URL。使用种子化的测试凭据，切勿使用真实的生产登录凭据，并在保存任何截图前脱敏凭据/令牌/PII。
阶段 1：冒烟测试
1. 导航到目标 URL
2. 检查控制台错误（过滤噪音：分析工具、第三方）
3. 确认网络请求中无 4xx/5xx
4. 在桌面端和移动端视口截取首屏截图
5. 检查核心 Web 指标：LCP < 2.5s，CLS < 0.1，INP < 200ms
（INP 于 2024 年 3 月取代 FID；阈值依据 web.dev）
阶段 2：交互测试
1. 点击每个导航链接——确认没有死链接
2. 用有效数据提交表单——确认成功状态
3. 用无效数据提交表单——确认错误状态
4. 测试认证流程：登录 → 受保护页面 → 退出（仅使用测试凭据，绝不使用生产凭据）
5. 测试关键用户旅程（下单、引导流程、搜索）
——默认只读；仅对预发布 URL 执行变更性旅程
且需明确选择（见上文“安全第一”）
阶段 3：视觉回归
1. 在 3 个断点（375px、768px、1440px）截取关键页面截图
2. 与已提交的基线截图进行比较
——无基线则报告 INCONCLUSIVE，绝不静默 PASS
3. 标记超过 5px 的布局偏移、缺失元素、溢出
4. 如有深色模式则检查
阶段 4：可访问性
1. 在每个页面上运行 axe-core 或等效工具
2. 标记 WCAG 2.2 AA 违规项（对比度、标签、焦点顺序）
3. 确认键盘导航完整可用
4. 检查屏幕阅读器地标
注意：axe-core 自动覆盖大约 30–40% 的 WCAG。通过自动化检查是必要但不充分的——键盘导航、焦点顺序以及屏幕阅读器测试仍需手动检查。不要仅凭自动化通过就报告“可访问”。
输出格式
## QA 报告 —— [URL] —— [时间戳]
### 冒烟测试
- 控制台错误：0 个严重，2 个警告（分析工具噪音）
- 网络：全部 200/304，无失败
- 核心 Web 指标：LCP 1.2s ✓，CLS 0.02 ✓，INP 89ms ✓
### 交互测试
- [✓] 导航链接：12/12 正常
- [✗] 联系表单：无效邮箱缺失错误状态
- [✓] 认证流程：登录/退出正常
### 视觉
- [✗] 英雄区域在 375px 视口溢出
- [✓] 深色模式：所有页面一致
### 可访问性
- 2 个 AA 违规：英雄图片缺少替代文本，页脚链接对比度低
### 判定：SHIP WITH FIXES（2 个问题，0 个阻塞项）
# 判定 ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP；若无视觉基线则使用 INCONCLUSIVE
集成
适用于任何浏览器 MCP：
mChild__claude-in-chrome__*工具（推荐——使用你的实际 Chrome）- 通过
mcp__browserbase__*使用 Playwright - 直接使用 Puppeteer 脚本
与 /canary-watch 配合使用可实现部署后监控。