Martin Fowler（重構那本書的作者）曾經寫過一篇博客來討論這個問題俏拱，他指出：把測試覆蓋作為質量目標沒有任何意義措伐，而我們應該把它作為一種發(fā)現未被測試覆蓋的代碼的手段。
代碼覆蓋率的意義
1.分析未覆蓋部分的代碼芙贫，從而反推在前期測試設計是否充分棒搜，沒有覆蓋到的代碼是否是測試設計的盲點，為什么沒有考慮到嘿般？需求/設計不夠清晰段标，測試設計的理解有誤，工程方法應用后的造成的策略性放棄等等炉奴，之后進行補充測試用例設計逼庞。
2.檢測出程序中的廢代碼，可以逆向反推在代碼設計中思維混亂點瞻赶，提醒設計/開發(fā)人員理清代碼邏輯關系赛糟，提升代碼質量。
3.代碼覆蓋率高不能說明代碼質量高共耍，但是反過來看虑灰，代碼覆蓋率低，代碼質量不會高到哪里去痹兜，可以作為測試自我審視的重要工具之一穆咐。
黑盒系統(tǒng)測試的困境
測試的工作產出相對于研發(fā)并沒有那么直觀，測試過程中經常會有一些針對質量與效率的靈魂拷問字旭，作為測試如何才能把工作做的又快捷对湃，又精準，剝開這個黑盒的掩蓋遗淳，我們在做功能測試的時候如果能看清楚哪些代碼是走到的拍柒，哪些代碼是沒有走到，這樣不但可以減少重復無用的盲目測試屈暗，而且也可以提升測試精準性拆讯。
聊到這里有的同學可能會想到自動化測試，為什么不通過自動化測試來增加業(yè)務覆蓋呢养叛，自動化測試作為一把雙刃劍种呐，當腳本數量達到一定程度一定會帶來維護成本的增加，反而會拖累整個測試團隊的效率弃甥，自動化測試我們會優(yōu)先考慮核心業(yè)務場景的覆蓋爽室，讓自動化測試成為一個防彈馬甲，而不是一個全身防護的裝備淆攻。
系統(tǒng)測試應用增量代碼覆蓋率
談到代碼覆蓋率我們一般會想到單元測試阔墩，覆蓋率一般會從包嘿架、文件、類啸箫、代碼行的維度去監(jiān)控耸彪。按照測試分層的理論，集成測試屬于UI這邊層面的筐高，這一層處在塔尖搜囱，覆蓋率是最小的丑瞧，如果想在一個版本測試中實現全量的覆蓋率監(jiān)控柑土，那無疑是一個實現不了的愿景。
既然實現不了全量绊汹，那能否實現增量的稽屏，我們假設master的分支（生產線上運行的分支）是全部覆蓋過的，可不可以把焦點放在增量代碼上呢西乖，我們只關注release分支跟master分支git diff之后的代碼變更呢狐榔？
由于我們增量代碼覆蓋率監(jiān)控依賴的開源項目jacoco，覆蓋率是只針對java問題才有的获雕，所以我們按照如下的策略來對代碼進行增量的對比薄腻。
增量代碼對比出來之后我們只需要在覆蓋率解析環(huán)節(jié)只顯示增量代碼的覆蓋率，我們就可以輕松的監(jiān)控到系統(tǒng)測試過程中的代碼覆蓋情況届案。如下是基于jenkins pipline的實踐案例庵楷。
基于jenkins的實現相對來說還是比較粗糙的，感興趣的小伙伴可以按照如下思路在測試平臺來實現代碼的實時染色楣颠。
