AI 自動化測試的第一種意義：用 AI 自動化你的測試
測試覆蓋由你的產品本身生成，測試步驟以意圖來描述，因此外觀上的變動不會讓它們失效；失敗則以修正者能直接使用的形式回傳。受測的軟體是一般的、具決定性的軟體，AI 存在於工具這一端。
這是這個類別中多數產品在做的事，也是多數團隊真正需要的。
第二種意義：測試內含 AI 的系統
在這裡，產品本身就不具決定性。相同的輸入會產生不同的輸出，「預期值等於實際值」這條路不再走得通，你需要另一種斷言方式。
性質，而非相等
斷言輸出具有正確的結構、有引用來源、長度在範圍內、該拒絕的有拒絕。
分布，而非單次執行
跑一次幾乎說明不了什麼。多跑幾次，並追蹤比率。
回歸，而非絕對值
要問的是這次變更有沒有讓它變差，而不是它是否完美。
兩者共通的那個錯誤
從來沒有確認過檢查會失敗，卻假設通過的檢查代表了什麼。在具決定性的情況下，這會產出一整套永遠不可能亮紅燈的斷言；在不具決定性的情況下，則會產出一套什麼都給高分的評估框架。
刻意弄壞一個東西。只要一分鐘，而這是唯一能證明任一種檢查確實連到它宣稱要衡量之對象的證據。
在混合型產品中劃出界線
大多數內含 AI 的產品，絕大部分其實都不是 AI；有用的做法是明確劃出界線，而不是任由非決定性擴散出去。
圍繞著那項功能的一切都是一般軟體：身分驗證、儲存、速率限制、負責呈現輸出的介面。這些全都能用傳統方式測試；只因為其中一個元件不可預測，就把整個產品都當成不可預測，會讓你損失大量既便宜又可靠的測試覆蓋。
界線之內，就改用性質與比率。輸入進去，輸出會變動，而你要斷言的是它具有正確的結構、引用的是真實存在的東西、該拒絕的有拒絕。把這條界線落在哪裡寫下來，只要一次，就能避免團隊用統計方法過度測試具決定性的部分，或因為精確斷言一直失敗而對 AI 部分測試不足。
你的情況屬於哪一種
如果你的產品問兩次會給出相同的答案，那就屬於第一種情況，你需要的是針對運行中的應用程式自動生成的測試覆蓋。如果不會，那就屬於第二種，你需要的是以性質為基礎的斷言與比率，而不是單純的通過或失敗。
很多產品兩者皆是：一個具決定性的應用程式，裡面放了一項 AI 功能。用一般方式測試具決定性的部分，並把那項 AI 功能當成獨立的問題來處理，而不是硬把同一套做法套用到兩邊。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
不想在本機安裝的人，用儀表板也能做到同樣的事；完整的指令則收錄於 CLI 儲存庫。
兩種路徑，而怎麼選其實取決於誰擁有這條管線。從儀表板連接 GitHub App ，完全不需要對你的儲存庫做任何改動，因為它是針對你的建置流程本來就會產生的部署做出反應。而加入一個 GitHub Actions 步驟，則會把這項檢查放進儲存庫裡，讓它像建置流程的其他部分一樣接受審查。
TestSprite 對應的是哪一種意義
第一種。它用 AI 來驗證一般軟體：測試覆蓋由你的產品生成、測試步驟以意圖描述、針對已部署的應用程式執行，並以程式碼代理能直接據以行動的形式回傳失敗結果。
對於內含 AI 功能的產品，這涵蓋了它周圍的一切，也就是產品的絕大部分：身分驗證、儲存、速率限制、介面，以及使用者實際會走的流程。Auto-Authentication、Dynamic Variables、Dependency Chains 與 Auto-Cleanup 則負責處理 API 這一側的狀態問題。
功能本身需要以性質為基礎的斷言與比率，那是另一套測試框架。明確劃出這條界線，才能讓你在具決定性的那絕大部分上取得便宜又可靠的測試覆蓋，而不是把整個產品都當成不可預測。
TestSprite 做的是哪一種？
第一種。它針對運行中的產品驗證具決定性的應用程式行為，也包括剛好內含 AI 功能的應用程式。
那 LLM 功能要怎麼測試？
用以性質為基礎的斷言反覆執行多次，追蹤的是比率而不是單次結果。拒絕行為、格式與是否有引用，通常比答案品質更容易檢查。
同一套測試能同時涵蓋兩者嗎？
具決定性的部分可以。不具決定性的功能需要自己的測試框架，以及自己對「通過」的定義。
AI 功能的通過率多少才算合理？
以你先前的比率為準。從基準測試借來的絕對目標，很少能套用到你的產品上。
單次執行失敗算是 bug 嗎？
對不具決定性的功能來說，單看一次並不算。比率出現變化才是訊號；單次執行只是雜訊。