在軟體測試的世界裡，存在著兩種截然不同的靈魂。一種像是在鋪設鐵軌，追求極致的精準與穩定；另一種則像是在叢林探險，追求驚喜與未知的邊界。這就是「腳本化測試」（Scripted Testing）與「探索性測試」（Exploratory Testing）。

這個分類本身沒有變，但 AI coding 時代把兩者的成本結構整個翻了過來。以前寫腳本很貴、執行很便宜；現在 Claude Code 一個下午就能生出幾百條 Playwright 腳本，寫腳本變得便宜到近乎免費。真正貴的東西換人了：驗證這些腳本到底測了什麼，才是新的瓶頸。

先處理一個疑問：ET 3.0 說「所有測試都是探索性的」

如果你看過前一篇，應該知道ET 3.0是什麼，看到這篇要比較 Scripted 和 Exploratory，可能會皺眉頭：他們說測試本來就是探索活動，哪來「兩種測試」可以比較？

這個質疑是對的。要理解他們在說什麼，用健康檢查來想最快。

例子一：健康檢查

你去做健檢，護理師幫你量血壓、抽血，儀器印出一張報告，每個數值旁邊標著標準範圍，超出的用紅字標記。這個「量出數值、對照標準範圍」的動作，就是 checking。它有明確的步驟和明確的判定標準，所以可以交給儀器做，做一萬次都一樣。

但接下來，醫生看著你的報告皺眉頭：「血壓正常，但以你的年齡加上你說最近常頭暈，我想再安排一個檢查。」這個動作就是 testing。報告上每個數字都是綠的，醫生卻從中看出了報告沒寫的風險。這需要經驗、需要判斷、需要對「哪裡可能有問題」的直覺——這些沒辦法寫成標準流程交給儀器。

例子二：換到軟體場景

一條 Playwright 腳本：登入、把商品加入購物車、斷言總金額等於 100 元。這是一個 check，跟血壓計一樣，每天跑、跑一千次、標準永遠一致。

而測試員盯著這個購物車功能，心想：「折價券和紅利點數同時用會怎樣？」動手一試，金額變成負的。這就是 testing。沒有任何腳本叫他做這件事，是他的經驗和好奇心把他帶到那裡的。

所以 ET 3.0 想說的是

腳本（check）只是測試過程中產出的一種工具，就像血壓計是健檢的工具。真正在做測試的，一直都是人：決定要寫哪些腳本的是人，看出「AI 產的這條腳本根本沒驗到重點」的是人，覺得「這裡怪怪的，再戳一下」的也是人。這些動作，全部都是探索。

那這篇為什麼還是分成兩邊來比較？

因為公司花錢的方式確實是兩種。一種錢花在「建一批機器天天自動跑的 checks」，另一種錢花在「讓資深測試員坐下來探索兩小時」。這是兩筆預算、兩種排程、兩張成本表，管理者做決策時就是這樣分的。所以接下來的比較照這個分法走，但請記得健檢的例子：儀器再多，看報告的還是醫生。

AI 時代反而讓這個觀點更好懂了：機器負責跑 checks，AI 負責生 checks，人類手上剩下的工作，幾乎全是探索。

帶著這個視角，我們重新看一次這兩種投資。

腳本化測試 (Scripted Testing)

(1) 說明
想像你正在組裝一個精密儀器，說明書上寫著：「第一步鎖上 A 螺絲，第二步接上 B 線路」。這就是腳本化測試的本質。

它是一種「先設計、後執行」的紀律。測試員在產品還沒寫好之前，就已經根據需求文件，寫好了每一步該怎麼走、預期會看到什麼畫面。這就像是編寫一齣劇本，演員（測試員或自動化程式）必須一字不漏地照著演。

AI 時代的變化在於：編劇換人了。過去劇本由測試員一行一行敲出來，現在你把規格丟給 AI，它幾分鐘就能產出完整的測試腳本。測試員的工作重心從「寫劇本」移向「審劇本」——這條腳本的斷言（assertion）真的有在驗證什麼嗎？還是只是開了頁面、點了按鈕，然後什麼都沒檢查就宣告通過？

(2) 強項
在於「確認已知」。當我們要確保舊功能沒有被新程式碼搞壞（回歸測試），或者在金融、醫療這種需要向稽核單位證明「我們真的測過了」的領域，腳本就是你的保命符。這也是自動化測試的地基——因為機器最擅長照著劇本走。

AI 讓這個地基蓋得更快。以前團隊常常因為「沒時間寫自動化」而放棄回歸測試防護網，現在這個藉口消失了。功能穩定下來的當天，就可以請 AI 補齊對應的回歸腳本。

但稽核場景多了一個新問題：稽核員開始會問「這些測試是誰寫的？誰審過？」AI 產生的測試如果沒有人類簽核，在合規上的證據力會被打折。Audit Trail 現在要記錄的東西，包含了測試案例的產生過程。

(3) 盲點
業界有個著名的「殺蟲劑悖論」（Pesticide Paradox）。如果你每次都用同樣的殺蟲劑（腳本）噴灑農田，害蟲（Bug）很快就會產生抗藥性。照著腳本走，你永遠只能發現腳本裡寫到的問題，而那些腳本之外的異常，就會在你的眼皮底下溜進使用者手中。

AI 時代這個悖論多了一個更兇的變種：Oracle Problem。當你請 AI「看著這段程式碼幫我寫測試」，它會忠實地把程式碼現在的行為寫成預期結果。程式碼裡的 bug，也會被包裝成測試的預期值。這種測試永遠是綠燈，因為它在驗證「程式碼做了程式碼做的事」，而規格要它做什麼，AI 根本沒問過。

於是出現了 Coverage Theater：儀表板上 90% 覆蓋率，實際上一半的測試連一個有意義的斷言都沒有。數字很好看，防護力是零。

探索性測試 (Exploratory Testing)

(1) 說明
如果你把腳本丟掉，開始問自己：「如果我在結帳的時候突然斷網會怎樣？」、「如果我輸入了負數的庫存量會怎樣？」恭喜你，你正在進行探索性測試。

這是一種「學習與設計同時進行」的高強度心智活動。測試員就像是刑案現場的偵探，不依賴預設的路線圖，根據當下看到的線索，動態調整下一步的搜查方向。

AI 時代，偵探多了一個助手。你可以請 AI 幫忙列出這個功能可能的邊界條件、產生刁鑽的測試資料、快速把環境調到某個特定狀態。但方向盤還在人手上：判斷「這個行為怪怪的」的那個直覺，目前 AI 給不了你。它甚至常常反過來，一本正經地告訴你這個明顯錯誤的行為「符合常見設計慣例」。

(2) 強項
在於「發現未知」。它能捕捉到那些寫在規格書之外、開發者沒想到的邏輯漏洞。在敏捷開發這種需求變動極快的環境下，探索性測試能用最少的時間，給出最有價值的風險評估。

AI coding 時代，這個強項的價值暴漲。原因很直接：AI 讓產出程式碼的速度快了十倍，但這些程式碼經常連寫的人都沒有逐行看過。團隊對自己系統的理解在下降（這就是 Cognitive Debt），規格外的行為、AI 自作主張的實作細節，比人工寫程式的年代多得多。

當生成不再是瓶頸，驗證就是瓶頸。而探索性測試，正是人類執行驗證最有效的形式之一——它驗證的是「軟體實際上怎麼運作」，而非「文件宣稱它怎麼運作」。

(3) 盲點
它極度依賴「人」。給一位新手和一位專家同樣的時間進行探索，結果會天差地遠。

此外，因為沒有固定的劇本，如果你不擅長做測試紀錄（Session-Based Test Management），主管可能會覺得你只是在玩軟體，而不是在工作。現在你可以開著螢幕錄影和 Playwright trace 做探索，事後請 AI 把整段過程整理成 session 報告、重現步驟，甚至直接轉成可重複執行的腳本。「探索完不知道剛剛做了什麼」這個問題，成本已經降到很低。

新的盲點反而是：過度依賴 AI 給的探索建議。AI 列出的邊界條件，來自它看過的千萬個類似系統，它會漏掉你這個業務領域特有的雷。把 AI 的清單當起點可以，當終點就危險了。

適用時機與關鍵活動

腳本化測試

腳本化測試（尤其是自動化）是為了「防止退步」。當產品功能已經穩定，我們不再預期它會變動，這時就需要腳本來確保它永遠運作正常。

例如當你要發布 v2.0 版本，你絕對不希望 v1.0 的舊功能壞掉。這時，你不需要創意，你需要的是機械式的確認。

(1) 回歸測試：確保「昨天能動的，今天也能動」。AI 時代這件事更重要，當 AI agent 一天可以改動幾十個檔案，沒有回歸防護網的團隊等於在裸奔。

(2) 合規性檢查 (Compliance/Audit)：金融、醫療軟體需要留下詳細的測試紀錄（Audit Trail）給稽核員看，這時腳本就是法律證據。注意：AI 產生的測試需要人類審核簽名，才能當作稽核證據。

(3) 精確運算驗證：銀行利息計算、稅務公式，這種錯一個小數點都不行的場景，必須依賴嚴謹的腳本對照。這裡有個實務提醒：這類測試的預期值必須來自規格或獨立計算，絕對禁止請 AI「看程式碼推導預期值」，否則就是把 bug 抄進測試裡。

探索性測試

探索性測試是高成本的腦力活動，它最適合用在「高不確定性」與「需要快速回饋」的時刻。

像是當功能剛寫好、規格甚至還在變動時，寫腳本是徒勞的（因為明天就要改）。這時需要測試員直接跳進去，用直覺找出邏輯漏洞。

(1) 新功能驗收：針對剛出爐的功能進行破壞性測試。尤其是當AI 交付一個功能，demo 影片看起來都對。但它有沒有偷偷改了別的地方？錯誤處理是真的有做，還是只印了一行 log？這種「看起來能動」和「真的正確」之間的落差，目前只有人類的探索抓得出來。

(2) 缺陷調查：當使用者回報了一個模糊的 Bug（例如：「有時候會當機」），腳本幫不了你，只有探索能重現案發現場。

(3) 複雜邏輯與邊界測試：例如電商的「滿千送百又折價券再扣紅利」的混合場景，這類組合爆炸的狀況，腳本難以窮舉，探索最有效。

代價分析

這是管理者最愛看，也是最殘酷的部分。天下沒有白吃的午餐，這兩種測試都有其隱形成本。

腳本化測試的代價

很多人以為寫好腳本就一勞永逸，這是最大的誤解。以下是你需要考量到的成本：

(1) 前期成本：從極高變成很低。這是十年來最大的變化。過去要花數週手刻的測試套件，現在 AI 一個下午產出。但別高興太早，省下的錢流去了下一項。

(2) 審核成本：新出現的隱形殺手。AI 產出 300 條測試，總得有人逐條確認斷言是否有意義、預期值是否來自規格。跳過這一步，你得到的只是一座 Coverage Theater。很多團隊在這裡犯的錯，是把「產生測試的速度」當成進度，把審核當成可以省略的形式。

(3) 維護成本： 降低，但多了新陷阱。Self-Healing 工具讓 UI 改版不再一次弄壞幾百條腳本。可是自我修復有個陰暗面：測試遇到非預期行為時，工具可能把它「修復」成接受這個行為：bug 出現，測試自動調整預期值，然後綠燈。你的防護網在你不知情的狀況下，默默學會了放行。

(4) 機會成本：以前是測試員的時間被鎖在執行腳本上。現在的版本是：團隊的注意力被鎖在維護一座龐大、快速膨脹、但沒人真正讀過的 AI 測試套件上，對「這些測試在保護什麼」失去了理解。這也是 Cognitive Debt 的一種。

探索性測試的代價

探索性測試看起來不用寫文件，好像很省錢？錯了，它燃燒的是團隊中最貴的資源。以下是可能會花錢的面向：

(1) 執行成本：高昂的人力成本。探索性測試無法由工讀生執行，它需要懂業務、懂技術的資深測試員。你是在燃燒資深工程師的時間來換取 Bug 的發現。差別在於，現在AI 可以幫忙準備測試資料、調整環境狀態、列邊界條件清單之後，同樣一個 90 分鐘的 session，資深測試員能覆蓋的範圍比以前大。你燃燒的還是最貴的資源，但火力變強了。

(2) 重現成本： 以前當探索者發現一個 Bug，如果不擅長紀錄，往往會陷入「剛剛發生了什麼？」的窘境，導致開發者難以修復。不過現在可以開著 trace 和錄影做探索，發現 bug 之後請 AI 從紀錄裡整理出重現步驟，甚至直接產出一條回歸腳本釘住這個 bug。「剛剛發生了什麼？」的窘境，技術上已經有解。

(3) 管理成本：難以量化進度。老闆會問：「你今天測了什麼？」如果沒有良好的 Session-Based 管理，探索性測試看起來就像在摸魚。不過現在可以請 AI 代勞，把探索過程摘要成報告、標記涵蓋的風險區域。老闆問「你今天測了什麼」，你有東西可以給他看了。

實務上的結論

把兩種測試的新成本結構擺在一起看，會得到一個具體的行動方向：

腳本的產生交給 AI，人類的時間集中在兩件事上：審核 AI 產出的腳本，以及對 AI 寫的功能做探索性測試。

過去團隊的人力配置可能是 70% 寫腳本、30% 探索。當寫腳本的成本趨近於零，繼續維持這個比例就是在浪費資深人力。往「審核 + 探索」移動，才對得起現在的成本結構。

測試員的角色沒有被 AI 取代，但重心確實移動了：從「照劇本演出的演員」，走向「劇本的審稿人，加上劇本外的偵探」。