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报告可以给我们提供一些有针对性的信息。