开源啦 | 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 - A Comprehensive Coverage Testing System for The Go Programming Language
一图胜千言:
使用 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 核心原理及未来
goc在设计上,抛弃老的 go test-c-cover
模式,而是直接与 go tool cover
工具交互,避免因 go test
命令引入的一系列弊端。goc同样没有选择自己做插桩,也是考虑go语言的兼容性,以及性能问题,毕竟 go tool cover
工具,原生采用结构体来定义counter收集器,每个文件都有单独的结构体,性能相对比较可靠。goc旨在做go语言领域综合性的覆盖率工具以及精准测试系统,其还有很长的路要走:
-
基于PR的单测/集测/系统覆盖率增量分析
-
精准测试方向,有一定的产品化设计体验,方便研发与测试日常使用
-
拥抱各种CICD系统
当前goc已经开源了(https://github.com/qiniu/goc),欢迎感兴趣的同学,前往代码仓库查看详情并Star支持。当然,我们更欢迎有志之士,能够参与贡献,和我们一起构建这个有意思的系统。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
服务器端实时推送技术之SSE
前言 在讲Server-Sent Events (SSE)之前,我们先来看看 HTTP 请求- 响应。一个标准的 HTTP 请求- 响应,需要客户端打开一个连接,将一个 HTTP 请求(如 HTTP GET 请求)发送到服务端,然后接收到 HTTP 回来的响应,如果该响应被完全发送或者接收,服务端就会把连接关闭。通常是由某个客户发起,客户端才会需要请求所有数据。 然而, Server-Sent Events (SSE) 与 HTTP 请求- 响应背道而驰,它是一种机制,客户端一旦建立起客户机-服务器的连接,就能让服务端将数据以异步的方式从服务器推到客户端。当连接由客户端建立完成,服务端就提供数据,并决定新数据“块"可用时将其发送到客户端。当一个新的数据事件发生在服务端时,这个事件被服务端发送到客户端。因此,名称被称为 Server-Sent Events(服务器推送事件)。下面是支持服务端到客户端交互的技术总览: 插件提供 socket 方式:比如利用 Flash XMLSocket,Java Applet 套接口,Activex 包装的 socket。 优点:原生 socket 的支...
- 下一篇
斗鱼Juno 监控中心的设计与实现
Juno 监控中心的设计与实现 作者:杜旻翔 @ 斗鱼 前言 伴随微服务的推广,程序粒度的日趋小型化,服务数量逐渐增长,需要更多的关注服务本身的监控,服务上下游服务情况,以及相关数据源中间件的状态。我们需要更加多维度服务监控,能够对服务调用链路进行可视化、对目标服务调用时客户端与服务端的实时监控。在 Juno 监控中心,我们尝试解决这些问题。 为什么需要监控中心 在行业内越来越多的公司需要开发人员懂得服务器基础架构、操作系统、网络、语言特性、业务整体架构、面对线上问题快速分析快速定位、还包括服务性能调优,对这些方面的要求就是 Google 倡导的 SRE(站点可靠性工程师)。这项工作依赖于很多工具才能顺利完成,例如日志系统、发布系统、监控系统等等。 在斗鱼微服务管理系统 Juno,其中的监控中心的设计就是为协助开发人员进行高效的服务稳定性维护工作,完成对微服务系统的健康支持: 水位瓶颈,在斗鱼进行全链路压测,通过监控系统可以找到服务链路中的瓶颈,了解核心项目的具体水位; 故障预防,采用环比和同步数据进行服务健康波动分析,进行一定程度上的异常预防; 故障排查,线上故障快速定位,给出服...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境