你有沒有遇過這種情況:早上打開 CI,一片紅。點進去看,功能明明沒壞,只是前端工程師把按鈕的文字從「送出」改成「確認送出」,locator 找不到元素,測試就掛了。
這種「測試壞了,但產品沒壞」的維護成本,是許多團隊放棄 E2E 測試的主因。Playwright 從 1.56 版開始內建了三個 Test Agents:planner、generator、healer。今天我們只聚焦在 healer——它會自己重跑失敗的測試、打開瀏覽器看現在的畫面長什麼樣、修改 locator、再跑一次,直到測試通過為止。
圖一:Playwright 三個 Test Agents 的分工,本文聚焦在 Healer
整個過程你只需要兩個工具:Playwright 和 Claude Code。不用裝其他外掛,不用寫任何設定檔。
事前準備
你需要:
- Node.js 18 以上
- Claude Code(已登入)
- 一個有 Playwright 測試的專案
如果手邊沒有現成專案,可以快速建一個練習用的:
| mkdir healer-demo && cd healer-demo npm init playwright@latest |
安裝時一路按 Enter 用預設值就好,它會幫你建立 tests/example.spec.ts,裡面有兩個測試 playwright.dev 官網的範例。先跑一次確認環境正常:
| npx playwright test |
兩個測試都綠燈,我們就可以開始了。
第一步:把 Playwright Agents 裝進 Claude Code
在專案根目錄執行:
| npx playwright init-agents –loop=claude |
–loop=claude 的意思是「幫我產生 Claude Code 用的 agent 定義」。執行完之後,你會發現專案多了一個 .claude/agents/ 資料夾,裡面有三個 Markdown 檔案,分別對應 planner、generator、healer。
打開來看你會發現,這些 agent 本質上就是 Claude Code 的 subagent 定義:一段指令,加上它可以使用的 Playwright MCP 工具。沒有黑魔法,全部是可讀、可改的純文字。這也代表 Playwright 升版之後,記得重新執行一次 init-agents,才能拿到新版的工具和指令。
第二步:故意把測試弄壞
要看 healer 修東西,得先有壞掉的測試。我們來模擬最常見的情境:UI 改版導致 locator 失效。
打開 tests/example.spec.ts,找到這一段:
| await page.getByRole(‘link’, { name: ‘Get started’ }).click(); |
把它改成一個不存在的元素:
| await page.getByRole(‘link’, { name: ‘Get started now’ }).click(); |
再跑一次測試:
| npx playwright test |
這次 get started link 這個測試會失敗,錯誤訊息是 timeout,因為頁面上根本沒有叫「Get started now」的連結。這就是我們平常遇到的情境:別人改了 UI,你的測試碼還停留在舊世界。
第三步:叫 Healer 出來修
在專案根目錄啟動 Claude Code:
| claude |
然後直接用自然語言下指令:
| get started link 這個測試失敗了,用 healer 修復它 |
Claude Code 會自動把工作交給 healer subagent。它的工作方式是一個循環:
圖二:Healer 的修復循環——修到綠燈為止,修不動就標記 skip 交給人判斷
整個過程大概一兩分鐘。修完之後你可以用 git diff 看它到底改了什麼——這個習慣很重要,後面會講為什麼。
跟過去人工修測試比起來,差別在哪裡?
| 人工修測試 | 交給 Healer | |
| 做的事 | 開 trace viewer、比對畫面、改 locator、重跑 | 下一句指令,等它跑完後 review patch |
| 單一測試耗時 | 約 10~20 分鐘 | 約 1~2 分鐘 + review 時間 |
| 人的角色 | 親手診斷與修改 | 把關:確認 patch 沒把斷言改弱、skip 的是不是真 bug |
Healer 還能修哪些問題
locator 失效只是最基本的情境。實際使用上,healer 能處理的失敗類型包括:
- 元素改名或改結構:按鈕文字變了、role 變了、從 button 換成 link
- 時序問題:頁面載入變慢、需要多等一個 API 回應,healer 會加上適當的等待
- 流程改變:例如結帳流程多了一個確認步驟,healer 會把新步驟補進測試裡
- 測試資料問題:資料狀態不符合預期時,調整測試的前置準備
還有一個值得注意的設計:如果 healer 重試幾次之後判斷「這個功能是真的壞了,不是測試的問題」,它會把測試標記成 skip,而非硬把測試改到通過。這個區分很關鍵——自動修復工具最怕的就是把真正的 bug 修成假綠燈。
三個使用上的提醒
第一,修完一定要 review。healer 的產出是一個 patch,它對「什麼是對的行為」的理解來自現在的 UI。如果 UI 本身就改錯了,healer 會忠實地把測試改成配合錯誤的 UI。人要當最後一道 gate,用 git diff 檢查每一次修復,確認它改的是 locator 和等待邏輯,不是把斷言改弱了。
第二,一次修一個測試。healer 的輸入是失敗的測試名稱。與其丟一句「把所有失敗的測試都修好」,不如一個一個指定,你比較容易追蹤它每次改了什麼,token 消耗也比較可控。
第三,把 healer 當成維護工具,不是掩蓋問題的工具。如果同一個測試每週都需要 healer 出手,那要問的問題是:這個測試的 locator 策略是不是太脆弱?是不是該跟前端團隊約定穩定的 accessibility 屬性?healer 降低了修測試的成本,但沒有免除你改善測試設計的責任。
小結
回顧一下整個流程,其實只有三個指令:
| npx playwright init-agents –loop=claude # 裝 agent 定義 npx playwright test # 找出失敗的測試 claude # 叫 healer 修 |
過去測試壞掉,工程師要自己開 trace viewer、比對畫面、改 locator、重跑,一個測試修下來十幾二十分鐘跑不掉。現在這段工作可以交給 healer,人的角色往後移一步:review patch、判斷 skip 掉的測試是不是真的 bug、決定哪些修復可以進 main。
修測試的手工變便宜了,但「這個修復對不對」的判斷還是你的工作。這件事 AI 目前替代不了,短期內大概也不會。
發表迴響