現代軟體測試與 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 提供死板 Selector，而是給它一條指令：「幫我登入系統，並確認購物車內有 3 件商品」。

你需要哪些工具？

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

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

Playwright 官方在 2026 年初推出了 Playwright CLI Agent 模式，比舊的 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 中載入這些檔案時，Claude 會自動為每個檔案生成一個專門的 agent，它們各自擁有：

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

在 Claude Code 中使用這三個 Subagent

你的做法非常簡單：拖入對應的 agent 定義檔，Claude 就會自動生成對應的 subagent。

你可以：

1. 直接在 Claude Code 對話框拖入 .claude/agents/playwright-test-planner.md（自動生成 Planner subagent）
2. 或者用語法引用：@playwright-test-planner.md（同樣效果）

閉環流程（順序執行）：

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

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

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

1. 閱讀與推論 (Planning)

在 Claude Code 中載入 Planner Agent（拖入 .claude/agents/playwright-test-planner.md 或用 @playwright-test-planner.md 引用），給它一段需求描述：

「分析 /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)

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

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

當 AI 遭遇真正的 Bug，它不只丟一個冷冰冰的 AssertionError，而是打包完整報告：

🤖 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 中引用 @playwright-test-planner.md 並給它一個需求（如「分析 /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 行為

接著，你在 Claude Code 中引用 @playwright-test-generator.md 並指向 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 並有測試失敗時，引用 @playwright-test-healer.md，Healer Agent 會：

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

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

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

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

在 AI 測試時代，品質保證 (QA) 將不再是苦力活，而是一門優雅的系統工程學。希望這個系列對你在提升專案品質與 AI 導入上有所啟發！