終結 CI 隨機報警：Flaky Tests 的四大常見根因與防護架構實踐

「這次 CI 又紅了，但別管它，按一下 Re-run 就綠了。」——如果你的團隊在日常 Standup 中經常聽到這句話，說明脆弱測試（Flaky Tests）已經對團隊的品質文化造成了實質破壞。當工程師習慣忽視測試失敗時，真正的嚴重缺陷就會乘虛而入。

根據我們長期為企業診斷測試套件的經驗，超過 90% 的 Flaky Tests 都可以歸類為以下四種架構級缺陷：

1. 硬編碼休眠與非同步等待競態：在 UI 或微服務調用中濫用 `Thread.sleep(3000)` 或 `cy.wait(2000)`。在本地機器可能只需 1 秒，但在高負載的 CI 虛擬機上可能需要 3.5 秒。解決方案是全面改用顯式條件輪詢（Explicit Polling / Polling Assertions），等待特定 DOM 狀態或事件匯流排完成信號。

2. 共享資料庫狀態污染：多個平行運行的測試共用同一個測試資料庫，前一個測試插入的資料未在 `tearDown` 中徹底清理，導致後一個依賴排序或計數的測試莫名失敗。解決方案是落實交易回滾隔離（Transaction Rollback per Test）或使用隨機租戶 ID 隔離資料夾具。

3. 時間與時區依賴：測試代碼中直接調用 `DateTime.now()`，當測試恰好在午夜跨日、閏年或不同時區的 CI 伺服器上執行時，時間計算出現偏倚。解決方案是統一注入時鐘抽象（Clock Provider / Time Mock）。

4. 非確定性集合迭代順序：依賴未排序的雜湊表（如原生 HashMap/Set）遍歷順序進行字串拼接斷言。解決方案是嚴格要求斷言時比對無序集合（Unordered Set Matcher）或在源頭保證排序穩定性。