lcov是建立在gcov之上的一个可以生成html代码覆盖率报告的工具，最近公司开始尝试引入代码覆盖来提高产品质量，lcov很好地满足了我们的需求，虽然lcov本身支持生成代码覆盖率的diff报告，但是跟我们的需求不太符合。
首先说一下我们的情况，我们有一套自动化回归测试集，可以看做是我们测试的全集。现在已经完成了基于这个回归测试集的代码覆盖率报告，这其中肯定有 某些行没有被覆盖到的，如何评估这些没有被测试过的行的风险呢？最开始是DEV跟QA一起review，由开发来评估这些没有被测试过的代码。最近提出了 一个新的思路，就是用Production的代码覆盖和本地回归测试的代码覆盖做一个diff，着重看一下那些在Production里面实际被执行过的 代码中，有哪些是我们本地回归测试所没有覆盖的，因为这些“裸奔”的代码才是最危险的代码。
查一下文档，lcov在生成html报告的时候可以做这个事情，在genhtml的时候使用参数“–baseline-file baseline-file”，指定了这个参数以后就会在用输入的tracefile里面的counter来减去baseline-file里面的 counter，完成这个减法计算以后再生成报告。可以用Local测试的数据作为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报告可以给我们提供一些有针对性的信息。