lcov是建立在gcov之上的一個可以生成html代碼覆蓋率報告的工具，最近公司開始嘗試引入代碼覆蓋來提高產品質量，lcov很好地滿足了我們的需求，雖然lcov本身支持生成代碼覆蓋率的diff報告，但是跟我們的需求不太符合。
首先說一下我們的情況，我們有一套自動化回歸測試集，可以看做是我們測試的全集�，F在已經完成了基于這個回歸測試集的代碼覆蓋率報告，這其中肯定有某些行沒有被覆蓋到的，如何評估這些沒有被測試過的行的風險呢?最開始是DEV跟QA一起review，由開發來評估這些沒有被測試過的代碼。最近提出了一個新的思路，就是用Production的代碼覆蓋和本地回歸測試的代碼覆蓋做一個diff，著重看一下那些在Production里面實際被執行過的代碼中，有哪些是我們本地回歸測試所沒有覆蓋的，因為這些“裸奔”的代碼才是最危險的代碼。
查一下文檔，lcov在生成html報告的時候可以做這個事情，在genhtml的時候使用參數“–baseline-file baseline-file”，指定了這個參數以后就會在用輸入的tracefile里面的counter來減去baseline-file里面的counter，完成這個減法計算以后再生成報告�？梢杂肔ocal測試的數據作為basefile，兩者一減，在報告里面那些cover的行，就是Production上跑到的代碼而回歸測試集沒有能覆蓋的部分。但是如果直接用的話，結果可能不是我們想要的，因為我用了genhtml這樣的一個特性：“Note that when a count for a particular line in baseline-file is greater than the count in the tracefile, the result is zero.”。
舉個例子，如果我們的代碼被執行了若干次：
| Code | A | B | C | D |
| Local | 0 | 40 | 50 | 60 |
| Production | 50 | 50 | 50 | 50 |
| Actual result | 50 (local uncover) | 10 (local uncover) | 0 (covered) | 0 (covered) |
| Expected | local uncover | covered | covered | covered |
主要看第三列，B這行代碼。如果在Local測試中某行代碼被執行了40次，而同一行代碼在Production被執行了50次，那么diff出來的結果是這行代碼沒有被覆蓋，而實際的結果是回歸測試已經覆蓋到了。解決思路很簡單，我們可以讓Local的counter增加N倍，這個N要足夠大，就能避免這種情況的發生了。當我們按照正常操作生成一個tracefile的時候，接下來就用“–add-tracefile tracefile” 來把這個tracefile的counter加上去，
lcov -a mytest.info -a mytest.info -o mytest_2x.info
lcov -a mytest_2x.info -a mytest_2x.info -o mytest_4x.info
寫個shell腳本幫你干這個事情，不到半小時就能把counter增加2的N次方倍。最后以這個放大了counter的tracefile作為基線，生成的diff report
genhtml -o diffresult –num-spaces 4 –legend -b mytest_1024x.info prod.info
最終結果：
| Code | A | B | C | D |
| Local | 0 | 40960 | 51200 | 61440 |
| Production | 50 | 50 | 50 | 50 |
| Actual result | 50 (local uncover) | 0 (covered) | 0 (covered) | 0 (covered) |
| Expected | local uncover | covered | covered | covered |
什么樣的代碼最危險?沒有被測試過的代碼是最危險的。Production和regression test的代碼覆蓋率diff報告可以給我們提供一些有針對性的信息。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
