現代軟體測試與 AI 實戰 (6)：Agentic Testing 的閉環，AI 自動執行與除錯

恭喜各位！這是「現代軟體測試與 AI 輔助實戰」系列的最終回。

經過前面幾篇的洗禮，我們已經能用 AI 秒速生出測試案例，並轉換成強大的 API 整合測試。但真實的商業世界裡，老闆跟客戶最終看的是「網頁畫面有沒有跑版」、「按鈕能不能按」。這時，我們就需要進行**驗收測試（Acceptance Test）**或是端到端測試（End-to-End, E2E）。

但早在冰淇淋筒反模式那篇我們就提過，UI 自動化測試極度脆弱（Flaky），維護成本極高。 好消息是，Agentic AI 的崛起徹底改變了這個遊戲規則。

什麼是「Agentic Testing」？

傳統的 UI 自動化腳本（如 Selenium、Cypress 等）是「死」的。你必須告訴它「點擊 ID 為 #login-btn 的按鈕」。只要設計師把 ID 改成 #btn-login，測試就會原地爆炸。

Agentic Testing 則賦予了自動化腳本認知能力（Cognitive Ability）。我們給 AI 的是一條指令：「幫我登入系統，並確認購物車內有 3 件商品」，不用再提供死板的 Selector。

你需要哪些工具？

這裡有個很常見的問題：「我知道要用 Playwright，但到底怎麼和 AI 結合？」

Playwright CLI（官方推薦，2026 年最新）

Playwright 官方在 2026 年初推出了給 coding agent 用的 Playwright CLI（@playwright/cli），官方測試比舊的 MCP Server 方案省約 4 倍 token。

差異在哪？ MCP 模式會把整個頁面的 accessibility tree 塞進 AI 的 context window；CLI 模式則是存到磁碟，AI 只讀取它真正需要的部分，更快也更省錢。

安裝步驟（以 Claude Code 為例）

# 確認版本
node --version            # >= 18
npx playwright --version  # >= 1.56（不夠的話先更新）

# 安裝或更新 Playwright
npm init playwright@latest

# 產生三個角色定義檔（for Claude Code）
npx playwright init-agents --loop=claude

這個指令做了什麼？ 它在你的專案裡產生三個 Agent 定義檔 和一個 MCP 伺服器設定：

.claude/agents/
  playwright-test-planner.md   ← Planner Agent（探索與規劃）
  playwright-test-generator.md ← Generator Agent（產生測試程式碼）
  playwright-test-healer.md    ← Healer Agent（除錯與修復）
.mcp.json                       ← MCP 伺服器設定（連接 Playwright）
specs/README.md                 ← 測試計畫存放目錄
seed.spec.ts                    ← 預設的環境初始化檔案

這些檔案定義了 Subagent。Claude Code 會為每個檔案生成一個專門的 agent，每個 agent 各自擁有下面三樣東西。

• 專有的系統提示：定義該 agent 的工作邏輯（Planner 的探索方式、Generator 的程式碼產生方式、Healer 的除錯流程）
• 專有的工具集：每個 agent 只能使用與它相關的 Playwright 工具（例如 Healer 可以用 test_run 和 test_debug，Generator 可以用 generator_write_test）
• 統一的模型：都使用 Claude Sonnet

在 Claude Code 中使用這三個 Subagent

這三個 subagent 在 Claude Code 啟動時就會自動載入（如果 .claude/agents/ 是這次 session 中途才建立的，要重開 session 才會載入），要指定用哪一個就用 @ 提及：

1. 在對話框輸入 @，從選單挑 playwright-test-planner (agent)
2. 或直接輸入 @agent-playwright-test-planner（同樣效果）

閉環流程（順序執行）：

1. Planner：你告訴它「分析 /checkout 頁面的結帳流程」，它探索 App 並產生 specs/test-plan.md
2. Generator：你餵它 test-plan.md，它自動轉成 *.spec.ts 測試檔案
3. Healer：測試失敗時，它自動除錯、修復程式碼，讓測試重新通過

體驗閉環：AI 如何執行端到端 (E2E) 測試

現在我們有了工具，來看 AI 在閉環的每個階段實際在做什麼。

Playwright 的 Agentic Testing 閉環由三個 agent 接力完成，Planner 讀需求寫出測試計畫，Generator 把計畫轉成測試檔，Healer 執行測試、修好失效的 selector 直到全綠，遇到真的 bug 則附上證據回報。

1. 閱讀與推論（Planning）

在 Claude Code 中用 @agent-playwright-test-planner 叫出 Planner Agent，給它一段需求描述：

「分析 /checkout 頁面，為整個結帳流程（加入商品 → 輸入折扣碼 → 送出訂單）產出測試計畫」

Agent 會透過 Playwright 啟動 headless 瀏覽器，分析頁面的 accessibility tree。這是一個比 DOM 更語意化的結構，長這樣：

button "Apply Coupon" (role=button)
input "Coupon Code" (role=textbox)
heading "Order Summary" (role=heading)

相比傳統的 #apply-btn CSS selector，accessibility tree 用的是「語意」而非「位置」。即使前端把所有 class 和 ID 全部重寫，只要按鈕的文字和用途沒變，AI 就找得到它。

2. 操作與驗證（Acting）

傳統 Playwright 腳本（你要自己寫，選錯 selector 就壞）：

await page.goto('/checkout');
await page.locator('#promo-code').fill('SAVE10');
await page.locator('[data-testid="apply-btn"]').click();
await expect(page.locator('.discount-amount')).toContainText('-10%');

Agentic 做法（載入 Generator Agent，只需這樣說就夠了）：

AI 理解語意，自己決定怎麼操作。如果途中遇到彈出廣告遮擋了按鈕：

• 傳統測試：直接 Timeout 失敗。
• Agentic 測試：AI 看到 accessibility tree 裡有個 button "Close" 擋在前面，自動關掉廣告，繼續執行。這就是「自我修復（Self-Healing）」，不靠規則，靠推論。

3. 自動記錄與提報（Logging & Reporting）

用 @agent-playwright-test-healer 執行測試套件。在 playwright.config.ts 加上這幾行，讓每次執行都自動留下完整的證據：

// playwright.config.ts
use: {
  video: 'retain-on-failure',    // 失敗時保留錄影
  screenshot: 'only-on-failure', // 失敗時截圖
  trace: 'on-first-retry',       // 第一次重試時收集 trace
}

AI 遭遇真正的 Bug 時，會打包一份完整報告：

🤖 Agent 回報：「在嘗試結帳時，發現畫面的『送出』按鈕被一個絕對定位的 Footer 遮擋了，導致無法點擊。請前端工程師檢查 z-index 問題。附帶錯誤發生前 3 秒的影片與截圖。」

Healer Agent 還會嘗試自動修復因程式碼更新導致的 selector 失效。如果 Generator 生成的 locator 因為 UI 改版而找不到元素，Healer 會重新分析頁面並更新選取器，不需要你手動介入。

實戰驗證：執行 Playwright Agents 的完整流程

我們用一個真實的專案驗證了這套工作流。以下是 npx playwright init-agents --loop=claude 實際產生的結構：

.claude/agents/
  playwright-test-planner.md    ← Planner Agent（3399 bytes）
  playwright-test-generator.md  ← Generator Agent（3399 bytes）
  playwright-test-healer.md     ← Healer Agent（2895 bytes）
.mcp.json                        ← MCP 伺服器設定
specs/
  README.md                      ← 測試計畫存放位置
seed.spec.ts                     ← 預設的測試檔案模板

實際的 Planner Agent 行為

在 Claude Code 中用 @agent-playwright-test-planner 給它一個需求（如「分析 /blog/zh-TW 首頁，為 Popular Posts 側邊欄產出測試計畫」），Planner Agent 會：

1. 啟動 headless 瀏覽器（透過 MCP 的 planner_setup_page 工具）

2. 探索頁面結構，捕捉 accessibility tree（不是 CSS selectors）

3. 產出 specs/test-plan.md，內容包含：

   ## 場景 1: 側邊欄應顯示「Popular Posts」標題
   
   **步驟**: 訪問頁面 → 查找標題
   **預期**: 側邊欄可見，顯示「Popular Posts」
   
   ## 場景 2: 側邊欄應顯示至少 3 篇文章
   
   **步驟**: 計算列表項目
   **預期**: 列表項 ≥ 3
   

實際的 Generator Agent 行為

接著用 @agent-playwright-test-generator 指向 test-plan.md，Generator Agent 會：

1. 讀取測試計畫中的每個場景

2. 自動執行每個步驟（用 generator_setup_page 啟動頁面，用 browser_click、browser_type 等互動）

3. 記錄執行過程（透過 generator_read_log）

4. 產出 specs/popular-posts.spec.ts：

   test('側邊欄應顯示 Popular Posts 標題', async ({ page }) => {
     const title = page.getByRole('heading', { name: /Popular Posts/i });
     await expect(title).toBeVisible();
   });
   
   test('側邊欄應顯示至少 3 篇文章', async ({ page }) => {
     const articles = page.locator('li'); // ← AI 自動找到的 selector
     expect(await articles.count()).toBeGreaterThanOrEqual(3);
   });
   

實際的 Healer Agent 行為

執行 npx playwright test 有測試失敗，就用 @agent-playwright-test-healer，Healer Agent 會：

1. 自動執行所有測試（用 test_run）
2. 診斷每個失敗（用 test_debug）
3. 自動修復（編輯 .spec.ts）
4. 重新執行驗證（迭代直到全綠）

對比：傳統 UI 自動化 vs Playwright Agent

傳統 UI 自動化靠寫死的 selector 找元素，UI 一改版就失敗；Playwright Agent 讀的是 accessibility tree，只要按鈕的文字和用途沒變就找得到。

Playwright Agent 搭配驗證矩陣

如果你讀過文章 7 - 驗證矩陣，會發現兩者是完美的搭配。驗證矩陣決定測試要蓋什麼，Playwright Agents 負責把它自動寫出來。

完整工作流：

1. PO + AI 制定驗證矩陣： 列出所有功能點 × 測試維度（Happy, Negative, Boundary）
2. Planner Agent 讀矩陣： 自動產出 test-plan.md（對應矩陣的每一格）
3. Generator Agent 編碼： 將計畫轉成 *.spec.ts（涵蓋矩陣所有場景）
4. Healer Agent 修復： 執行測試，失敗自動修復，直到全綠

時間投入對比：

• 傳統方式（驗證矩陣 + 手寫測試）：8-10 小時
• Playwright Agent 方式（驗證矩陣 + AI 生成 + 自動修復）：1.5-2 小時
• 節省 85% 工時

總結：人類與 AI 在測試領域的未來分工

走遍這 6 篇文章，我們可以總結出未來軟體測試的發展趨勢：

1. 捨棄爛架構：TDD 精神不滅，健康的金字塔架構、容器化（Docker）、左移測試仍是核心基本功。
2. 人類制定邊界：工程師只需專注於架構設計與「Edge Cases 的驗收標準」。
3. AI 負責落地：從「撰寫測項清單」、「生成整合測試腳本」，到最終的「Agentic 驅動瀏覽器測試」，全都可以交由 AI 代勞。

在 AI 測試時代，品質保證（QA）會是一門優雅的系統工程學。希望這個系列對你在提升專案品質與 AI 導入上有所啟發！