什麼會拉低 UI 自動化測試的比例
選擇器
一次完全不影響功能的改版，就足以讓整套測試變紅。
多數維護時間其實都花在這裡。
等待
固定延遲既慢又一樣不穩定。正確的等待必須知道自己在等什麼。
多數不穩定的狀況都源自這裡。
靠人工撰寫的覆蓋範圍
你涵蓋到的只是有人寫過的部分，也就是比較有意思的流程，而不是真正會出問題的那些。
選擇器與等待造成的失敗都不是 bug。而每一次這樣的失敗，都會消耗掉團隊一點點願意去看下一個紅燈建置的意願。
一套測試死去的那一刻
事後回頭看通常都認得出來：就是某個人說「重跑一次就好」而且說對了的那一週。從那之後，重跑就變成面對任何失敗的第一反應，而真正的回歸問題會被一再重跑，直到它碰運氣通過，或是被隔離起來。
沒有人會下定決心不再信任這套測試，信任是一點一點被侵蝕掉的。
守住這個比例
先修好不穩定的測試，再加新的。 不討喜，但正確。在一套大家都已經忽略的測試裡再加一個新測試，毫無價值。
隔離要張揚，不要偷偷來。 被略過的測試應該被看見，而且要有負責人，否則那份略過清單就會變成測試的墳場。
把重跑當成一項發現。 如果一個測試需要重跑，那就是測試本身或環境有問題。把它記錄下來，而不是就這樣放過。
結構性的部分
紀律能處理選擇器和等待，卻處理不了第三項成本：覆蓋範圍受限於有人能寫出多少測試，而產品成長的速度遠比這快，特別是當大部分程式碼都來自 coding agent 的時候。
把步驟寫成意圖，而不是寫成穿過 DOM 的路徑，可以直接消除很大一部分的選擇器失敗，而那正是影響這個比例最大的單一因素。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板裡也有同樣的設定方式。CLI 其餘的功能則收錄在 CLI 儲存庫。
把糟糕的比例救回來
如果這套測試已經到了大家只會重跑、不會追查的地步，那麼從現在起要求紀律並不能解決問題，因為既有的雜訊會持續強化這個習慣。要救回來，必須刻意重置一次。
把最近五十次失敗拿出來，逐一歸類為真實問題、選擇器、時間點或環境。這一個小時會告訴你，自己真正面對的是三項成本中的哪一項，而且問題通常集中在某一類，而不是平均分布。針對那一類，在整套測試裡一次修好，而不是等測試失敗了再一個個修。
接著把所有還在失敗的測試隔離起來，各自指定負責人與日期，讓剩下的測試維持全綠。一套小而全綠、大家願意相信的測試，價值高於一套大而滿江紅、大家早已學會忽略的測試；而且只有在這個狀態下，比例才有可能改善。
在失敗代價最低的地方執行
在每一個 pull request 上執行，讓失敗指向單一一次變更，而不是一整週的變更。
GitHub App 是一個你在 TestSprite 儀表板裡設定的 webhook。它會監聽你的 pipeline 本來就會產生的部署事件，所以你的儲存庫完全不必更動。
GitHub Actions 則是把這個步驟放進你自己的工作流程中，從終端機完成設定。
TestSprite 如何守住這個比例
方式很直接：拿掉假性失敗最大的來源。測試步驟寫的是意圖而不是定位器，所以那些造成多數選擇器失效的外觀調整，不會讓建置變紅。等待由系統處理，不再是逐個測試慢慢調整的工作，剩下的問題也就解決了大半。
覆蓋範圍是從你的產品產生，再用自然語言調整，所以擴大測試套件不代表維護成本要等比例增加，而那正是平常逼著團隊在覆蓋範圍與信任之間取捨的原因。
最後得到的，是一套失敗會讓人意外的測試。在那樣的狀態下，大家看到失敗會去追查而不是重跑；也只有在那樣的狀態下，覆蓋範圍才能持續成長，而不會讓整套測試悄悄淪為裝飾品。
我們該期待多高的通過率？
高到紅燈建置會讓人意外的程度。如果失敗變成家常便飯，那這套測試回報的是它自己的狀況，而不是產品的狀況。
不穩定的測試該怎麼修？
先找出問題是出在選擇器還是等待。選擇器需要穩定的定位依據，等待則必須等的是狀態。第三種情況是環境本身真的不穩定，那不是改測試能解決的。
刪掉舊測試值得嗎？
值得。一個沒有人相信、也沒有人維護的測試，只有成本沒有效益。刪掉它比略過它更好。
這套測試應該擋住合併嗎？
等比例健康之後，應該。在那之前，用一套不可信的測試去擋合併，只會訓練大家學會繞過它。
這該怎麼衡量？
追蹤有多少失敗最後證實是真的問題。如果沒有人知道這個數字，那本身就是一項發現。