都100%代碼覆蓋了，還會有什麼問題？
（圖片來自：http://t.cn/R06rQHi）
很多人看到這個標題時，都會想“你都100%代碼覆蓋了，
再看看用junit寫出的測試代碼：
當我們使用EclEmma或者Jacoco來進行覆蓋測試時，對於這個類，我們將得到100%測試覆蓋率。
一切看起來都那麼的完美，真是這樣的嗎？
好吧，讓我們來來看看另一個測試，當其中一個變數為null時，
好了，你會發現儘管覆蓋率為100%，但程式卻拋出了NullPointerException。
那麼肯定有人會問，這樣的話單元測試覆蓋率的高低都不能作為衡量項目代碼品質的指標，那麼我們要單元測試還有什麼用？
首先，我想我們可能搞錯了測試覆蓋的定義。
我們先聽聽Martin Fowler對於測試覆蓋的定義：
Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.
（圖片來自：https://martinfowler.com/bliki/TestCoverage.
他認為：把測試覆蓋作為品質目標沒有任何意義，我們應該把它作為一種發現未被測試覆蓋的代碼的手段。
所以100%的代碼覆蓋率還值得追求嗎?當然，這應該是每個程式師畢生的追求之一，但是如果從項目角度考慮ROI(投入產出比)，對於需要快速上線的短期專案，需要注重的是讓測試覆蓋核心功能代碼。如果你的項目是一個長期項目，
其實沒有適用於所有項目的數值，每個項目都應有自己的閾值，但共性是，測試必須覆蓋主要業務場景，代碼的邏輯分支也必須盡可能的覆蓋。
首先我們要閱讀和理解專案代碼，找出其中需要測試並且與業務強相關的代碼，結合sonar等代碼品質管制平臺，從代碼編寫規範、複雜度、重複代碼等方面進行代碼重構，進一步提高項目的可維護性與可讀性。
這也意味著重構，重構的同時，你需要更多的測試來保證你重構代碼的正確性。
其次要對code coverage進行度量分析，那麼我們應該怎麼度量code coverage？
一般來說我們從以下四個維度來度量，如上圖所示:
行覆蓋率（line coverage）：度量被測代碼中每個可執行語句是否都被執行到，但不包括java import，空行，注釋等。
函數覆蓋率（function coverage）：度量被測代碼中每個定義的函數是否都被調用。
分支覆蓋率（branch coverage）：度量被測代碼中每一個判定的分支是否都被測試到。
語句覆蓋率（statement coverage）：度量被測代碼是否每個語句都被執行。
所以行覆蓋率的高低不能說明項目的好壞，我們要從多方面進行思考，一般我們遵循的標準應是：函數覆蓋率 > 分支覆蓋率 > 語句覆蓋率**。
代碼覆蓋率最重要的意義在於：
閱讀分析之前專案中未覆蓋部分的代碼，進而反推在前期QA以及相關測試人員在進行黑盒測試設計時是否考慮充分，沒有覆蓋到的代碼是否是測試設計的盲點，為什麼沒有考慮到？是需求或者UX設計不夠清晰，還是測試設計的理解有誤。
檢測出程式中的廢代碼，可以逆向反推代碼設計中不合理的地方，提醒設計/開發人員理清代碼邏輯關係，提升代碼品質。
代碼覆蓋率高不能說明代碼品質高，但是反過來看，代碼覆蓋率低，代碼品質絕對不會高到哪裡去，可以作為測試自我審視的重要工具之一。
結束語單元測試的覆蓋率並不只是為了取悅客戶或者管理層的資料，它能夠實實在在反應專案中代碼的健康程度，幫助我們更好的改善了代碼的品質，增加了我們對所編寫代碼的信心。
語句覆蓋率（statement coverage）：度量被測代碼是否每個語句都被執行。
所以行覆蓋率的高低不能說明項目的好壞，我們要從多方面進行思考，一般我們遵循的標準應是：函數覆蓋率 > 分支覆蓋率 > 語句覆蓋率**。
代碼覆蓋率最重要的意義在於：
閱讀分析之前專案中未覆蓋部分的代碼，進而反推在前期QA以及相關測試人員在進行黑盒測試設計時是否考慮充分，沒有覆蓋到的代碼是否是測試設計的盲點，為什麼沒有考慮到？是需求或者UX設計不夠清晰，還是測試設計的理解有誤。
檢測出程式中的廢代碼，可以逆向反推代碼設計中不合理的地方，提醒設計/開發人員理清代碼邏輯關係，提升代碼品質。
代碼覆蓋率高不能說明代碼品質高，但是反過來看，代碼覆蓋率低，代碼品質絕對不會高到哪裡去，可以作為測試自我審視的重要工具之一。
結束語單元測試的覆蓋率並不只是為了取悅客戶或者管理層的資料，它能夠實實在在反應專案中代碼的健康程度，幫助我們更好的改善了代碼的品質，增加了我們對所編寫代碼的信心。