browser-qa

Browser QA — 自动化可视化测试与交互

使用时机

• 将功能部署到staging/preview环境后
• 需要跨页面验证UI行为时
• 发布前——确认布局、表单、交互是否正常工作
• 审查涉及前端代码的PR时
• 可访问性审计和响应式测试

工作原理

使用浏览器自动化MCP（claude-in-chrome、Playwright或Puppeteer）像真实用户一样与在线页面交互。

安全第一——影响范围（默认只读运行）

Browser QA驱动真实的认证和用户旅程，因此请明确处理影响范围。
默认只读：切勿针对生产URL执行变更性旅程（结账、支付、删除、批量更新）——需要明确的主动选择以及staging/preview 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. 测试关键用户旅程（结账、引导、搜索）
   ——默认只读；仅针对staging环境执行变更性旅程
     并需明确主动选择（参见上方“安全第一”）

阶段3：视觉回归

1. 在3个断点（375px、768px、1440px）截取关键页面截图
2. 与已提交的基线截图比较
   ——无基线则报告INCONCLUSIVE，切勿静默通过
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违规：英雄图片缺少替代文本，页脚链接对比度低

### 结论：带修复发布（2个问题，0个阻塞）
# 结论 ∈ 发布 / 带修复发布 / 不发布；若无视觉基线则使用INCONCLUSIVE

集成

适用于任何浏览器MCP：

• mChild__claude-in-chrome__* 工具（推荐——使用您的实际Chrome）
• 通过 mcp__browserbase__* 使用Playwright
• 直接使用Puppeteer脚本

与 /canary-watch 配合用于部署后监控。