軟體測試中的 AI 真正改變了什麼
撰寫測試不再是瓶頸。 過去大部分的工夫，都花在把已知的行為翻譯成測試程式碼。如今這件事幾乎不花成本，限制也就轉移到「決定哪些事情應該成立」上。
修好問題的往往不是人。 當接手失敗結果的是編碼代理（coding agent），輸出格式就比儀表板更重要。截圖已經不算是交付物。
哪些沒有改變
決定什麼叫正確
這仍然是產品層次的判斷。沒有任何模型知道你的業務承諾了什麼。
測試資料與環境
這仍然是測試套件失敗時最不起眼、也最常見的原因。
測試不穩定
自適應執行消除了選擇器的脆弱問題。不穩定的環境依然不穩定。
哪些變得更難
程式碼的產出量上升了，審查的能量卻沒有。這才是目前大家關注軟體測試中的 AI 背後真正的危機，而它不會因為產生更多測試就解決。解法是對行為有一個獨立的檢查，因為以與程式碼相同的假設所產生的測試，只會同意程式碼的說法。
第二個新風險比較隱微：當你要求代理讓某項檢查通過，它可能只是滿足了那項檢查，而不是修好產品。模糊的檢查會招來這種行為；具體、可被推翻的檢查則不會。
值得養成的習慣
刻意弄壞某個地方，確認檢查真的變成紅燈。這只要一分鐘，卻是唯一能證明一項檢查——不論是產生的還是手寫的——真的連到你的產品上的證據。
最快把人帶偏的指標
覆蓋率百分比一直只是個不完美的替代指標，而自動產生測試更是徹底把它弄壞了。這件事之所以重要，是因為大多數團隊回報的仍然是這個數字。
這個數字量的是哪些程式碼行被執行過，從來就沒有量過是否斷言了任何有意義的事情；而當測試是大量產生出來的，兩者的落差會急遽拉大：要做出一套碰到九成程式碼、卻幾乎沒斷言任何重要事項的測試，一點也不難。覆蓋率上升，圖表很好看，漏到線上的缺陷卻紋風不動。
有兩個數字沒有這個問題：有多少比例的缺陷是在發布前被找出來的，以及從失敗到修好要花多久。這兩個都無法靠多寫測試灌水，都要真的有所改善才會動，也都比較難蒐集——這正是團隊寧可繼續回報覆蓋率的原因。
從哪裡開始
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
不想在本機安裝的人，用儀表板也能做到同樣的事；完整的指令一覽則放在 CLI 儲存庫。
如果建置流程由另一個團隊負責， GitHub App 是阻力最小的方式：它就是一個 webhook，不會更動你的儲存庫，並且會在你的建置回報新版本上線時觸發。如果你希望檢查結果直接顯示在儲存庫裡，那麼一個 GitHub Actions 步驟就能做到。
TestSprite 針對變得更難的那部分做了什麼
量的問題，正是它被打造出來要處理的。覆蓋範圍是從你的產品自動產生的，而不是由人撰寫，因此不會與功能開發搶工程時間；而且它會在每次變更時執行，而不是等有人想起來才跑。
獨立性的問題，則靠檢查所在的位置來解決。它是拿你描述的行為去操作已部署的應用程式，而不是依循程式碼自己的假設；正因如此，當實作與它的單元測試都出自同一個代理時，它給出的資訊才有價值。
沒有改變的事情在這裡一樣沒有改變：什麼叫正確仍然由你決定，測試資料與環境也仍然是你的。你得到的是：覆蓋範圍不再追不上程式碼產出的速度。
AI 會取代測試人員嗎？
它取代的是這份工作機械性的那一半。決定什麼叫正確，以及用對抗的角度去思考產品可能被如何濫用，只會更有價值，而不是更沒價值。
自動產生的測試可信嗎？
在結構與狀態方面，大致可信。但某個值對不對，它們只是繼承了程式碼原本的假設，所以仍需審查。
這代表測試會變少嗎？
通常是覆蓋範圍變多、手寫的測試變少。你投注心力的比重，會從撰寫轉向審查。
團隊最常犯的最大錯誤是什麼？
量覆蓋率，而不量漏到線上的缺陷。用產生的方式做測試，覆蓋率馬上就會上升，卻幾乎說明不了什麼。
人的判斷在哪些地方仍然最重要？
模糊的需求，以及對商業邏輯的濫用。這兩件事關乎的都是產品，而不是程式碼。