Go增量覆盖率解决方案

代码覆盖率

本文参考了内部同事huimiao的文章：

一、引言

我是一名中间件 QA，我对应的研发团队是有赞 PaaS，目前我们团队有很多产品是使用 go 语言开发，因此我对 go 语言项目的单测覆盖率、集成以及增量测试覆盖率统计与分析做了探索。

二、单测覆盖率以及静态代码分析

2.1､单测覆盖率分析

Go 语言自身提供了单元测试工具 go test ，单元测试文件必须以 *_test.go 形式存在， go test 工具同时也提供了分析单测覆盖率的功能。因为需要将单测覆盖率上传到 sonar 平台展示，所以必须将覆盖率文件转换成能被 sonar 识别的格式，因此，还需要另外一个命令行工具 gocov。

首先我们使用 go test 生成覆盖率输出文件 cover.out ，并通过 gocov 工具来将生成的覆盖率文件 cover.out 转换成可以被 sonar 识别的 Cobertura 格式的 xml 文件。 如下所示：

go test -v ./... -coverprofile=cover.out #生成覆盖率输出  
gocov convert cover.out | gocov-xml > coverage.xml #将覆盖率输出转换成xml格式的报告  

新覆盖率问题

1.问题分析

        go覆盖率的搜集这里就不详细介绍了，主要介绍增量覆盖率的计算。

        为什么要讨论这个问题，因为在直接解析go覆盖率输出文件，拿到覆盖行号进行增量计算，最后会导致数据不准确。

go覆盖率命令go test -coverprofile=cov.out输出文件行分析：

go输出的覆盖率文件

21.13,31.3 --代码块开始（LineNo_start）和结束(LineNo_end)的行号，21行第13个字符开始到31行第3个字符作为一个代码块

4 -- 代码块的可执行行数(ExecCnt)，有4行可执行行

1 -- 覆盖情况，1测试覆盖，0测试未覆盖

        上图右边是生成的覆盖率报告页面，可以看到21-31行，只有4行可执行行，是因为其他是注释或者空行。

        所以，问题的核心是，原生输出覆盖率文件信息无法确定代码块中哪些是可/不可执行行

2.解决思路：

方案1：

        当然是从go源码入手，可以找到计数的方法，在每次可执行计数的时候，额外输出行号。

这种方案，优点：后面只需要直接解析新的输出文件即可。

缺点：落实之后，需要所有的开发在生成覆盖率数据的时候，都需要用修改后的插桩工具。

方案2:

        重新解析一次覆盖率输出文件，在无法明确可执行行的情况下，对比代码，分析代码文件，去除不可执行行。

这种方案，优点：无需改动go源码，

缺点：后面分析，不少文件需要去读取代码源文件进行匹配，增加了后台处理计算的负担。

3.效果：

1.全量报告跟原生相比，更清楚直接

        如下，左边黑色是原生报告，原生报告生成方式 go tool cover -html=cov.out,

        右边是咱们视频覆盖率平台生成的go覆盖率报告页面。相比下，视频覆盖率平台可以更直观的标注可执行的覆盖信息，不可执行行已经不再标注。

2.增量覆盖率数据更准确

        如下两个部分，左边是未做处理的增量覆盖率报告，可以看到增量覆盖率数据是33.33%，右边是做过处理的数据是50%。 可以看到相比下，因为第16行是注释行，导致两边计算数据不一致。显然，右边更准确。