测试覆盖率 我们是如何做 go 语言系统测试覆盖率收集的？
工程效能领域，测试覆盖率度量总是绕不开的话题，我们也不例外。在七牛云，我们主要使用 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 语言系统测试覆盖率。整体比较简单，大体只需要三步：
a) 首先通过goc server命令部署一个服务注册中心，它将会作为枢纽服务跟所有的被测服务通信。
b) 使用goc build --center="<server>" 命令编译被测程序。goc 不会破坏被测程序的启动方式，所以你可以直接将编译出的二进制发布到集成测试环境。
c）环境部署好之后，就可以做执行任意的系统测试。而在测试期间，可以在任何时间，通过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 支持。当然，我们更欢迎有志之士，能够参与贡献，和我们一起构建这个有意思的系统。
最后，父亲节快乐！
关注公众号: 大卡尔
图都挂了
赞，我也搞了一段时间 go 覆盖率
恒温
回复
嗯，确实是绕不开的话题。考虑到 goc 其实用的是比较底层的基础技术，可以类比 jacoco 的定位，所以我们特意开源出来，希望能对大家有用~
如果被测项目是 docker 部署，由于被测服务会向注册服务中心注册一个额外的覆盖率收集服务，这个端口在容器创建时是没有被映射出来的，请问大佬们是怎么做的，我的想法是把端口定死
https://github.com/qiniu/goc/releases/tag/v1.1.0
最新版本已经支持指定端口了，可以尝试下~
Changjun Ji
回复
感谢大佬，刚试用了可以，还没正式部署，有个小插曲，指定端口的时候需要加 : ,一开始没加提示端口未指定，懵逼半天哈哈 ，看了下代码才知道
John
回复
是的，这块写的有点匆忙，没加校验，体验确实不好。目前已开了 issue 来跟进： https://github.com/qiniu/goc/issues/61
请问一下--agentport 是怎么使用，目前在本地试用的时候直接用 goc build --agentport=:1000 或者 goc build --agentport=1000，执行编译的文件后在注册服务那边都没看到端口被指定，还是随机的端口，是我使用错了吗
moku
回复
基于代码: https://github.com/qiniu/goc/blob/master/pkg/cover/instrument.go#L252
估计是你本地已经执行过了，程序就直接复用了上一次监听的地址。
这块与预期不大一致，我们调整下。参见 issue: https://github.com/qiniu/goc/issues/74
1.2.1 版本编译报错：（导致无法正常 go get，直接下载源码注释对应报错后使用）
xxxx/src/github.com/qiniu/goc/pkg/build/tmpfolder.go:86:5: undefined: errors.Is
注释了这段代码后编译使用不清除有什么问题。
GodS+_+
回复
通过源码编译 goc，得需要 go 版本 1.13+ 以上。如果是单纯想试用下，可以直接下载 Github Release 里面正式的版本。参见 README: https://github.com/qiniu/goc#installation
GodS+_+
回复
具体是什么样的覆盖率报告呢？
goc 目前产生的是标准的 go 语言自带的 cover profile，如果有需要到是可以将这个 cover profile 转换为其他格式。
Changjun Ji
回复
报告搞定了 github 有包处理，现在有个疑问， 代码更新是不是每次都要重新执行编译 goc build --agentport=:10000 才能监听最新的代码，这个时候端口是被占用的。，使用起来不太方便。
GodS+_+
回复
有点不大理解你的问题。
goc build 命令是为了插桩并编译程序，带上 agentport 参数，是为了指定编译后的程序监听的端口，如果不指定，它会随机监听一个。
代码有更新 (也就是产品有更新)，若想测这块的改动，必然得重新编译和部署服务吧？
Changjun Ji
回复
楼主好，
1.) 首先是要 git 下载 goc 和 simple-go-server，工程 goc 编译通过后。
2.) 在 simple-go-server 根目录下执行【go run D:/GoCode/goc/goc.go run .】
3.) 报如下异常：【level=fatal msg="Fail to run: fail to list package dependencies"
exit status 1】
疑问：请问大概是哪里出错了，btw，演示教程能写的更详细一点吗，多谢先
楼主，您好，请教 2 个问题：
1、想了解下注册服务最多可以监听多少个被测服务
2、当注册服务监听多个被测服务时，支持获取指定被测服务的代码覆盖率吗
楼主您好，我看 git 中 v2 版本的 readme 中 “goc v2 版本开发中”，想问下现在 v2 版本可用吗 稳定不
楼主好，在容器中使用 goc build 会报错 msg="Fail to build: fail to list package dependencies"
麻烦问下你们有没有遇到，要怎么解决
jiangsibei
回复
这一步是为了拿到服务的的包。等价于类似 go list -json ./... , 可以用这个命令来判断是否执行成功。