自動化測試回答的是「我們預期的行為還在嗎」,探索性測試回答的是「有沒有我們沒想到的問題」。這兩件事以前很難兼顧,因為探索需要人一邊操作、一邊觀察、一邊設計下一步。現在有了 Claude Code 加上 Playwright,你可以讓 AI 當你的結對探索夥伴:它負責操作瀏覽器和記錄,你負責決定探索方向和判斷「這算不算問題」。

這篇文章帶你實際走一遍。測試對象用 Playwright 官方的 TodoMVC 範例站,場景挑選用 James Whittaker 的 tour testing:tour 就是 charter,由 Claude Code 從每個 charter 產生具體的測試場景、人來 review 挑選,對多數人來說這樣上手最快。接著比較 MCP 和 CLI 兩種做法,最後整理業界目前常見的用法。

圖 1:探索性測試中,人與 Claude 的結對分工

一、事前準備

你需要 Node.js 18 以上,以及 Claude Code。接著在專案目錄安裝 Playwright:

mkdir explore-todomvc && cd explore-todomvc
npm init playwright@latest

安裝過程會問你要不要裝瀏覽器,選 yes。

再加上 Playwright 官方的 MCP server(注意是 Microsoft 官方的 @playwright/mcp,不要跟社群另一個同名專案搞混):

claude mcp add playwright npx @playwright/mcp@latest

之後啟動 claude,輸入 /mcp 應該能看到 playwright 的工具清單。環境就緒。

測試對象是 Playwright 官方文件範例用的網站:
https://demo.playwright.dev/todomvc

這是一個待辦清單應用,有新增、勾選完成、篩選、清除等功能。麻雀雖小,夠我們探索出東西。

二、從 charter 到測試場景:Claude 產生,人 review

探索性測試最怕漫無目的地亂點。James Whittaker 在《Exploratory Software Testing》(2009)提出 tour testing:把待測系統想成一座城市,每個 tour 就是一個 charter,定義了這趟探索的主題與策略。常用的包括 Landmark、Saboteur、Obsessive-Compulsive、FedEx、Supermodel 等。挑幾個適合 TodoMVC 的:

‧ Landmark Tour:挑出系統的重要功能當地標,規劃一條路線依序造訪,確認每個地標之間的轉換順暢。對 TodoMVC 來說,地標就是新增、編輯、完成、篩選、清除。

‧ Saboteur Tour:故意做出開發者不希望你做的事。輸入空白、輸入超長字串、貼上表情符號、快速連按、中途重新整理。

‧ Obsessive-Compulsive Tour:同一個動作重複做很多次,或做完立刻復原再做。新增又刪除一百次之後,系統狀態還正確嗎?

charter 只給了方向,實際要操作什麼還需要展開成具體的測試場景。這一步不必自己想,讓 Claude Code 先產生、人再 review,對多數人來說最省力。在 claude 裡貼上:

請先開啟 https://demo.playwright.dev/todomvc 了解功能。
我要用 tour testing 的方式做探索性測試,
charter 選定:Landmark Tour、Saboteur Tour、
Obsessive-Compulsive Tour。
 
請為每個 charter 產生 3 個具體的測試場景,
每個場景包含:操作步驟概要、想觀察的重點、預估時間。
 
先不要執行,列出來讓我 review 挑選與修改。

Claude 會回你一份場景清單,例如:

Charter:Landmark Tour
場景 1:新增 5 筆待辦 → 逐一編輯 → 勾選完成 → 切換三種篩選,
        觀察計數器與清單是否一致(約 10 分鐘)
場景 2:在 Active 篩選下勾選完成,觀察項目是否即時消失、
        重新整理後狀態是否保留(約 8 分鐘)
場景 3:Clear completed 後切換各篩選,觀察殘留與計數(約 8 分鐘)
 
Charter:Saboteur Tour
場景 1:輸入空字串、純空白、500 字超長字串,
        觀察驗證與清單顯示(約 10 分鐘)
場景 2:貼上 <script>alert(1)</script>、emoji、中文混排,
        觀察轉義與排版(約 10 分鐘)
...

接著換人上場 review。刪掉重複或價值低的場景、補上你在意但 Claude 沒想到的風險、確認每個場景在預估時間內做得完。挑出這個 session 要跑的組合,場景就定案了。這一步花你五分鐘,卻決定了整個 session 的品質——charter 和場景的取捨是人的判斷,Claude 只是幫你把選項攤開來。

圖 2:tour testing 的層次——charter 展開為測試場景,人 review

整個 session 建議限時,業界常見做法是 60 到 120 分鐘。用 AI 輔助後,30 分鐘內通常就能跑完一個 charter 底下挑出的場景。

三、走法一:MCP,讓 Claude 直接開瀏覽器探索

場景定案後,直接接著在同一個 claude 對話裡下指令(所以 Claude 已經知道場景內容):

使用 playwright mcp 開啟 https://demo.playwright.dev/todomvc,
執行剛剛 review 過的 Saboteur Tour 場景 1 和場景 2。
 
規則:
1. 每做一個動作,先說明你的假設,再操作,再記錄實際結果
2. 發現可疑行為時,嘗試縮小重現步驟
3. 全部做完後,把過程整理成 session-notes.md,
   包含:操作紀錄、發現的問題(附重現步驟)、
   沒問題但值得注意的觀察、建議後續探索的方向

你會看到一個 Chrome 視窗打開,Claude 開始操作。它靠的是 accessibility snapshot(頁面的結構化快照)來「看」畫面,所以能準確找到元素,也能觀察操作後的狀態變化。

這個走法的體驗很接近真人結對:Claude 會在過程中回報「輸入純空白字串後,按 Enter 沒有新增項目,符合預期」或「輸入前後空白沒有被 trim,清單顯示保留了空白」這類觀察。你隨時可以插話改變方向,例如「等等,剛剛那個編輯後按 Escape 的行為,再多試幾種情況」。這正是探索性測試的精神——下一步由上一步的發現決定。

跑完後,專案目錄會多出 session-notes.md,這就是你的 session 紀錄初稿。

四、走法二:CLI,讓 Claude 寫探索腳本再執行

第二種走法不用 MCP,而是請 Claude Code 把 review 過的場景轉成 Playwright 測試碼,用 CLI 執行。同樣在 claude 裡:

不要使用 mcp。請把剛剛 review 過的
Obsessive-Compulsive Tour 三個場景,
寫成 Playwright 測試檔 tests/explore-oc.spec.ts:
 
要求:
1. 每個場景寫成獨立的 test,標題用中文描述假設
2. 對「不確定什麼才是正確行為」的地方,不要用 expect 斷言,
   改用 test.info().annotations 記錄實際觀察到的行為
3. 寫完後執行 npx playwright test --trace on,
   再根據結果產出 findings.md

Claude 寫完會自己跑:

npx playwright test --trace on
npx playwright show-report

HTML 報告會列出每個探索項目的結果,trace 則保留了每一步的畫面快照、DOM 狀態和網路請求。發現問題時,用 npx playwright show-trace 打開 trace 檔,可以逐步回放——這是探索性測試長久以來的痛點(「剛剛那個 bug 我重現不出來了」)的解方。

這裡有個關鍵細節:探索性測試很多時候你還不知道「正確答案」是什麼,所以第 2 點要求用 annotation 記錄觀察,而非硬寫斷言。等你人工判讀 findings.md、確認哪些行為是對的之後,再把它們升級成正式的 regression 測試。

五、兩種走法怎麼選

圖 3:MCP 與 CLI 兩種走法的架構對照

我自己的用法是混搭:先用 MCP 跑 Landmark Tour 摸清地形,過程中發現可疑的區域,再請 Claude 把該區域寫成 CLI 腳本,用 Obsessive-Compulsive Tour 的方式重複轟炸。MCP 負責「找到值得深挖的地方」,CLI 負責「挖深並留下證據」。

六、紀錄與報告

不管哪種走法,session 結束時請 Claude 統一產出一份報告:

請把這次探索整理成 exploratory-report.md,結構如下:
- Charter(tour)與執行的測試場景
- 測試環境(URL、瀏覽器、日期)
- 涵蓋範圍:探索了什麼、刻意沒探索什麼
- 問題清單:每個問題附重現步驟、實際結果、預期結果、
  嚴重度(由我人工判定,先留空)
- 觀察與疑問:不確定是否為問題的行為
- 建議的後續 charter

「嚴重度留空給人判定」這點是刻意的。AI 可以觀察和記錄,但「這個行為對使用者是不是問題」的判斷,以及要不要開 bug ticket,應該留在人手上。這也是 session-based test management 的原始精神:session sheet 是給人 debrief 用的,而非取代 debrief。

七、業界常見的用法

整理幾種目前在團隊裡看到的實際搭配:

‧ 開發者自我 QA:改完程式後,請 Claude 用 MCP 開 localhost,依照這次改動的範圍跑一個小 charter,確認沒有改壞周邊功能。這比「只跑既有的自動化測試」多了一層探索視角。

‧ Bug 重現與 triage:拿到一張描述模糊的 bug ticket,把描述貼給 Claude,請它用 MCP 嘗試重現並縮小步驟,產出精確的重現腳本附回 ticket。

‧ 探索發現轉 regression:MCP session 裡確認的問題,修好之後請 Claude 把重現步驟轉成 Playwright spec,進 CI 防止回歸。探索性測試和自動化測試因此接上了:探索負責發現,自動化負責守住。

‧ Trace 附在 ticket 上:CLI 走法產出的 trace 檔直接附在 bug ticket,開發者用 trace viewer 回放,省掉大量「在我機器上不會發生」的來回。

‧ 每個 sprint 排固定的 charter 時段:團隊挑兩三個高風險區域寫 charter,由不同成員搭配 Claude 各跑一個 session,debrief 時比對彼此的發現。AI 降低了操作成本,人的時間集中在挑選旅程和判讀結果。

圖 4:混搭策略——探索接上自動化

八、結語

探索性測試的核心從來都是思考,操作和記錄只是載體。Claude Code 加 Playwright 把載體的成本壓到很低,於是你可以把省下來的力氣放回 charter 設計和結果判讀上——這兩件事,目前仍然只有人做得好。

找一個你熟的系統,挑一兩個 tour testing 的 charter,請 Claude 產生測試場景讓你挑,今天就跑一個 30 分鐘的 session 看看。