撰寫測試程式碼時，不知不覺就會開始執著於覆蓋率數字。
「既然都做了，就應該補到 100%」的心情，我也很能理解。
先說結論，程式碼覆蓋率維持在 70～80% 左右，是實務上最現實的目標；100% 也不代表程式碼沒有錯誤。 接下來會結合我的經驗說明原因。
先看重點摘要
為了方便忙碌的讀者，先整理本文結論。
- 覆蓋率 100% 只代表「每一行都執行過」，不代表「所有情況都經過驗證」。
- 實務上通常建議維持在 70～80% 左右。
- 付款、驗證等重要核心邏輯，可以將目標設定在 90% 以上。
- 比起數字，更重要的是知道「哪些內容尚未測試」。
程式碼覆蓋率 100% 就代表沒有錯誤嗎？
這正是最常見的誤解。
覆蓋率 100% 只表示測試「至少執行過程式碼的每一行一次」。
這不代表已驗證每一行是否正確運作。
舉個例子。以下函式就是測試只執行程式碼，卻沒有正確檢查結果的情況。
func divide(_ a: Double, _ b: Double) -> Double {
return a / b // b如果是 0？測試有執行，但
}
// 這個測試有覆蓋率 100%，但
@Test func divide_只執行_程式碼() {
_ = divide(10, 2) // 不驗證回傳值(#expect)!
}這段程式碼達到了 100% 覆蓋率。
但因為沒有透過 #expect確認結果，實際上什麼也無法保證。
覆蓋率衡量的是「執行了多少」，不是「驗證得多完善」。
這就是不能只看數字就放心的原因。
那麼多少百分比才適當？
我將經歷多個團隊後體會到的實際標準整理成表格。（截至 2026 年的一般實務建議值）
| 程式碼區域 | 建議覆蓋率 | 原因 |
|---|---|---|
| 核心商業邏輯 | 90% 以上 | 付款、驗證等發生錯誤時後果嚴重 |
| 一般服務程式碼 | 70~80% | 成本效益最佳的範圍 |
| UI・檢視層 | 50~60% | 變更頻繁，測試維護成本高 |
| 自動產生・設定檔 | 排除測量 | 測試意義較低 |
Google 也曾公開表示，內部將 60% 視為「可接受的水準」、75% 視為「建議值」、90% 視為「典範」。
雖然沒有唯一正解，但可以把接近 80% 視為大多數團隊合理的目標。
為什麼堅持 100% 反而可能吃虧？
補足最後 20% 所需的努力，遠大於補足前 80%。
若要把例外處理、難以到達的分支和防禦性程式碼全部測試，所需時間會呈指數成長。
更大的問題還在後面。
為了填滿數字，會出現「作秀式測試」。
沒有真正驗證內容、只提高覆蓋率的測試，日後修改程式碼時反而會成為阻礙。
每次重構都得花時間修正沒有意義的測試。
常見問題（Q&A）
Q. 那麼，測量覆蓋率本身沒有意義嗎？
不是。覆蓋率非常適合用來找出「測試完全沒有觸及的區域」。
不要把數字當成目標，而是利用覆蓋率報告確認紅色部分（未執行的程式碼）。
Q. 可以在 CI 中強制設定覆蓋率標準嗎？
可以，但建議採用「新程式碼至少 80%」這類方式。
如果對全部程式碼一律設定很高的標準，團隊會因既有程式碼而感到疲憊。
Q. 覆蓋率好像有好幾種類型？
除了行覆蓋率，也建議一起查看分支覆蓋率。
因為 if/else 等條件分支是否受到完整測試，更接近實際品質。
別被數字追著跑，先問問自己：「這個測試真的在守護什麼嗎？」
覆蓋率 80% 但扎實的測試，比覆蓋率 100% 卻空洞的測試可靠得多。祝你今天也能寫出優質的測試程式碼！