北京
一套全綠的CI流水線，確實讓人安心。構建完成，單元測試通過，瀏覽器套件100%及格，這個拉取請求可以合并了。但發布依然可能炸掉。
這種反差一直存在，只是現在出現得更頻繁了。前端系統越來越動態，團隊對生成代碼、特性開關、第三方服務、異步組件和AI輔助開發的依賴都在加深。問題不是測試變差了，而是我們一直在讓一個二進制的測試結果，回答一個更大的問題：這個版本安全到可以發布了嗎？僅靠通過率，回答不了。
通過率丟掉的東西太多了。假設有個套件包含500個瀏覽器測試，495個通過了。99%的通過率聽起來很漂亮，但這個數字對發布風險幾乎什么都沒說。那五個失敗可能是已知的不穩定測試，發生在一個無關緊要的內部設置頁面；也可能是支付流程、登錄認證或賬號恢復模塊的新故障；可能是基礎設施問題，導致關鍵測試根本沒跑起來；可能是在應用進入損壞狀態后，斷言才失敗的；還有可能是重試了三次才勉強通過的測試。這些情形，不應該指向同一個發布決策。
對于集成了AI的系統，這個問題更棘手。給AI驅動功能設計一個有用的CI信號，不能只看最終頁面有沒有渲染出來，還需要評估輸出變異性、降級行為、響應延遲、安全控制，以及這個功能能不能從不完整甚至無效的響應里恢復過來。所以團隊應該考慮為AI測試可靠性專門搭建一個CI信號，而不是繼續信賴通過率。目標不是替換通過或失敗這種二元判斷，而是把它們裝進上下文里。
真正有用的發布信號，得把幾種證據縫合起來看。哪些產品區域發生了變化，哪些測試覆蓋了這些區域，有沒有關鍵測試被跳過，通過的測試是不是靠重試撐起來的，失敗模式是全新的還是已經排查過的，視覺或行為上的變化是否在預期之內，生產環境的錯誤信號是在變好還是在惡化，測試環境能不能代表線上真實情況，當前收集的證據夠不夠支撐一次徹底的失敗排查。這么一來，CI就從勾選框變成了一個證據源。
一個實際可上手的起點，是給AI輔助的前端變更做一份發布風險檢查清單。哪怕是一份很輕量的清單，也能迫使團隊去思考改了什么、怎么驗證的，以及超出主線路徑以外還可能崩在哪里。這份清單不必膨脹成龐大的審批流程，它可以很薄地貼到現有的拉取請求流程上。
最危險的CI結果，有時候不是測試失敗，而是測試根本沒跑。條件性CI規則、錯誤的測試過濾器，都可能制造這種假象。綠色對勾會掩蓋不完整的執行，讓一段從來沒被驗證過的代碼順利滑進發布管道，而所有人還以為一切正常。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
