UI 自動化工具的三大類別
程式碼框架。 由你用真正的程式語言撰寫測試。 預設前提： 有時間撰寫與維護測試的工程師。
錄製與低程式碼。 由人在編輯器中建立測試流程。 預設前提： 有人的職責就是建立測試流程。
Agent 驅動。 測試覆蓋由系統產生，再以自然語言調整。 預設前提： 你會審閱並非自己撰寫的測試覆蓋。
哪一個前提最常失準
第二個。低程式碼平台是圍繞著一個測試職能而設計的，而許多團隊早已沒有這個職能。平台本身沒問題，授權費也付了，但沒有人在建立測試流程，於是覆蓋率在最後一位測試人員離職的那個月就停止成長。
第一個前提則是慢慢失效。工程師確實寫得出測試，但這件事會和交付功能互相排擠，因此測試套件在第一季成長，之後就停滯。
比功能比較表更有用的問題
誰來寫第兩百個測試？ 前十個會在評估期間寫完，要問的是第六個月的情況。
UI 改版時會發生什麼事？ 這就是持續發生的成本，而各類工具的答案差異極大。
對負責修的人來說，一次失敗看起來是什麼樣子？ 這個角色越來越常是 coding agent，而它無法解讀螢幕截圖。
一次根本沒跑到斷言的執行，會不會被回報為通過？ 值得刻意測試一下，因為答案有時候是會。
比較表上看不到的成本
上述每一類工具都有一項持續成本，廠商不會去量化它，因為它取決於你而不是他們：決定要涵蓋哪些範圍的成本。
用程式碼框架時，得有人把測試寫出來，這表示有人事先決定了這個測試該存在。低程式碼編輯器也一樣。改用自動生成的覆蓋之後，決策這件事就移到審閱測試計畫上，這比較快，但並非零成本，而且經常被略過，於是產生「沒人讀過的測試覆蓋」這種失敗模式。
不論你選哪一種，都要明確為它編列時間。每週有人花一小時檢視哪些有涵蓋、哪些沒有，差別就在於你的測試套件反映的是現在的產品，還是十八個月前剛好方便自動化的那些東西。
該怎麼評估
刻意弄壞一個地方。放進一個真實的迴歸問題，例如存檔不再真的保存下來，然後看每個候選工具回報了什麼：它會不會判定失敗、失敗訊息有沒有指出落差在哪，以及負責修的人能不能直接從那份輸出開始動手。光是這一個練習，就比一個月的功能比較更有參考價值。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，儀表板也能做到同樣的事。命令列能做的其他所有事情，都收錄在 CLI 儲存庫。
有兩條路徑，而選擇的重點其實在於誰擁有這條 pipeline。從儀表板連接 GitHub App 完全不需要改動你的儲存庫，因為它是針對你的建置流程本來就會發出的部署事件做出反應。而加入一個 GitHub Actions 步驟，則是把這道檢查放進儲存庫裡，讓它像建置流程的其他部分一樣被審查。
TestSprite 的預設前提是什麼
前提是你會審閱並非自己親手撰寫的測試覆蓋。這就是取捨：不需要有人擔任撰寫者，交換條件是要有人讀過測試計畫並加以修正。
具體來說，測試案例是從你的產品生成的；步驟以意圖的形式表達，因此改版後依然有效；而失敗會以「嘗試做什麼、應用程式實際做了什麼、兩者在哪裡分歧」的形式回報，coding agent 和人一樣都能據此動手處理。
對於沒有專職測試職能的團隊來說，這個前提比另外兩個都更容易滿足，因為審閱測試計畫每週只要一小時，而撰寫一整套測試需要一個專職角色。如果你確實有這個角色，程式碼框架也許更適合你；誠實的選擇方式，是問自己的團隊在一年之內真正能滿足哪一個前提。
可以混用不同類別嗎？
可以，而且多數團隊最後都會這麼做。用程式碼框架處理刻意指定的流程、用生成的覆蓋來取得廣度，是常見的分工方式。
開源就夠了嗎？
通常是夠的，而且授權從來就不是成本所在。成本在於撰寫與維護，這一點開源並不會改變。
那錄製與重播呢？
建立很快，維護很貴，因為錄製下來的是一條路徑，而不是一個意圖。適合用在一次性的問題重現。
評估期應該進行多久？
久到足以經歷一次改版或一個真實的迴歸問題。兩者都沒遇上的試用，等於沒有測到真正重要的地方。
最常見的錯誤是什麼？
照著你希望擁有的團隊來選。要選的是六個月後真正在維護這套東西的那個團隊。