深入Go代码覆盖率使用、场景与原理

1557次阅读  |  发布于2年以前

一般我们会使用代码覆盖率来判断代码书写的质量,识别无效代码。

识别静态静态的代码

对于静态的代码,要识别代码没有被使用,可以使用golangci-lint工具

golangci-lint  run --disable-all  --enable unused

对于通过单元测试 测试函数代码的覆盖率,在go生态中,go1.2提供了cover工具。

cover 基本用法

首先来看看go test -cover 统计代码覆盖率做的事情,借鉴一下它的思路。go test -cover 能够统计出代码的覆盖率,这是一种比统计函数是否被调用更强悍的手法。

% go test -cover
PASS
coverage: 42.9% of statements
ok      size    0.026s
%

另外,还可以收集覆盖率进行,并进行可视化的展示。

go test -coverprofile=coverage.out

如下,使用 go tool cover 可视化分析代码覆盖率信息。

$ go tool cover -html=coverage.out

能够识别和统计出未调用过的分支。

测试环境下代码覆盖率

go test -cover 本身是运行xxx_test.go文件的测试函数使用的,但是我们可以使用一些奇淫技巧将这种方式用于测试环境下的代码覆盖率测试。假设我们的代码是一个web服务器,我们可以新建一个main_test.go文件,执行main()函数,就好像在执行程序一样。并在退出程序后,正常完成coverprofile文件的生成。这种好处是可以在测试环境调用http请求,并最终统计代码覆盖率。如下为一段main_test.go代码示例


func TestSystem(t *testing.T) {
        handleSignals()

        endRunning = make(chan bool, 1)

        go func() {

            main()

        }()

        <-endRunning
}

线上代码覆盖率的思路

假设我们的需求是想看线上的代码哪一些函数没有被调用?

运行中的程序要检测某一个函数是否被调用似乎没有什么好的办法,原因是没有好的手段能够检测并记录当前函数已经被调用了。

可以将线上的代码覆盖率分为倾入性和非倾入性两种方式。

倾入性方案一种最直接的方式是为代码打桩,在每一个函数开头埋点记录下调用信息。我们可以参考下go test -cover

的实现方案。

cover代码覆盖率的原理

go test -cover 会对代码进行打桩。

package size

func Size(a int) string {
    switch {
    case a < 0:
        return "negative"
    case a == 0:
        return "zero"
    case a < 10:
        return "small"
    case a < 100:
        return "big"
    case a < 1000:
        return "huge"
    }
    return "enormous"
}

如上代码可以通过下面的命令生成打桩后的结果

go tool cover -mode=set  -var=size  xxx.go

打桩后的结果如下:

//line xxx.go:1
package tt

func Size(a int) string {size.Count[0] = 1;
        switch {
        case a < 0:size.Count[2] = 1;
                return "negative"
        case a == 0:size.Count[3] = 1;
                return "zero"
        case a < 10:size.Count[4] = 1;
                return "small"
        case a < 100:size.Count[5] = 1;
                return "big"
        case a < 1000:size.Count[6] = 1;
                return "huge"
        }
        size.Count[1] = 1;return "enormous"
}

var size = struct {
        Count     [7]uint32
        Pos       [3 * 7]uint32
        NumStmt   [7]uint16
} {
        Pos: [3 * 7]uint32{
                3, 4, 0x90019, // [0]
                16, 16, 0x130002, // [1]
                5, 6, 0x14000d, // [2]
                7, 8, 0x10000e, // [3]
                9, 10, 0x11000e, // [4]
                11, 12, 0xf000f, // [5]
                13, 14, 0x100010, // [6]
        },
        NumStmt: [7]uint16{
                1, // 0
                1, // 1
                1, // 2
                1, // 3
                1, // 4
                1, // 5
                1, // 6
        },
}

而要实现go test -coverprofile=coverage.out打桩略微复杂一些,改命令会生成一个_testmain.go的中间文件,将文件名信息以及花括号的信息记录并注册,并最终生成coverprofile协议文件。具体的执行过程可以通过如下命令查看。

go test -n -x  -test.coverprofile=coverage.out

coverprofile文件的协议遵循如下格式:

第一行为"mode: foo", foo is "set", "count", or "atomic".
中间为记录的位置:name.go:line.column,line.column numberOfStatements count
// 例如:encoding/base64/base64.go:34.44,37.40 3 1

具体协议可以参考:go1.16.14/src/cmd/cover/profile.go:44

coverprofile文件协议需要的信息可以通过go test -cover自动生成的代码进行整理。在这个地方,可以参考开源项目https://github.com/qiniu/goc 的实现逻辑,goc 本身就是对go test -cover 命令的封装。

借助如下命令得到的在临时目录生成的文件,可以查看到如何将go test -cover对应的结构转换为coverprofile 文件的协议。

goc build --debug

cover 打桩原理:AST语法树打桩

go test -cover 打桩的原理是借助AST语法树遍历整个文件,在识别到花括号、swith、select等地方,插入一行。

// go1.16.14/src/cmd/cover/cover.go:202
func (f *File) Visit(node ast.Node) ast.Visitor {
    switch n := node.(type) {
    case *ast.BlockStmt:
        // If it's a switch or select, the body is a list of case clauses; don't tag the block itself.
        if len(n.List) > 0 {
            switch n.List[0].(type) {
            case *ast.CaseClause: // switch
                for _, n := range n.List {
                    clause := n.(*ast.CaseClause)
                    f.addCounters(clause.Colon+1, clause.Colon+1, clause.End(), clause.Body, false)
                }
                return f
            case *ast.CommClause: // select
                for _, n := range n.List {
                    clause := n.(*ast.CommClause)
                    f.addCounters(clause.Colon+1, clause.Colon+1, clause.End(), clause.Body, false)
                }
                return f
            }
        }
        f.addCounters(n.Lbrace, n.Lbrace+1, n.Rbrace+1, n.List, true) // +1 to step past closing brace.
 ...

借助于操作AST语法树这种思路,我们也可以做相应改造,完成在代码特定位置插入一行用于统计,等其他功能。

如果只是统计函数是否被调用,那么可以借助AST语法树,在识别到函数的下一行,插入一行统一的函数调用,全局Record函数可以是一个map,用于全局函数的统计。参考资料中给出了操作AST的2篇文章。

func A(){
  Record("A")
  ...
}

脚本

如果我们只是想实现简单的功能,例如在函数下方插入一行,也许我们可以用时间成本最小的方式来处理。如下的sed命令,直接在文件中函数下方插入一行,这种方式最快。

sed -i 's/.*\(func \([a-z].*\)()\).*/\1\n Record \2/g' xxx.go

其适用于大部分函数场景:但是上面的这种方法不适用于有换行的函数,如下统计个数。

find . -type f -name '*.go' -not -path "./vendor/*" | xargs ggrep -oP "func \w*\(.*?,$" | wc -l

非倾入性方案-pprof

上面的方式比较直接,但是代码有侵入性容易出错。不想有倾入性可以借助于中断信号处理的方式。

Go pprof CPU 分析器使用 定时发送SIGPROF 信号中断代码执行。当调用 pprof.StartCPUProfile 函数时,SIGPROF 信号处理程序将被注册为默认每 10 毫秒间隔调用一次(100 Hz)。在 Unix 上,它使用 setitimer(2) 系统调用来设置信号计时器。当内核态返回到用户态调用注册好的sighandler 函数,sighandler 函数识别到信号为_SIGPROF 时,执行sigprof 函数记录该CPU样本,并以此机会获取当前代码的栈帧数据。

这些堆栈信息可以合并为profile文件并最终被pprof程序分析处理。

这种方式记录了每一个堆栈样本

并且通过合并统计,借助概率的方式,能够知道程序大部分时间在哪个函数运行。

但是如果要统计哪一个函数没有被调用却比较困难,原因是如果某一个A函数执行的时间很短,ns级别的,那么当触发定时任务时,有多大的概率能够在该A函数停留?这种不确定性增加了识别不可用函数或者代码的难度。

由于频繁的中断,pprof 不能一直打开,一般是抽样60ms以下的数据。一种思路是定时抽样并合并profile数据。

curl -o cpu.out  http://localhost:9981/debug/pprof/profile?seconds=30 
go tool pprof -http=localhost:8000  cpu.out

总结

代码覆盖率是判断代码书写的质量,识别无效代码的重要工具。在go生态中,go1.2提供了测试代码覆盖率的cover工具。

对于静态的代码,要识别代码没有被使用,可以使用golangci-lint工具

golangci-lint  run --disable-all  --enable unused

可以使用go test -cover工具

对于测试环境下有请求或长时间运行程序的单元覆盖率,可以借助cover工具使用文中巧妙的方式来测试。如果测试环境不充分完备,没有办法测试出来。线上统计函数是否被调用有两种方式倾入性和非倾入性。

主要是在关键位置注入一行函数进行统计。可以是函数级别的,甚至可以借助go test -cover 在每一个逻辑分支注入了函数。

如果只是考虑函数级别的,可以考虑直接shel脚本注入函数,这样做时间成本最低。也可以考虑借助AST抽象语法树的方式,成本略高。

如果是逻辑分支级别的,可以考虑借鉴开源库https://github.com/qiniu/goc 的手法来生成打桩后的go文件。它是对go test -cover 代码的封装,借助AST抽象语法树,在特定位置插入一行。

通过pprof,信号中断处理的手法,抽样获取堆栈信息。一些处理时间很短的函数,将很难被检测到。这种方式对于检测到经常使用的函数有用,但是不适合推断没有使用过的函数。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8