3 篇博文 含有标签「覆盖率」

玩过 Go 覆盖率的同学当有所了解，Go 的覆盖率方案最初的设计目标仅是针对单测场景，导致其局限性很大。而为了适配更多的场景，行业内各种博客、插件、黑科技介绍也层出不穷。当然，过去我们也开源过 Go 系统测试覆盖率收集利器 - goc，算其中比较完善，比较系统的了。且从用户使用角度来看，goc 也确实解决了行业内很多同学的痛点。

而现在，Go 官方终于开始正式这个问题了。作者Than McIntosh 于今年 3 月份提出了新的覆盖率提案，且看当前实现进度，最快 Go1.20 我们就能体验到这个能力，非常赞。

• https://github.com/golang/go/issues/51430
• https://go.googlesource.com/proposal/+/master/design/51430-revamp-code-coverage.md

基于作者的 Proposal，我们先来看看这个提案细节。

新姿势: go build -cover​

需要明确的是，本次提案不会改变原来的使用姿势go test -cover，而是新增go build -cover使用入口。从这一变化我们不难看出，新提案主要瞄准的是 "针对程序级的覆盖率收集" ，而旧版的实际是 "仅针对包级别的覆盖率收集" ，二者设计目标有明显的差别。

在新姿势下，使用流程大体是:

$ go build -o myapp.exe -cover ...
$ mkdir /tmp/mycovdata
$ export GOCOVERDIR=/tmp/mycovdata
$ <run test suite, resulting in multiple invocations of myapp.exe>
$ go tool covdata [command]

整体逻辑也比较清晰：

1. 先编译出一个经过插桩的被测程序
2. 配置好覆盖率输出的路径，然后执行被测程序。到这一步程序本身就会自动的输出覆盖率结果到上述路径了
3. 通过 go tool covdata 来处理覆盖率结果

这里的子命令 covdata 是新引入的工具。而之所需要新工具，主要还是在新提案下，输出的覆盖率文件格式与原来的已有较大的差别。

新版覆盖率格式​

先来看旧版的覆盖率结果:

  mode: set
  cov-example/p/p.go:5.26,8.12 2 1
  cov-example/p/p.go:11.2,11.27 1 1
  cov-example/p/p.go:8.12,10.3 1 1
  cov-example/p/p.go:14.27,20.2 5 1

大家当比较熟悉，其是文本格式，简单易懂。

每一行的基本语义为 "文件:起始行.起始列,结束行.结束列 该基本块中的语句数量 该基本块被执行到的次数"

但缺点也明显，就是 "浪费空间". 比如文件路径 cov-example/p/p.go, 相比后面的 counter 数据，重复了多次，且在通常的 profile 文件，这块占比很大。

新提案在这个方向上做了不少文章，实现细节上稍显复杂，但方向较为清晰。

通过分析旧版的每一行能看出，本质上每一行会记录两类信息，一是定位每个基本块的具体物理位置，二是记录这个基本块的语句数量和被执行的次数。虽然执行的次数会变化，但是其他的信息是不变的，所以全局上其实只要记录一份这样的信息就好，而这就能大大的优化空间，

所以，新版覆盖率它实际会实际输出两份文件，一份就是 meta-data 信息，用于定位这个被测程序所有包、方法等元信息，另一份才是 counters，类似下面:

➜  tmp git:(master) ✗ ls -l
total 1280
-rw-r--r--  1 jicarl  staff   14144 Nov 28 17:02 covcounters.4d1584597702552623f460d5e2fdff27.8120.1669626144328186000
-rw-r--r--  1 jicarl  staff  635326 Nov 28 17:02 covmeta.4d1584597702552623f460d5e2fdff27

这两份文件都是二进制格式，并不能直观的读取。但是借助covdata工具，可以轻松转化为旧版格式，比较优雅。类似：

go tool covdata textfmt -i=tmp -o=covdata.txt

ps: tmp 是覆盖率文件所在目录。

真 • 全量覆盖率​

一个标准的 go 程序，基本上由三种类型的代码包组成:

• 自身代码
• 第三方包，通过 mod 或者 vendor 机制引用
• go 标准库

在过去，几乎所有的工具都只关注业务自身代码的插桩，鲜少关注第三方包，更别说 go 官方标准库了。这在大部分场景下是没问题的，但有时有些场景也有例外，比如 SDK 相关的项目。因为这时候 SDK 会作为 Dependency 引入，要想对其插桩就需要额外的开发量。还比如一些 CLI 程序，执行完命令之后，立马就结束了，也是非常不利于覆盖率收集的。

这些问题都是很现实的，且我们在 goc 项目中也收到过真实的用户反馈:

• https://github.com/qiniu/goc/issues/243
• https://github.com/qiniu/goc/issues/304

不过，现在好了，新版覆盖率方案也有实际考虑到这些需求，它实际会做到 支持全量插桩+程序退出时主动输出覆盖率结果 的原生方式，非常值得期待。

更多覆盖率使用场景支持: 合并(merge)、删减(subtract)、交集(intersect)​

在实际处理覆盖率结果时，有很多实用的场景，在新提案中也有提及，比如支持:

• 合并多次覆盖率结果 go tool covdata merge -i=<directories> -o=<dir>
• 删减已经覆盖的部分 go tool covdata subtract -i=dir1,dir2 -o=<dir>
• 得到两份结果的交集 go tool covdata intersect -i=dir1,dir2 -o=<dir>

在过去，这些场景都需要依赖第三方工具才行，而在新方案中已经无限接近开箱即用了。

不过更复杂的场景，类似远程获得覆盖率结果等(类似 goc 支持的场景)，看起来新方案并没有原生支持。这个问题，笔者也在 issue 讨论中提出，看看作者是否后续有解答。

展望与不足​

值得注意的是新提案的实现是通过 源码插桩+编译器支持 的方式来混合实现的，与原来go test -cover 纯源码改写的方式有了较大的变化。

另外作者提到的 test "origin" queries 功能还是非常让我兴奋的，因为有了它，若想建立 测试用例到源码的映射 会变得简单很多，甚至更进一步的 精准测试，也变的更有想象空间。不过这个功能不会在 Go1.20 里出现，只能期待以后了。

作者还提到了一些其他的限制和将来可能的改进，比如 Intra-line coverage, Function-level coverage, Taking into account panic paths 等，感兴趣的同学可以自行去 Proposal 文档查看。

"聊点干货"

覆盖率技术基础​

截止到 Go1.15.2 以前，关于覆盖率技术底层实现，以下知识点您应该知道：

• go 语言采用的是插桩源码的形式，而不是待二进制执行时再去设置 breakpoints。这就导致了当前 go 的测试覆盖率收集技术，一定是侵入式的，会修改目标程序源码。曾经有同学会问，插过桩的二进制能不能放到线上，所以建议最好不要。

• 到底什么是"插桩"？这个问题很关键。大家可以任意找一个 go 文件，试试命令go tool cover -mode=count -var=CoverageVariableName xxxx.go，看看输出的文件是什么？

  • 笔者以这个文件为例https://github.com/qiniu/goc/blob/master/goc.go, 得到以下结果:

    	package main
    
    	import "github.com/qiniu/goc/cmd"
    
    	func main() {CoverageVariableName.Count[0]++;
    		cmd.Execute()
    	}
    
    	var CoverageVariableName = struct {
    		Count     [1]uint32
    		Pos       [3 * 1]uint32
    		NumStmt   [1]uint16
    	} {
    		Pos: [3 * 1]uint32{
    			21, 23, 0x2000d, // [0]
    		},
    		NumStmt: [1]uint16{
    			1, // 0
    		},
    	}
    

    可以看到，执行完之后，源码里多了个CoverageVariableName变量，其有三个比较关键的属性: _ Count uint32 数组，数组中每个元素代表相应基本块(basic block)被执行到的次数 _ Pos 代表的各个基本块在源码文件中的位置，三个为一组。比如这里的21代表该基本块的起始行数，23代表结束行数,0x2000d比较有趣，其前 16 位代表结束列数，后 16 位代表起始列数。通过行和列能唯一确定一个点，而通过起始点和结束点，就能精确表达某基本块在源码文件中的物理范围 * NumStmt 代表相应基本块范围内有多少语句(statement) CoverageVariableName变量会在每个执行逻辑单元设置个计数器，比如CoverageVariableName.Count[0]++, 而这就是所谓插桩了。通过这个计数器能很方便的计算出这块代码是否被执行到，以及执行了多少次。相信大家一定见过表示 go 覆盖率结果的 coverprofile 数据，类似下面: github.com/qiniu/goc/goc.go:21.13,23.2 1 1

    这里的内容就是通过类似上面的变量CoverageVariableName得到。其基本语义为 "文件:起始行.起始列,结束行.结束列 该基本块中的语句数量 该基本块被执行到的次数"

依托于 go 语言官方强大的工具链，大家可以非常方便的做单测覆盖率收集与统计。但是集测/E2E 就不是那么方便了。不过好在我们现在有了https://github.com/qiniu/goc。

集测覆盖率收集利器 - Goc 原理​

关于单测这块，深入 go 源码，我们会发现go test -cover命令会自动生成一个_testmain.go 文件。这个文件会 Import 各个插过桩的包，这样就可以直接读取插桩变量，从而计算测试覆盖率。实际上goc也是类似的原理(PS: 关于为何不直接用go test -c -cover 方案，可以参考这里https://mp.weixin.qq.com/s/DzXEXwepaouSuD2dPVloOg)。

不过集测时，被测对象通常是完整产品，涉及到多个 long running 的后端服务。所以 goc 在设计上会自动化会给每个服务注入 HTTP API，同时通过服务注册中心goc server来管理所有被测服务。如此的话，就可以在运行时，通过命令goc profile实时获取整个集群的覆盖率结果，当真非常方便。

整体架构参见:

代码覆盖率的最佳实践​

技术需要为企业价值服务，不然就是在耍流氓。可以看到，目前玩覆盖率的，主要有以下几个方向:

• 度量 - 深度度量，各种包，文件，方法度量，都属于该体系。其背后的价值在于反馈与发现。反馈测试水平如何，发现不足或风险并予以提高。比如常见的作为流水线准入标准，发布门禁等等。度量是基础，但不能止步于数据。覆盖率的终极目标，是提高测试覆盖率，尤其是自动化场景的覆盖率，并一以贯之。所以基于此，业界我们看到，做的比较有价值的落地形态是增量覆盖率的度量。goc diff 结合 Prow 平台也落地了类似的能力，如果您内部也使用 Kubernetes，不妨尝试一下。当然同类型的比较知名的商业化服务，也有 CodeCov/Coveralls 等，不过目前她们多数是局限在单测领域。

• 精准测试方向 - 这是个很大的方向，其背后的价值逻辑比较清晰，就是建立业务到代码的双向反馈，用于提升测试行为的精准高效。但这里其实含有悖论，懂代码的同学，大概率不需要无脑反馈；不能深入到代码的同学，你给代码级别的反馈，也效果不大。所以这里落地姿势很重要。目前业界没还看到有比较好的实践例子，大部分都是解决特定场景下的问题，有一定的局限。

而相较于落地方向，作为广大研发同学，下面这些最佳实践可能对您更有价值：

• 高代码覆盖率并不能保证高产品质量，但低代码覆盖率一定说明大部分逻辑没有被自动化测到。后者通常会增加问题遗留到线上的风险，当引起注意。
• 没有普适的针对所有产品的严格覆盖率标准。实际上这更应该是业务或技术负责人基于自己的领域知识，代码模块的重要程度，修改频率等等因素，自行在团队中确定标准，并推动成为团队共识。
• 低代码覆盖率并不可怕，能够主动去分析未被覆盖到的部分，并评估风险是否可接受，会更加有意义。实际上笔者认为，只要这一次的提交比上一次要好，都是值得鼓励的。

谷歌有篇博客(参考资料)提到，其经验表明，重视代码覆盖率的团队通常会更加容易培养卓越工程师文化，因为这些团队在设计产品之初就会考虑可测性问题，以便能更轻松的实现测试目标。而这些措施反过来会促使工程师编写更高质量的代码，更注重模块化。

最后，欢迎点击左下角详情按钮，加入七牛云 Goc 交流群，我们一起聊聊 goc，聊聊研发效能那些事。

参考资料

• 谷歌管理覆盖率的经验: https://testing.googleblog.com/2020/08/code-coverage-best-practices.html

往期推荐​

• 开源啦 | go 语言系统测试覆盖率收集利器 goc

觉得不错，欢迎关注：​

工程效能领域，测试覆盖率度量总是绕不开的话题，我们也不例外。在七牛云，我们主要使用 go 语言构建云服务，在考虑系统测试覆盖率时，最早也是通过围绕原生go test -c -cover的能力来构建。这个方案，笔者还曾在 MTSC2018 大会上有过专项分享。其实我们当时已经做了不少自动化工作，能够针对很多类型的代码库，自动插桩服务，自动生成 TestMain()等方法，但随着接入项目越来越多，以及后面使用场景的不断复杂化，我们发现这套还是有其先天局限，会让后面越来越难受：

• 程序必须关闭才能收集覆盖率。如果将这套系统仅定位在收集覆盖率数据上，这个痛点倒也能忍受。但是如果想进一步做精准测试等方向，就很受局限。
• 因为不想污染被测代码库，我们采取了自动化的方式，在编译阶段给每个服务生成类似 main_test.go 文件。但这种方式，其最难受的地方在于 flag 的处理，要知道 go test 命令本身会调用flag.Parse 方法，所以这里需要自动化的修改源码，保证被测程序的 flag 定义，要先于 go test 调用 flag.Parse 之前。但是，随着程序自己使用 flag 姿势的复杂化，我们发现越来越难有通用方案来处理这些 flag，有点难受。
• 受限于go test -c命令的先天缺陷，它会给被测程序注入一些测试专属的 flag，比如-test.coverprofile, -test.timeout 等等。这个是最难受的，因为它会破坏被测程序的启动姿势。我们知道系统测试面对是完整被测集群，如果你需要专门维护一套测试集群来做覆盖率收集时，就会显得非常浪费。好钢就应该用在刀刃上，在七牛云，我们倡导极客文化，追求用工程师思维解决重复问题。而作为业务效率部门，我们自己更应该走在前列。

也是因为以上的种种考量，我们内部一直在优化这一套系统，到今天这一版，我们已从架构和实现原理上完成了颠覆，能够做到无损插桩，运行时分析覆盖率，当属非常优雅。

Goc - A Comprehensive Coverage Testing System for The Go Programming Language​

一图胜千言:

使用goc run .的姿势直接运行被测程序，就能在运行时，通过goc profile命令方便的得到覆盖率结果。是不是很神奇？是不是很优雅？

这个系统就是goc, 设计上希望完全兼容 go 命令行工具核心命令(go buld/install/run)。使用体验上，也希望向 go 命令行工具靠拢：

以下是goc 1.0 版本支持的功能:

系统测试覆盖率收集方案​

有了 goc，我们再来看如何收集 go 语言系统测试覆盖率。整体比较简单，大体只需要三步：

• 首先通过goc server命令部署一个服务注册中心，它将会作为枢纽服务跟所有的被测服务通信。

• 使用goc build --center="<server>" 命令编译被测程序。goc 不会破坏被测程序的启动方式，所以你可以直接将编译出的二进制发布到集成测试环境。

• 环境部署好之后，就可以做执行任意的系统测试。而在测试期间，可以在任何时间，通过goc profile --center="<server>"拿到当前被测集群的覆盖率结果。 是不是很优雅？

goc 核心原理及未来​

goc 在设计上，抛弃老的go test -c -cover模式，而是直接与go tool cover工具交互，避免因go test命令引入的一系列弊端。goc 同样没有选择自己做插桩，也是考虑 go 语言的兼容性，以及性能问题，毕竟go tool cover工具，原生采用结构体来定义 counter 收集器，每个文件都有单独的结构体，性能相对比较可靠。goc 旨在做 go 语言领域综合性的覆盖率工具以及精准测试系统，其还有很长的路要走:

• 基于 PR 的单测/集测/系统覆盖率增量分析
• 精准测试方向，有一定的产品化设计体验，方便研发与测试日常使用
• 拥抱各种 CICD 系统

当前goc 已经开源了，欢迎感兴趣的同学，前往代码仓库查看详情并 Star 支持。当然，我们更欢迎有志之士，能够参与贡献，和我们一起构建这个有意思的系统。

最后，父亲节快乐！

Contact me ?​