自主軟體測試：四個層級的誠實說明

自主軟體測試的四個層級

• 1. 輔助撰寫。 你說要測什麼，它把程式碼寫出來。確實省下時間。但所有決定還是在你身上。

• 2. 自動產生涵蓋範圍。 它會從規格或執行中的應用程式，提出該測些什麼。你負責審閱這份計畫。這是多數產品真正所在的位置。

• 3. 自我維護。 產品改變時，涵蓋範圍會跟著調整，不需要有人動手修。前提是能分辨哪些是刻意的變更，哪些是功能退化。

第四階是 閉迴路：它偵測到失敗，把證據交給編碼代理，再驗證修正是否成立。這件事今天確實存在，但形式很窄，僅限於有明確重現步驟的行為性缺陷，也不延伸到任何需要產品決策的情況。

每一階對你的要求

• 第一階： 知道要測什麼。所有判斷都還在你身上。

• 第二階： 審閱一份計畫。比自己寫快，但工作量不是零；跳過這一步，就會得到一整套沒人看得懂的涵蓋範圍。

• 第三階： 判定什麼算是刻意的變更。工具無從得知某段流程是被刻意重新設計過的。

• 第四階： 把「正確」定義得夠精確，讓修正不需要你也能被驗證。

值得注意的是，往上爬並不會讓人的工作消失，只是讓它往上層移動：從打字轉向決策。而決策既更有價值，也更難交給別人。

沒有人拿來行銷的那道天花板

沒有任何一階能免除「決定什麼叫正確」這件事。工具可以推導出某個端點存在、某個欄位是字串；但它推導不出兩種折扣不該疊加，因為那是一條商業規則，存在於某個人做過的決定裡。

任何暗示情況並非如此的產品，都是把第二階講成第四階。

把產品定位到正確階數的幾個問題

廠商都會把自己描述在還撐得住的最高那一階，所以手邊值得準備幾個問題，把他們精準定位。

誰決定要測什麼。如果答案是你，那不管測試是怎麼寫出來的，都是第一階。

當介面改了、行為沒改，會發生什麼事。如果要人去修測試，那是第二階；如果測試撐得住，是第三階；如果測試撐得住，而且在行為真的改變時仍然會失敗，那才是做得徹底的第三階，這種比較少見。

還有，失敗之後會發生什麼事。如果結果只是送進儀表板給人看，那就到此為止。第四階的意思是，輸出能被真正修問題的那一方直接使用，而且修正不需要人在中間轉述就能被驗證。依序問完這三題只要五分鐘，得到的定位會比任何功能列表都誠實得多。

開始使用

如果你不想安裝任何東西，儀表板也能做同樣的事。命令列能做的其他一切，全都收在 CLI 儲存庫。

如果這條管線歸另一個團隊管， GitHub App 是阻力最小的做法：它就是一個 webhook，不會改動你儲存庫裡的任何東西，並在你的建置回報新版本上線時觸發。如果你希望這項檢查改為顯示在儲存庫裡，一個 GitHub Actions 步驟就能做到。

TestSprite 落在階梯的哪一階

整體是第二階，遇到行為變更是第三階，第四階則是那個很窄的形式：失敗會以編碼代理可以直接處理的形式回傳，而修正是由同一項檢查來驗證，不是由產出這項修正的推理來驗證。

具體來說：涵蓋範圍從你的產品產生出來，再以白話語言微調；測試步驟記錄的是意圖，所以外觀層面的變動不會弄壞它們；而驗證技能會安裝進你原本就在用的編碼代理裡，讓這個迴路發生在工作真正進行的地方。

留在你身上的，就是上面說的那道天花板：為一條模稜兩可的規則決定什麼叫正確。天花板以下的一切都會往前移動，而好處是：涵蓋範圍不再受限於有人能寫出多少測試。