代码覆盖工具gcov, lcov的一些使用经验

使用gcov和lcov做代码覆盖有一段时间了,期间走了一些弯路,算是一些经验教训。

  • gcov可以对shared object进行代码覆盖信息收集。

之前的一篇文章说过,gcov不能收集.so的代码覆盖率信息,其实这个是错的。

如果是C++程序,在CXXFLAGS中加入-fprofile-arcs -ftest-coverage 作为编译选项,并且在LDFLAGS中加入-lgcov作为链接选项。如果没有-lgcov选项编译出来的.so文件在动态加载的时候会提示类似 undefined reference to ‘__gcov_merge_add’ 或者 undefined reference to ‘__gcov_init’这样的错误。

如果是C程序,在CFLAGS中加入-fprofile-arcs -ftest-coverage 作为编译选项,也是在LDFLAGS中加入-lgcov作为链接选项,就OK了。跑测试的时候跟正常测试一样,最后把收集到的.gcda文件处理一下就能得到代码覆盖率报告

  • 用lcov处理.gcda文件的时候,在处理某些文件的时候hang了。

对于这个问题,不知道根本原因是什么,可能是那个文件的某行代码触发了bug,我对此是workaround了一下。lcov本身是一堆Perl脚本,打开它,通常在这里“/usr/bin/geninfo”,然后找到这行,注释掉

push(@gcov_options, “-a”) if ($gcov_caps->{‘all-blocks’});

  • genhtml的一个参数:-f, –frames

Use HTML frames for source code view。这样会在每个结果页的左边生成一个缩略图,review代码的时候很方便。但是,如果你的项目里面用到了一些第三方的库,而那些第三方的库没有提供完整的源代码,那么使用这个参数就会出现问题。

gd-png: fatal libpng error: Image width or height is zero in IHDR
gd-png error: setjmp returns error condition

解决方法可以是1. 尝试找一下源代码;2. 通常这些第三方库,我们都是放在一个单独的文件夹里面的,这样子用lcov处理.gcda文件的时候,可以指定目录,把这些第三方库的目录跳过去

  • genhtml的一个参数:–num-spaces NUM

默认值是8,出来的报告看着很费劲,建议换成4,如果代码有很多层,那设成2也是可以的

TestLink和BugZilla集成中的一些问题

前两天有个朋友写信给我问一个testlink和bugzilla集成的问题,从他信里面的描述得出,他已经成功把这两个系统集成好了,但是有一些功能用不了,例如不能显示bugzilla里面的id、状态、标题信息等。其实原因是testlink的作者只实现了bugzilla集成的部分接口,其他的接口是要我们自己来写的。大家可以浏览一下testlink安装目录下的/lib/bugtracking,里面有好些文件,其中文件int_bugtracking.php是testlink和其他所有bug tracking系统(bugzilla, jira, mantis等)做集成的基类。还有一个文件叫int_bugzilla.php,这个文件就是testlink和bugzilla集成的代码,里面定义了一个类:bugzillaInterface,它是bugtrackingInterface的子类,并且在类bugzillaInterface里面重写了一部分方法,这也是为什么如果我们自己不修改代码的话,只能用到部分功能(例如只能连接,但却不能显示相关的信息)。

假如说,现在想在testlink关联bugzilla的一个bug之前,验证一下bug id是否存在,就要在int_bugzilla.php里面重写checkBugID_existence方法。

$query = "SELECT bug_id FROM {$this->dbSchema}.bugs WHERE bug_id='" . $id."'";
$query_results = $this->dbConnection->exec_query($query);
if ($query_results && ($this->dbConnection->num_rows($query_results) == 1))
{
    return true;
}
return false;

如果要自己补充这个int_bugzilla.php的时候,需要一点php的知识,并且对bugzilla数据库有所了解,以前公司的同事告诉我用php的一个神器,vardump。你懂的。

用lcov生成diff代码覆盖率报告

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