UI 自動化測試 - 使用 Playwright x AI Agent 系列 #01
Codex、GitHub Copilot、Claude Code 等 AI Agent 已能快速修改功能、調整畫面與重構程式碼。開發流程面對的新問題，已不只是「AI 能不能寫出程式碼」，而是：
AI Agent 修改系統功能後，如何證明使用者原本可以完成的操作流程仍然正確？
在以 Web 為操作界面的應用系統中，最容易受到變更影響的往往不是單一函式，而是跨越畫面元件、API、資料狀態與操作順序的完整流程。例如登入、搜尋、表單送出、購物車金額計算與錯誤訊息顯示，都可能在局部程式修改後出現連鎖影響。
單元測試可以確認某個函式、服務或資料處理邏輯是否正確，但無法完整代表使用者在瀏覽器中的實際操作結果。
因此，當系統開始頻繁透過 AI Agent 修改功能、調整畫面或重構流程時，就需要一套可重複執行、可留下證據、可回饋修正的 UI 驗證機制。
為什麼 Agent 協作需要可重複執行的 UI 驗證
傳統開發中，開發者完成小幅修改後，常直接開啟瀏覽器操作幾次，確認畫面看起來正常。當變更頻率低、修改範圍小，而且開發者熟悉系統脈絡時，這種方式勉強可以運作。
但在 AI Agent 協作情境中，這種方式會快速失效，原因包括：
- Agent 可以快速修改多個檔案，但不一定理解完整使用者流程。
- Agent 可能修好局部程式碼，卻破壞另一個畫面操作。
- Agent 可能依據錯誤假設修改 selector、欄位名稱或狀態處理。
- 人工檢查不容易持續重複，也不容易提供精準失敗證據。
- 若沒有可執行驗收條件，Agent 任務完成與否會變成主觀判斷。
因此，AI Agent 協作開發需要一個可重複執行的驗證機制，用來回答最基本的問題：
Agent 修改後，使用者原本應該能完成的主要操作流程，是否仍然可以完成？
UI Automation、E2E Testing 與 Smoke Test
UI 自動化測試常與 E2E Testing、Smoke Test 混用，但三者的定位並不相同。
| 名稱 | 核心定位 | 實務用途 |
|---|---|---|
| UI Automation | 以程式撰寫腳本自動操作瀏覽器畫面 | 將登入、輸入、點擊與導頁等操作轉為可重複執行的腳本 |
| E2E Testing | 驗證跨越前端、API、後端與資料狀態的完整流程 | 確認使用者從操作起點到結果呈現的流程仍然成立 |
| Smoke Test | 以最小測試集合快速確認主要功能可用 | 作為功能修改後的基本驗收與回歸檢查 |
UI Automation：讓界面操作流程可以被重複執行
UI Automation 的核心，是將原本需要人工操作的畫面流程，轉換為可由程式重複執行的操作步驟。例如，一段人工登入流程可以描述為：
開啟登入頁
→ 輸入帳號與密碼
→ 點擊登入
→ 確認進入主畫面轉為 UI Automation 後，這段流程可以固定使用相同的步驟與測試資料執行，並納入版本控管。其價值不只是節省點擊時間，而是讓操作方式與驗證結果具備一致性。
E2E Testing：確認跨層流程仍然成立
以購物系統的「加入購物車」為例，實際流程可能跨越：
商品列表
→ 商品資料載入
→ 加入購物車
→ 購物車狀態更新
→ 數量與金額重新計算即使 API 測試已通過，畫面仍可能因欄位名稱、事件處理、狀態同步或 UI 重構而無法完成操作。E2E Testing 關注的正是這種從使用者畫面出發、跨越多個系統層次的完整結果。
Smoke Test：先驗證最小但關鍵的流程
Smoke Test 不是完整測試策略，也不追求一次覆蓋所有分支與邊界條件。它以最低成本確認系統是否仍具備基本可用性。
Smoke Test 的設計原則如下：
- 測試數量不追求多，先覆蓋核心流程。
- 測試案例需能快速執行。
- 測試結果需能清楚指出失敗位置。
- 測試證據需能回饋給 Agent 作為修正依據。
- 測試腳本需能隨課程案例逐步調整，而不是一次設計到完整測試平台。
對 AI Agent 協作開發而言，Smoke Test 特別重要。原因是 Agent 修改通常速度很快，但每次修改後都需要有一個低成本、可重複的方式確認主要流程是否被破壞。
Playwright 在驗證閉環中的三種角色
Playwright 不只是瀏覽器操作工具。在 AI Agent 協作流程中，它可以同時扮演驗證層、測試證據（Evidence） 來源與完成條件三種角色。
1. 驗證層：確認主要流程仍可操作
Playwright 測試腳本可以模擬實際使用者操作瀏覽器，例如：
登入
→ 搜尋資料
→ 開啟明細
→ 修改狀態
→ 送出流程
→ 驗證完成結果這類驗證可以補足單元測試與 API 測試無法直接覆蓋的部分，特別是 UI 元件互動、畫面狀態變更與使用者可見結果。
2. Evidence 來源：提供失敗診斷依據
測試失敗時，只知道 failed 並不足以修正問題。開發者與 Agent 還需要知道失敗步驟、當時畫面、實際 DOM 狀態，以及前後操作是否符合預期。
Playwright 可提供下列 Evidence（測試證據）：
- Screenshot：保留失敗當下的畫面狀態。
- Trace：記錄操作步驟、Locator、DOM Snapshot、Console 與 Network 資訊。
- Video：觀察整段測試的畫面變化與卡住位置。
- HTML Report：彙整測試結果、錯誤訊息、執行時間與附件。
這些輸出可以作為 AI Agent 修正時的依據，而不是只提供一段模糊的自然語言描述。
3. Done Definition：讓 Agent 任務具備可驗收標準
Agent 回報「已完成修改」不應被視為任務已完成。更合理的方式，是將測試通過作為完成定義的一部分，例如：
完成條件：
- 已依需求修改登入錯誤提示。
- 已更新相關 UI Smoke Test。
- `npx playwright test` 執行通過。
- 若測試失敗，需提供 Trace、錯誤摘要與修正說明。如此可將 Agent 的工作成果從「產出程式碼」提升為「產出可驗證的變更」。
為何採用 Playwright？
Selenium 長期被廣泛應用於企業瀏覽器自動化驗證，適合已有多語言測試框架、跨平台基礎建設與大量既有案例的團隊。採用 Playwright 並不表示 Selenium 已失去價值。
在 AI Agent 協作開發情境中，Playwright 的主要優勢，是較容易建立快速驗證閉環：內建 Auto-waiting 與 Actionability Checks，並整合 Trace、Screenshot、Video 與 HTML Report 等診斷能力。對需要小步修改、立即驗證、快速回饋的現代 Web 專案而言，導入阻力通常較低。
真正的判斷標準不是哪一套工具較新，而是哪一套工具較符合現有團隊、系統與驗證流程。
測試腳本就是可執行的驗收規格
傳統驗收條件常以文字描述：
- 使用者登入後應能看到商品列表。
- 使用者可以搜尋商品。
- 使用者可以將商品加入購物車。
這些敘述適合需求討論，但無法自動判斷修改後的系統是否仍符合要求。當它們被轉換為 Playwright 測試腳本後，便成為可執行的驗收規格。
| 驗收描述 | 可執行驗證方式 |
|---|---|
| 使用者可以登入 | 操作登入表單，驗證導頁與登入後畫面 |
| 使用者可以搜尋 | 輸入關鍵字，驗證列表內容變化 |
| 使用者可以加入購物車 | 點擊加入按鈕，驗證商品與數量 |
| 使用者可以修改數量 | 操作數量欄位，驗證小計與總額 |
| 使用者可以完成結帳 | 執行結帳流程，驗證完成訊息與訂單結果 |
重點不是將所有需求全部轉為 E2E 測試，而是優先保護最能代表系統可用性的主流程。當關鍵流程具有固定測試資料、操作步驟與預期結果後，Agent 的修改便有明確的安全邊界。
建立最小可行的驗證閉環
可將 AI Agent 與 Playwright 的協作流程整理為：
需求或修改任務
→ Agent 修改系統
→ Playwright 執行 UI Smoke Test
→ 產出測試結果與 Evidence
→ 判斷失敗原因
→ 回饋 Agent 修正
→ 再次執行測試落地時可依下列順序進行：
- Step 1：定義最重要的使用者流程
- Step 2：建立一條最小 UI Smoke Test
- Step 3：使用固定測試資料執行驗證
- Step 4：保存錯誤訊息與 Evidence
- Step 5：分類產品、測試、資料或環境問題
- Step 6：將明確診斷結果回饋 Agent
- Step 7：重新執行測試確認修正結果
測試腳本在這個流程中成為開發者、Agent 與團隊之間的共同語言：
- 對開發者而言，測試腳本定義了變更後必須保留的行為。
- 對 Agent 而言，測試結果提供了明確且可核對的修正目標。
- 對團隊而言，測試 Evidence 提供了變更是否可接受的判斷依據。
從「生成程式碼」轉向「交付可驗證變更」
AI Agent 提高了程式碼產生與修改速度，但速度本身不等於交付能力。沒有可重複執行的驗證流程，修改越快，累積不確定性的速度也可能越快。
UI 自動化測試的價值，不只是取代人工點擊，而是將主要使用者流程轉換為可版本控管、可重複執行、可產出證據的驗收機制。E2E Testing 用來確認跨層流程仍然成立；Smoke Test 則以最小成本保護系統的基本可用性。
將 Playwright 納入 AI Agent 工作流程後，開發閉環便可從：
Agent 修改程式碼 → Agent 回報已完成
轉變為：
Agent 修改程式碼
→ 執行可重複 UI 驗證
→ 依 Evidence 診斷與修正
→ 以測試結果確認完成真正值得建立的，不是一組零散的自動化腳本，而是一套「修改、驗證、診斷、修正、再驗證」的可持續工作方式。
後續可再從工具鏈與專案環境著手，將 Playwright CLI、Playwright Test、Agent Skill 與專案規範整合為可實際執行的驗證基礎。