AI 測試代理程式的不同之處
從你的產品推導出涵蓋範圍。 來自規格、需求文件，或探索執行中的應用程式，而不是來自某個人剛好記得要寫下來的東西。
以意圖表達步驟。 「開啟設定頁面」，而不是一條穿過 DOM 的路徑，這就是外觀改版通常不會把它弄壞的原因。
回傳修復者用得上的失敗結果。 嘗試了什麼、實際發生了什麼、兩者在哪裡分歧，並以另一個代理程式能據以行動的形式呈現。
失效模式一：只求滿足檢查
當你要求代理程式讓測試通過，它可能會走最短的那條路，而調整檢查有時候比修好產品更短。這不是惡意，而是目標本身沒有說清楚。
防範的成本很低。在每個檢查裡指名一個具體、可觀察的對象，並刻意弄壞某個東西，確認這個檢查真的會變紅。不會失敗的檢查，什麼也保護不了。
失效模式二：沒有人讀過、卻信心滿滿的涵蓋範圍
代理程式會很樂意產出兩百個測試案例。數量看起來像是進展，而沒有人審閱過的涵蓋範圍，就是沒有人能依賴的涵蓋範圍，因為你並不知道它到底斷言了什麼。
讀測試計畫，而不是讀程式碼。刪掉那些管理性質的路由，補上沒有寫在任何地方的產品規則，並且把它當成一個 pull request 來看待。
它仍然做不到的事
了解你的商業規則
兩個折扣同時適用時該怎麼處理，是一個決策，不是推導得出的結果。
想出濫用情境
它會檢查授權，卻不會想到某人可以鑽漏洞操弄的流程。
修好壞掉的環境
來自基礎架構的不穩定，仍舊是不穩定。
有效率地審閱一份計畫
用這種方式工作，最主要的持續成本是去讀你自己沒寫的涵蓋範圍，而讀得馬虎，正是上述兩種失效模式的來源。有一個快速的方法。
只讀斷言。第一輪完全跳過步驟，因為步驟是機械性的，判斷力則落在斷言裡。任何在產品壞掉時仍然成立的斷言，就是該修的地方；而當你只盯著斷言看，它們很容易被認出來。
接著掃過清單，找的是缺了什麼，而不是有什麼。產生出來的計畫，對已經存在的端點總是很完整，對只活在某個人腦袋裡的規則則總是沉默。補上三條那樣的規則，價值高過修正三十個步驟。
開始使用
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板裡也有同樣的設定流程。CLI 其餘的功能都在 CLI 儲存庫。
觸發時機比機制更重要。把它接上你的部署事件，就代表每一次變更都會被檢查，而不需要任何人特地決定要檢查； GitHub App 從儀表板做到這件事，而一個 GitHub Actions 步驟則從你的工作流程內部做到這件事。
TestSprite 作為代理程式做了什麼
它從你的來源資料與執行中的應用程式推導出涵蓋範圍，以意圖表達步驟，讓外觀上的改動不會把它們弄壞，對已部署的應用程式執行測試，並把失敗結果回報為：嘗試了什麼、實際發生了什麼，以及兩者在哪裡分歧。
安裝過程會把驗證技能裝進你已經在用的編碼代理程式裡，因此這一切都發生在程式碼正被寫出來的那個循環之內，而不是某個人要記得去做的獨立步驟。
價值在於循環被閉合。一次變更會對著執行中的產品接受檢查，失敗會以代理程式能據以行動的形式回來，而修正則由產生它的那套推理以外的東西來確認。留在你身上的，是讀計畫、決定「正確」是什麼意思，那是每週一小時的事，而不是一個職位。
這和測試產生器有什麼不同？
產生器產出程式碼，之後由你來執行與維護。代理程式則還會執行它、讀取結果，並且能夠反覆迭代，而這正是讓循環閉合的關鍵。
沒有規格也能運作嗎？
可以，透過探索執行中的應用程式即可；不過有規格或需求文件，產生出來的第一份計畫會更好。
它需要多少審閱？
在第一次執行前、以及每次大規模重新產生之後，都讀一次計畫。在這之間，就像審閱程式碼那樣審閱新增的測試案例。
有什麼能避免費用失控？
每次執行都會消耗點數，所以在長時間的工作階段開始前先設好預期。擁有驗證工具的代理程式就會去用它，這正是重點，也值得為它編列預算。
它會取代 QA 工程師嗎？
它取代的是重複性的那一半。定義什麼叫正確，以及對抗性的思考，仍然是人的工作，而那本來就是更有價值的一半。