这篇文章将为大家详细讲解有关 go语言系统测试覆盖率收集利器goc怎么用，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
工程效能领域，测试覆盖率度量总是绕不开的话题，我们也不例外。在七牛云，我们主要使用go语言构建云服务，在考虑系统测试覆盖率时，最早也是通过围绕原生go test -c -cover的能力来构建。且我们已经做了很多自动化工作，能够针对很多类型的代码库，自动插桩服务，自动生成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 run.的姿势直接运行被测程序，就能在运行时，通过 goc profile命令方便的得到覆盖率结果。是不是很神奇？是不是很优雅？
这个系统就是goc, 设计上希望完全兼容go命令行工具核心命令(go build/install/run)。使用体验上，也希望向go命令行工具靠拢。以下是goc 1.0版本支持的功能:
有了goc，我们再来看如何收集go语言系统测试覆盖率。整体比较简单，大体只需要三步：
首先通过 goc server命令部署一个服务注册中心，它将会作为枢纽服务跟所有的被测服务通信。
使用 goc build--center="<server>" 命令编译被测程序。goc不会破坏被测程序的启动方式，所以你可以直接将编译出的二进制发布到集成测试环境。
环境部署好之后，就可以做执行任意的系统测试。而在测试期间，可以在任何时间，通过 goc profile--center="<server>"拿到当前被测集群的覆盖率结果。
是不是很优雅？
goc在设计上，抛弃老的 go test-c-cover模式，而是直接与 go tool cover工具交互，避免因 go test命令引入的一系列弊端。goc同样没有选择自己做插桩，也是考虑go语言的兼容性，以及性能问题，毕竟 go tool cover工具，原生采用结构体来定义counter收集器，每个文件都有单独的结构体，性能相对比较可靠。goc旨在做go语言领域综合性的覆盖率工具以及精准测试系统，其还有很长的路要走:
基于PR的单测/集测/系统覆盖率增量分析
精准测试方向，有一定的产品化设计体验，方便研发与测试日常使用
拥抱各种CICD系统
关于 go语言系统测试覆盖率收集利器goc怎么用就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
