行覆蓋率 90% 為何依然頻繁出包？解構虛假覆蓋率與變異測試實踐

在諮詢過眾多台灣軟體研發團隊的過程中，我們最常聽到的管理層抱怨之一就是：「我們 CI 上的覆蓋率報告明明顯示有 88%，為什麼每次一上線還是會在邊界條件出現 NullPointerException 或金額計算邏輯錯誤？」

這個問題的根本原因在於：傳統的行覆蓋率（Line Coverage）與分支覆蓋率（Branch Coverage）僅衡量了「哪些代碼被 CPU 執行過」，卻從未驗證「測試代碼是否做出了有價值的斷言（Assertions）」。在許多代碼庫中，充斥著為了迎合 KPI 而寫出「只呼叫函數、卻不驗證返回值與副作用」的幽靈測試。

要打破這種虛假安全感，工程團隊必須轉向以「領域模型狀態轉移」為核心的覆蓋率評估標準。首先，將代碼庫劃分為核心業務領域（Domain Logic）、適配層（Adapters）與基礎設施（Infrastructure）。高覆蓋率的要求應嚴格聚焦於具有複雜決策路徑的核心領域，而非無業務邏輯的 DTO 或標準框架配置。

其次，引入變異測試（Mutation Testing）。變異測試會在編譯期間對你的業務代碼注入微小的故障（例如將 `>` 改為 `>=`、反轉布林條件、將運算符從 `+` 改為 `-`），然後執行現有測試套件。如果測試套件依然全部通過，說明你的測試根本無法察覺該處代碼的語意變更，這被稱為「存活變異（Survived Mutants）」。

藉由針對存活變異進行有針對性的斷言補強，團隊能將有限的工程資源精準投注在最脆弱的邏輯盲點上，徹底終結覆蓋率數字遊戲。