都100%代碼覆蓋了，還會有什么問題？
很多人看到這個標題時，都會想“你都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(投入產出比)，對于需要快速上線的短期項目，需要注重的是讓測試覆蓋核心功能代碼。如果你的項目是一個長期項目，那么高覆蓋率是非常有必要的，它意味著高可維護性，以及更少的bug。(前提是你的測試采用TDD/BDD方式編寫，我見過將測試代碼寫的一團糟的人，看著他的代碼，我寧愿重新寫一遍)
那么對于一個項目來說，覆蓋率應該達到多少？
其實沒有適用于所有項目的數值，每個項目都應有自己的閾值，但共性是，測試必須覆蓋主要業務場景，代碼的邏輯分支也必須盡可能的覆蓋。
如何改進你的項目代碼覆蓋率？
首先 我們要閱讀和理解項目代碼，找出其中需要測試并且與業務強相關的代碼，結合sonar等代碼質量管理平臺，從代碼編寫規范、復雜度、重復代碼等方面進行代碼重構，進一步提高項目的可維護性與可讀性。
這也意味著重構，重構的同時，你需要更多的測試來保證你重構代碼的正確性。
其次要對code coverage進行度量分析，那么我們應該怎么度量code coverage？
一般來說我們從以下四個維度來度量，如上圖所示:
- 行覆蓋率 （line coverage）：度量被測代碼中每個可執行語句是否都被執行到，但不包括java import，空行，注釋等。
- 函數覆蓋率 （function coverage）：度量被測代碼中每個定義的函數是否都被調用。
- 分支覆蓋率 （branch coverage）：度量被測代碼中每一個判定的分支是否都被測試到。
- 語句覆蓋率 （statement coverage）：度量被測代碼是否每個語句都被執行。
所以行覆蓋率的高低不能說明項目的好壞，我們要從多方面進行思考，一般我們遵循的標準應是： 函數覆蓋率 > 分支覆蓋率 > 語句覆蓋率** 。
代碼覆蓋率最重要的意義在于：
- 閱讀分析之前項目中未覆蓋部分的代碼，進而反推在前期QA以及相關測試人員在進行黑盒測試設計時是否考慮充分，沒有覆蓋到的代碼是否是測試設計的盲點，為什么沒有考慮到？是需求或者UX設計不夠清晰，還是測試設計的理解有誤。
- 檢測出程序中的廢代碼，可以逆向反推代碼設計中不合理的地方，提醒設計/開發人員理清代碼邏輯關系，提升代碼質量。
- 代碼覆蓋率高不能說明代碼質量高，但是反過來看，代碼覆蓋率低，代碼質量絕對不會高到哪里去，可以作為測試自我審視的重要工具之一。
結束語
單元測試的覆蓋率并不只是為了取悅客戶或者管理層的數據，它能夠實實在在反應項目中代碼的健康程度，幫助我們更好的改善了代碼的質量，增加了我們對所編寫代碼的信心。
來自：http://www.techug.com/post/100-percent-test-coverage.html?_=1506652432