Browser QA — 自動化視覺測試與互動
使用時機
- 將功能部署至暫存/預覽環境後
- 需要驗證多個頁面的 UI 行為時
- 在出貨前 — 確認版面、表單、互動確實正常運作
- 審查涉及前端程式碼的 PR 時
- 無障礙性審計與響應式測試
運作方式
使用瀏覽器自動化 MCP（Claude in Chrome、Playwright 或 Puppeteer）像真實使用者一樣與即時頁面互動。
安全第一 — 爆炸半徑（預設唯讀執行）
Browser QA 會驅動真實的驗證流程與使用者旅程，因此必須明確界定爆炸半徑。 預設為唯讀：絕不對正式環境 URL 執行變更性旅程（結帳、付款、刪除、大量更新） — 需要明確選擇加入並使用暫存/預覽 URL。使用預先建立的測試憑證，絕不使用真正的正式環境登入資訊，並在儲存任何螢幕截圖前遮蓋憑證/令牌/PII。
階段 1：煙霧測試
1. 導航至目標 URL
2. 檢查主控台錯誤（過濾雜訊：分析工具、第三方）
3. 確認網路請求中無 4xx/5xx
4. 在桌面與行動裝置視口下截取摺疊區域上方的畫面
5. 檢查 Core Web Vitals：LCP < 2.5s，CLS < 0.1，INP < 200ms
（INP 已於 2024 年 3 月取代 FID；閾值依 web.dev 定義）
階段 2：互動測試
1. 點擊每個導覽連結 — 確認無死連結
2. 使用有效資料提交表單 — 確認成功狀態
3. 使用無效資料提交表單 — 確認錯誤狀態
4. 測試驗證流程：登入 → 受保護頁面 → 登出（僅使用測試憑證，切勿使用正式環境）
5. 測試關鍵使用者旅程（結帳、入門引導、搜尋）
— 預設唯讀；僅在明確選擇加入的情況下，才對暫存環境執行變更性旅程
（請參閱上方「安全第一」）
階段 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，無失敗
- Core Web Vitals：LCP 1.2s ✓，CLS 0.02 ✓，INP 89ms ✓
### 互動
- [✓] 導覽連結：12/12 正常運作
- [✗] 聯絡表單：無效電子郵件缺少錯誤狀態
- [✓] 驗證流程：登入/登出正常運作
### 視覺
- [✗] 英雄區塊在 375px 視口下內容溢出
- [✓] 深色模式：所有頁面一致
### 無障礙性
- 2 項 AA 違規：英雄圖片缺少替代文字、頁尾連結對比度不足
### 裁決：SHIP WITH FIXES（2 個問題，0 個阻擋項）
# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP；若無視覺基準則使用 INCONCLUSIVE
整合
與工作階段可用的瀏覽器工具搭配運作：Claude in Chrome（mcp__claude-in-chrome__*）、Playwright MCP 伺服器，或直接從殼層執行的普通 Playwright 腳本。如果上述皆不可用，請直接說明並提供 Playwright 腳本，而不是猜測結果。
若需可重複的檢查，請將發現轉為 e2e-testing 測試；若需深入的無障礙性檢測，請參閱 accessibility。