gcov c++代码覆盖率测试工具(原理篇)

一、gcov简单介绍

Gcov是一个测试C/C++代码覆盖率的工具,伴随GCC发布,配合GCC共同实现对C/C++文件的语句覆盖、功能函数覆盖和分支覆盖测试。

二、gcov统计生成覆盖率流程

图1 gcov覆盖率生成过程

Gcc在编译阶段指定 –ftest-coverage 等覆盖率测试选项后,GCC会:

1、 在输出目标文件中留出一段存储区保存统计数据;

2、 在源代码中每行可执行语句生成的代码之后附加一段更新覆盖率统计结果的代码,也就是插桩(后面详细介绍);

3、 Gcc编译,会生成*.gcno文件,它包含重建基本块图和相应块的源码的行号信息;

4、 在最终可执行文件中,进入main函数之前调用gcov_init内部函数初始化统计数据区,并将gcov_init内部函数注册为exit_handers,用户代码调用exit正常结束时,gcov_exit函数得到调用,并继续调用__gcov_flush输出统计数据到*.gcda文件。

三、原理(插桩)

gcov是使用 基本块BB 跳转ARC 计数,结合 程序流图 来实现代码覆盖率统计的:

图2 程序流图

基本块BB:如果一段程序的第一条语句被执行过一次,这段程序中的每一个都要执行一次,称为基本块。一个BB中的所有语句的执行次数一定是相同的。一般由多个顺序执行语句后边跟一个跳转语句组成。所以一般情况下BB的最后一条语句一定是一个跳转语句,跳转的目的地是另外一个BB的第一条语句,如果跳转时有条件的,就产生了分支,该BB就有两个BB作为目的地。

跳转ARC:从一个BB到另外一个BB的跳转叫做一个arc,要想知道程序中的每个语句和分支的执行次数,就必须知道每个BB和ARC的执行次数。

如果把BB作为一个节点,这样一个函数中的所有BB就构成了一个有向图。要想知道程序中的每个语句和分支的执行次数,就必须知道每个BB和ARC的执行次数。根据图论可以知道有向图中BB的入度和出度是相同的,所以只要知道了部分的BB或者ARC大小,就可以推断所有的大小。

由ARC的执行次数来推断BB的执行次数。所以对部分 ARC插桩,只要满足可以统计出来所有的BB和ARC的执行次数即可。

记录BB块和ARB的数据结构为:

struct bb

long zero_word; //是否被插入到链表中

const char *file_name; //当前被测试文件名

long *count;//指向bx2的指针

long ncounts;//桩点个数

struct bb *next;//下一个文件的BX2信息

1、GCC在插桩的过程中会向源文件的末尾插入一个静态数组,BX2.,数组的大小就是这个源文件中桩点的个数。BX2+0代表第0个桩点的位置,BX2+n代表第n个桩点的位置,数组的值就是桩点的执行次数。

2、每个桩点插入汇编语句:

*按照我的理解,汇编语句是inc$(BX2+n).

3、 BX2数组链表:

为了便于统计,gcc还将各个源文件中的BX2数组链接成一个链表,这个链表结构是在测试main函数之前就产生了,在调用main之前会有一个类似构造函数的函数,进行构建链表。这个函数会在退出时调用exit函数计算执行次数生成.gcda文件。

Qtest是360旗下的专业测试团队!

是WEB平台部测试技术平台化、效率化的先锋力量!

https://ceshiren.com/t/topic/20878

SonarQube的使用心得

一、使用背景:

   SonarQube 是一个用于代码质量管理的开源平台,用于管理源代码的质量。

通过插件形式,可以支持包括 java, C#, C/C++, PL/SQL, Cobol, JavaScrip, Groovy 等等二十几种编程语言的代码质量管理与检测。

   Sonar可以从以下七个维度检测代码质量,而作为开发人员至少需要处理前5种代码质量问题。

1. 不遵循代码标准

sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写。

2. 潜在的缺陷

sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具检测出潜在的缺陷。

3. 糟糕的复杂度分布

文件、类、方法等,如果复杂度过高将难以改变,这会使得开发人员难以理解它们, 且如果没有自动化的单元测试,对于程序中的任何组件的改变都将可能导致需要全面的回归测试。

4. 重复

显然程序中包含大量复制粘贴的代码是质量低下的,sonar可以展示源码中重复严重的地方。

5. 注释不足或者过多

没有注释将使代码可读性变差,特别是当不可避免地出现人员变动时,程序的可读性将大幅下降;而过多的注释又会使得开发人员将精力过多地花费在阅读注释上,亦违背初衷。

6. 缺乏单元测试

sonar可以很方便地统计并展示单元测试覆盖率。

7. 糟糕的设计

通过sonar可以找出循环,展示包与包、类与类之间的相互依赖关系,可以检测自定义的架构规则:通过sonar可以管理第三方的jar包,可以利用LCOM4检测单个任务规则的应用情况,检测藕合。

二、SonarQube的安装、配置

1、jdk

2、sonarqube官网:

https://www.sonarqube.org/进行下载

3、SonarQube+Scanner扫描分析器:

https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-2.5.zip

4、mysql数据库:

需要注意点,数据库版本要求;;#----- 5.6<=MySQL _<)~~】

还有数据库的查看mysql默认一次允许写入的包大小:

show global VARIABLES like ‘%max_allowed_packet%‘

Sonarz中数据库配置信息如下:

正常启动后,信息提示如下:可以访问http://localhost:9000/ sonar搭建完毕!!

三、SonarQube的分析、扫描

1、安装必要插件--最重要的是汉化包

2、新建项目进行静态代码扫描

sonar-scanner.bat -D“sonar.projectKey=qixiao" -D"sonar.sources=." -D"sonar.host.url=http://localhost:9000" -D"sonar.login=105d3da15bc1e355d7a8c290d24b1d0465a571af"

3、生成报告分析

四、SonarQube的总结

为什么要选择SonarQube?

个人使用之后认为 :

SonarQube的优势如下(相比于阿里编码规约这种市面上常见类似软件):

  • 更加优秀的图形化界面基本上通过界面就可以对自己项目的代码状况一目了然

  • 可以查询出其它软件难以定位到的问题比如 :

    2.1.可能导致空指针异常的问题 (对象在进行使用前没有加空的判断)

    2.2.可能导致内存泄漏的问题, 在try catch块里面,直接使用e.printStackTrace()将堆栈信息打印到内存的

    2.3.可能导致的漏洞 : 成员变量使用public定义的