為什麼「AI 測試」是個沒什麼用的分類
分類通常是用來指稱一個問題，但這個分類指的是一項技術——所以它一口氣蓋住了三種問題，而這三種問題症狀不同、買單的人不同、失敗的方式也不同。在比較任何工具之前，先把自己面對的是哪一種講出來，很值得。
第一種：幫你寫測試的 AI
它解決的問題： 你有一堆沒有測試的程式碼，而手寫測試既慢又無聊。
它實際上長什麼樣子： 你把工具指向某個函式、某個檔案或某份規格，它就產出可以直接提交的測試程式碼。
它的極限在哪裡： 產生出來的測試，會繼承它所依據的那份程式碼的假設。如果實作本身誤解了某個端點會回傳什麼，產生的測試就會斷言同一份誤解，然後順利通過。這是整個類別很少被說出口的極限。覆蓋率上去了，信心卻不該跟著上去——至少不該像那個數字看起來那麼多。
什麼情況下你需要它： 你的缺口是「量」。有一大片沒有測試的程式碼，而沒有人有時間。
第二種：負責執行與維護測試的 AI
它解決的問題： 你已經有一套測試，而養活它很花錢。改版一來選擇器就壞掉，測試時好時壞，每個 sprint 都有一塊不小的時間花在修它們。
它實際上長什麼樣子： 介面一動，執行器就跟著調整。按鈕換了文字或換了位置，一樣找得到，因為那個步驟被理解成一個意圖，而不是一條穿過 DOM 的固定路徑。
它的極限在哪裡： 這種適應力是把雙面刃。一套在真正出現迴歸錯誤時還繞過去自我修復的測試，比一套直接失敗的測試更糟，因為它把你最想知道的事情藏了起來。有用的版本會分辨「介面變了」和「行為變了」，而且只放過前者。
什麼情況下你需要它： 你的缺口是「維護」。測試已經存在，而讓它們保持綠燈，就是你要繳的稅。
第三種：驗證 AI 寫出來的程式碼
它解決的問題： 你的團隊交付 AI 代理產出的程式碼，速度快到沒有人讀得完；而以前能攔下錯誤的審查這一關，已經悄悄變成一道形式。
它實際上長什麼樣子： 已部署的應用程式會像真人在用那樣被實際操作一遍，結果以 AI 代理能直接據以行動的證據形式回來，於是修正就發生在與改動同一個循環裡。
它該搭配什麼： 用快速的本機單元測試處理邏輯，用專門的工具處理負載。這一層回答的，是那兩者回答不了的問題：這個功能在實際運行的產品裡，到底能不能用。
什麼情況下你需要它： 你的缺口是「信任」。程式碼的量上去了，審查的量能沒有，而沒有人敢說最近二十次合併有沒有弄壞什麼。
你真正需要的是哪一種 AI 測試
一份簡短的診斷，依值得發問的順序排列。
你會點頭說「對」的那一句
「我們幾乎沒有測試。」
「我們測試很多，有一半是紅的，而且理由跟我們的產品無關。」
「測試都是綠的，版本還是會出事，而且我們的程式碼現在大多是 AI 代理寫出來的。」
那你的問題就是
量。第一種。
維護。第二種。
信任。第三種。
買錯的話，會變成
覆蓋率上升，事故沒有下降。
測試比較不會時好時壞，漏出去的缺陷一樣多。
一個沒人會打開的儀表板，因為它回報的是一套根本沒人寫的測試。
第三列最值得停下來想一想。覆蓋率上升和不穩定測試減少都很好量，但兩者都不是你真正想要的東西。你想要的，是上線之後的意外變少。
一個問題，就能分出認真的工具和只是 demo 的工具
不管你看的是哪一種，都問一句：失敗的時候會發生什麼事。
demo 給你的是一列紅色。真的能用下去的工具，會告訴你它想做什麼、應用程式實際做了什麼、兩者在哪裡分岔，而且是以負責修的人不必重新推敲整件事就能直接使用的形式給出。如果失敗換來的答案只是一張截圖和一段 stack trace，那解讀的工作還是落在人身上，而那個人正是你想拿掉的瓶頸。
當負責修的是 AI 代理而不是人，這件事的重要性還要再加倍，因為代理沒辦法瞇著眼看截圖、自己猜出意圖。
第二個問題：沒有你，它會自己跑嗎
如果測試只有在有人想起來的時候才跑，上面這幾種全都等於零。會按排程、或在每一次 pull request 自動觸發的測試套件，才是真的在做事；等著人來按下開始的測試套件，只是一份關於「某人本來打算做這些事」的文件。
所以導入時該問的，不是哪個工具的斷言語法比較漂亮，而是哪一個在第一次使用結束時，留下的是一道接進 pipeline 的檢查，而不是螢幕上的一份報告。
直說我們站在哪裡
TestSprite 是為第三個問題打造的。它會打開你正在運行的應用程式，像真實使用者那樣去用，再把壞掉的地方整理成一包、交給你的 AI 代理直接處理。它也會產生測試案例，但那是為了服務驗證，而不是重點本身。
如果你的缺口是信任，那正是它被打造來解決的問題；而最快看清楚的方法，就是把它指向你的 AI 代理這禮拜送出的某個改動，然後讀讀看回來的是什麼。
TestSprite 是為三種中的哪一種而生
第三種。TestSprite 是為這樣的團隊存在的：測試都是綠的、版本還是會出事，而且程式碼越來越多來自 AI 代理，快到沒有人審得完。
具體來說：它會打開你正在運行的應用程式，像真人那樣實際操作一遍，再把壞掉的地方整理成一份前後一致的結果，讓你的 AI 代理可以直接據以行動。案例是從你的產品本身產生、再用自然語言細修，所以覆蓋率不必等某個人挪得出一個下午。步驟記錄的是意圖而不是選擇器，所以一次不改變功能的改版，不會讓整套測試變紅。
它也會產生案例，這碰到了第一個缺口；它的步驟撐得過介面改動，這碰到了第二個。但這些都是為了服務最後的判定，而不是重點本身。如果你真正的抱怨是寫測試很煩，或是現有的測試套件不穩定，那麼圍繞這兩件事打造的產品會更適合你——這句話值得在試用之前就講，而不是試用到一半才講。
一個工具有辦法通吃三種嗎？
有一部分可以，重疊也是真的。但設計的重心藏不住。圍繞產生測試程式碼打造的產品，優化的是覆蓋率；圍繞驗證打造的產品，優化的是判定的品質。問清楚這個產品拿什麼來衡量自己。
AI 測試會取代人工 QA 嗎？
它取代的是重複性的迴歸測試。探索式測試、判斷什麼才重要，以及在定義模糊的流程裡決定「正確」是什麼意思，這些仍然是人的工作；而第二項，一直都是價值所在。
我怎麼知道一個通過的測試真的有意義？
看它斷言了什麼。一次跑完卻沒有走到任何斷言的執行不算通過，而把它回報成通過的工具，比沒有工具更糟。評估期間值得刻意弄壞一個東西，專門測這一點。
會自我修復的測試套件值得信任嗎？
只有在它對介面改動自我修復、對行為改變如實失敗時才值得。問清楚產品怎麼分辨這兩者，別接受「AI 會自己判斷」這種答案。
小團隊該從哪裡開始？
從那個一旦壞掉最讓你難堪的流程開始，並且接上每一次 pull request 自動執行。一個每次都會跑的案例，比五十個只在發版前跑的還有價值。