Browser QA — 自动化视觉测试与交互
何时使用
- 将功能部署到预发布/预览环境后
- 需要跨页面验证 UI 行为时
- 发货前——确认布局、表单、交互确实正常工作
- 审查涉及前端代码的 PR 时
- 可访问性审计和响应式测试
工作原理
使用浏览器自动化 MCP（Claude in Chrome、Playwright 或 Puppeteer）像真实用户一样与在线页面交互。
安全第一——爆炸半径（默认只读）
Browser QA 驱动真实的认证和用户旅程，因此请明确处理爆炸半径。 默认为 只读：绝不对生产 URL 运行 修改性 旅程（结账、支付、删除、批量更新）——要求显式选择加入 并且 使用预发布/预览 URL。使用预植的 测试凭据，绝不要使用真实的生产登录信息，并在保存任何截图之前 脱敏 凭据/令牌/PII。
阶段 1：烟雾测试
1. 导航到目标 URL
2. 检查控制台错误（过滤噪音：分析、第三方）
3. 确认网络请求中无 4xx/5xx
4. 在桌面端 + 移动端视口下截图首屏内容
5. 检查核心网页指标：LCP < 2.5s, CLS < 0.1, INP < 200ms
（INP 于 2024 年 3 月取代 FID；阈值参考 web.dev）
阶段 2：交互测试
1. 点击每个导航链接——确认无死链接
2. 用有效数据提交表单——确认成功状态
3. 用无效数据提交表单——确认错误状态
4. 测试认证流程：登录 → 受保护页面 → 登出（仅使用测试凭据，绝不使用生产凭据）
5. 测试关键用户旅程（结账、注册、搜索）
——默认只读；仅可对预发布环境并在显式选择加入后执行修改性旅程
（参见上方“安全第一”）
阶段 3：视觉回归
1. 在三个断点（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，无失败
- 核心网页指标：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
集成
与会话中可用的任何浏览器工具配合使用：Claude in Chrome（mcp__claude-in-chrome__*）、Playwright MCP 服务器，或从 shell 运行的普通 Playwright 脚本。如果都没有，则说明情况并提供使用 Playwright 脚本的建议，而不是猜测结果。
如需进行可重复检查，将发现项转换为 e2e-testing 中的测试；如需更深入的可访问性，请参阅 accessibility。