一聽到「AI 導入軟體測試」，很多 QA 工程師跟開發者的直覺反應往往是：是不是又要寫一堆全自動化腳本了？但如果我們談的是高度依賴人類直覺、好奇心與隨機應變的「探索式測試」，AI 真的派得上用場嗎？答案是絕對肯定的。

在過去，我們常把「測試覆蓋率」跟程式碼行數或測試計畫的執行百分比綁在一起。但在探索式測試的世界裡，真正的目標是「盡可能多地去了解這個系統」。既然我們永遠無法達到實質上 100% 的覆蓋，那麼如果能利用 AI 幫我們省下大把時間，我們就能發掘出系統裡更多的秘密。

這裡我們將帶你了解 AI 如何在探索式測試中成為你的「超級副駕」，以及人類與 AI 究竟該如何完美分工，打造出最高效的現代化軟體測試流程。

很多人擔心 AI 會搶走測試人員的飯碗，但在探索式測試的領域，這種事目前是不太可能發生的。為什麼呢？因為軟體最終是給「人」用的，我們必須將真實的「人類體驗」保留在測試的迴圈裡面。

你想想看，AI 雖然算力強、速度快，但它缺乏人類的「非處方性（non-prescriptive）觀察力」。在測試的過程中，人類會敏銳地察覺到那些沒有被寫在規格書上的異常狀況。例如，當你點擊一個按鈕，系統確實回傳了正確的資料，但你身為人類會感覺到：「咦，這個畫面轉圈圈載入的時間也太長了吧？」

再者，人類會根據看到的有趣現象，突然靈光一閃：「如果我換個順序點擊會怎樣？」這種基於人類感官判斷與隨機應變的好奇心，是缺乏實體體驗的 AI 無法主動具備的。所以，我們不是要把測試工作外包給 AI，而是要找它來當我們的「超級助理」，一起結伴工作。

在進行探索式測試時，我們通常會用「Sessions」來限制測試時間（例如專心測半小時），並透過「Charters」來定義探索的起點與大方向。在這套實戰框架下，AI 能在以下四個核心環節幫上大忙：

(1) 沒靈感？一鍵生成「測試章程」與優先級排序

面對一個全新的頁面或 API，萬事起頭難。與其盯著螢幕發呆，不如直接找 AI 幫忙腦力激盪。

舉個例子，如果你面對一個電商網站的「登入」與「結帳」功能，只要把背景丟給 AI，因為它看過太多類似的網站，通常在短短 30 秒內就能給你一份超有價值的探索清單（例如測試產品排序功能等）。對於新手，這是超棒的起步點；對於老手，這能幫你省下無數的思考時間。

測 API 就更神了。如果你直接把 OpenAPI 的 YAML 規格檔（Schema）丟給 AI，它不僅會建議你測基礎搜尋，還能從資料結構中看出端倪，提出進階的測試情境，像是「處理巨量資料時的分頁功能」、「效能邊界」或是「部分名稱比對」。

如果 AI 給的點子太多，你在有限的時間內做不完怎麼辦？你可以直接用白話文要求 AI：「我時間不夠，請根據一般使用者的行為習慣，幫我把這些建議排出高、中、低的優先順序。」 這樣一來，你的決策成本就大幅降低了。

(2) 測試卡關？讓 AI 當你的專屬「導航員」
探索式測試最有趣的地方，就是你常常會把系統玩到一個極度偏門的狀態。假設你在電商網站上，把商品類別篩選成「相機」，接著又把品牌限定為「蘋果」。在這個極度特定的狀態下，如果你突然腦袋卡殼，不知道下一步該點什麼，你可以直接問 AI：「我現在卡在這個特定的畫面，接下來我該怎麼做？」 AI 會根據你當下的特殊情境，立刻提供全新的測試靈感，讓你順利突破盲點，甚至發展出一個全新的探索方向。

(3) 討厭生假資料？AI 幫你搞定 JSON 與預期結果
準備測試資料，絕對是多數 QA 工程師覺得最煩人又最容易打錯字的工作。

以 API 測試的 POST 請求為例，手動敲打 JSON 檔超浪費時間。現在，你只要對 AI 說：「請幫我準備兩個 JSON 請求，一個是『來自鏡像宇宙的史巴克』，另一個是『史巴克二號』」。AI 會完美讀懂 Schema，直接幫你把 mirror: true 這種欄位精準設定好，連程式碼的括號都不會漏。

更厲害的是，AI 能結合它原本的知識庫來提供超真實的資料。在測試《星艦迷航記》的 API 時，AI 建議使用特殊的真實角色（如 Worf 之子 Paul）或常見姓氏（Tom Paris）來測試。用真實世界的資料來測試，能讓你對測試結果更有信心，因為你確切知道這些資料「理應」要在系統裡找得到。

除此之外，AI 還能幫你預先寫好用來比對的「預期結果」。不過要特別注意，AI 其實是在「猜測」資料庫裡有什麼。所以當它產出包含動態生成的雜訊（例如每次都會變的 UID）時，你必須發揮人類的判斷力直接忽略它，專注於比對關鍵的欄位就好。

(4) 擺脫重複點擊！快速生成「狀態前置腳本」

你一定有過這種經驗：今天想針對「購物車」進行深度探索，但每次測試前都得先登入、隨便挑兩個商品、點擊加入購物車，才能來到真的要測的畫面。這些重複的準備動作實在太消耗熱情了！

這時候，你可以請 AI 幫你寫一段「Setup Script」。你只要告訴 AI：「請幫我寫一段腳本，自動登入、選擇兩件商品，然後前往購物車頁面。」 這段程式碼不是用來驗證對錯的，而是幫你瞬間跳過無聊的步驟，直達到達探索起點。

如果探索過程中你發現了 Bug，這種腳本甚至能用來自動重現問題，直接發送到 Jira 裡，超級省時。當然，如果你手動探索出了一條很棒的測試路徑，也可以請 AI 將剛剛的操作寫成 Python 或 Playwright 自動化測試腳本，甚至要求它套用「頁面物件模型（Page Object Model, POM）」進行重構，讓程式碼乾淨漂亮地融入你們公司既有的測試架構中。

在現代化的軟體測試流程中，我們與 AI 不是單向的主從關係，而是一種「Pairing」合作的夥伴關係。理解彼此的強項，才能把工作效率催到極限。

(1) AI 的職責：苦力擔當與大腦激盪

不要把 AI 當成幫你做最終決定的老闆，把它當作手腳超快的好幫手。

• 靈感擴充器：在短短幾秒鐘內產出大量的測試大綱、邊界情境與探索方向。
• 無情的資料產生器：根據複雜的 API 規格快速產出準確的 JSON 請求檔，或是基於常識幫你猜測測試的預期結果。
• 基礎程式碼推土機：幫你打字，撰寫狀態前置腳本、自動化測試草稿，並照你的要求重構程式碼。
  

(2) 人類的職責：決策者、審查者與體驗感知者

我們要把寶貴的腦力，花在 AI 做不到的事情上。

• 提供上下文與做決定：AI 不知道你們專案的歷史背景，也不知道哪個模組最常壞掉。人類必須提供這些背景資訊，並親自決定要從哪一個優先級別開始測試。
• 嚴謹的審查：AI 給的東西不一定全對。自動化腳本可能無法直接跑起來，預期結果也可能包含會一直變動的 ID。人類必須擔任把關者，剔除雜訊並修正錯誤。
• 非處方性的直覺探索：發揮身為人類的好奇心，去感受畫面有沒有卡頓、排版有沒有跑位，並在隨機的點擊中找出系統隱藏的致命傷。
  

下次進行軟體測試時，別再傻傻地從頭自己苦幹了。在探索式測試的世界裡，AI 是一把解放時間的萬能鑰匙。當你把繁瑣的資料準備、環境前置與初期發想都交給 AI 處理後，你就能把省下來的時間，投資在真正需要人類智慧的「深度探索」上。

透過這種人機結對合作的超強組合，我們不僅能找出更多隱藏的 Bug，更能真正在這個 AI 時代，發揮出測試工程師不可取代的黃金價值。