云原生系列Go语言篇-编写测试Part 2

本文来自正在规划的Go语言&云原生自我提升系列，欢迎关注后续文章。

检测代码覆盖率

代码覆盖率是一个非常有用的工具，可以知道是否漏掉了某些明显的状况。但达到100%的测试覆盖率并不能保证在某些输入下代码中没有错误。首先，我们会学习如何使用go test展示代码覆盖率，然后我们会了解仅依赖代码覆盖率的局限性。

在go test命令中添加-cover标记可以计算覆盖率信息，并在测试输出中添加摘要。如果再加上一个-coverprofile 的参数，可将覆盖率信息保存到一个文件中。我们再回到第15章的GitHub代码库的sample_code/table目录中，收集代码覆盖率信息：

$ go test -v -cover -coverprofile=c.out

如果检测表格测试的代码覆盖率，测试输出会显示一行信息，代码覆盖率为87.5%。虽然这是有用的信息，但我们更希望看到漏掉了哪些测试。Go 附带的cover工具会生成包含了这些信息的 HTML 表示：

$ go tool cover -html=c.out

运行该命令，应该会打开浏览器并能看到如图12-1的页面：

图12-1：初始测试代码覆盖率

每个测试过的文件都会出现在左上角的组合框中。源代码有三种颜色。灰色表不可测试的代码行，绿色表已被测试覆盖的代码，红色表未经测试的代码。通过观察颜色，可以看出我们没有对default分支编写测试，即对函数传递错误的运算符时。下面将这种情况添加到测试列表中：

{"bad_op", 2, 2, "?", 0, `unknown operator ?`},

重新运行go test -v -cover -coverprofile=c.out和go tool cover -html=c.out，可在图12-2中看到测试代码覆盖率为100%。

图12-2：最终测试代码覆盖率

代码覆盖率非常棒，但也有不足。虽然有100%的覆盖率，但代码中却有一个bug。不知读者有没有注意到？如果没有，可以添加另一个测试用例然后运行测试：

{"another_mult", 2, 3, "*", 6, ""},

可以看到如下错误：

table_test.go:57: Expected 6, got 5

在乘法用例中有一处笔误。对乘法使用了加号。（复制、粘贴代码时要格外小心！）修改代码，再次运行go test -v -cover -coverprofile=c.out和go tool cover -html=c.out，测试会正常通过。

警告：代码覆盖率很有必要，但并不足够。覆盖率为100%的代码仍可能存在bug。

基准测试

确定代码是快或慢非常复杂。我们不用自己计算，应使用Go测试框架内置的基准测试。下面来看第15章的GitHub代码库sample_code/bench目录下的函数：

func FileLen(f string, bufsize int) (int, error) {
    file, err := os.Open(f)
    if err != nil {
        return 0, err
    }
    defer file.Close()
    count := 0
    for {
        buf := make([]byte, bufsize)
        num, err := file.Read(buf)
        count += num
        if err != nil {
            break
        }
    }
    return count, nil
}

这个函数计算文件中的字数。它接收两个参数，文件名和用于读取文件的缓冲大小（稍后会讲到第二个参数的作用）。

在测试其速度前，应当测试代码运行是否正常。以下是简单的测试：

func TestFileLen(t *testing.T) {
    result, err := FileLen("testdata/data.txt", 1)
    if err != nil {
        t.Fatal(err)
    }
    if result != 65204 {
        t.Error("Expected 65204, got", result)
    }
}

下面来看运行该函数需要多长时间。我们的目标是找出该使用多大的缓冲区读取文件。

注：在花时间坠入优化的深渊之前，请明确程序需要进行优化。如果程序已经足够快，满足了响应要求，并且使用的内存量在接受范围之内，那么将时间花在新增功能和修复bug上会更好。业务的需求决定了何为"足够快"和"接受范围之内"。

在 Go 中，基准测试是测试文件中以单词Benchmark开头的函数，它们接受一个类型为*testing.B的参数。这种类型包含了*testing.T的所有功能，以及用于基准测试的额外支持。首先看一个使用 1 字节缓冲区的基准测试：

var blackhole int

func BenchmarkFileLen1(b *testing.B) {
    for i := 0; i < b.N; i++ {
        result, err := FileLen("testdata/data.txt", 1)
        if err != nil {
            b.Fatal(err)
        }
        blackhole = result
    }
}

blackhole 包级变量是有作用的。我们将 FileLen 的结果写入这个包级变量，以确保编译器不会自负到优化掉对 FileLen 的调用，而对基准测试产生破坏。

每个 Go 基准测试都必须有一个循环，从 0 迭代到 b.N。测试框架会一遍又一遍地调用我们的基准测试函数，每次传递更大的 N 值，直到确保时间结果准确为止。马上会在输出中看到这一点。

我们通过向go test传递-bench标记来运行基准测试。该标记接收一个正则表达式来描述要运行的基准测试名称。使用-bench=.来运行所有基准测试。第二个标记-benchmem在基准测试输出中包含内存分配信息。所有测试在基准测试之前运行，因此只有在测试通过时才能对代码进行基准测试。

以下是运行基准测试我电脑上的输出：

BenchmarkFileLen1-12  25  47201025 ns/op  65342 B/op  65208 allocs/op

运行含内存分配信息的基准测试输出有5列。分别如下：

• BenchmarkFileLen1-12

  基准测试的名称，中间杠，加用于测试的GOMAXPROCS的值。

• 25

  产生稳定输出运行测试的次数。

• 47201025 ns/op

  该基准测试运行单次通过的时间，单位是纳秒(1秒为1,000,000,000纳秒)。

• 65342 B/op

  基准测试单次通过所分配的字节数。

• 65208 allocs/op

  基准测试单次通过堆上分配字节的次数。其值小于等于字节的分配数。

我们已经得到1字节缓冲的结果，下面来看使用其它大小缓冲所得到的结果：

func BenchmarkFileLen(b *testing.B) {
    for _, v := range []int{1, 10, 100, 1000, 10000, 100000} {
        b.Run(fmt.Sprintf("FileLen-%d", v), func(b *testing.B) {
            for i := 0; i < b.N; i++ {
                result, err := FileLen("testdata/data.txt", v)
                if err != nil {
                    b.Fatal(err)
                }
                blackhole = result
            }
        })
    }
}

和使用t.Run启动表格测试类似，我们使用b.Run启动不同输入的基准测试。作者电脑上的结果如下：

BenchmarkFileLen/FileLen-1-12          25  47828842 ns/op   65342 B/op  65208 allocs/op
BenchmarkFileLen/FileLen-10-12        230   5136839 ns/op  104488 B/op   6525 allocs/op
BenchmarkFileLen/FileLen-100-12      2246    509619 ns/op   73384 B/op    657 allocs/op
BenchmarkFileLen/FileLen-1000-12    16491     71281 ns/op   68744 B/op     70 allocs/op
BenchmarkFileLen/FileLen-10000-12   42468     26600 ns/op   82056 B/op     11 allocs/op
BenchmarkFileLen/FileLen-100000-12  36700     30473 ns/op  213128 B/op      5 allocs/op

结果符合预期；随着缓冲区大小的增加，分配次数减少，代码运行速度更快，直至缓冲区大于文件的大小。当缓冲区大于文件大小时，会有额外的分配导致输出减慢。如果我们预期文件大致是这个大小，那么10,000 字节的缓冲区效果最佳。

但是有一个改动可以进一步提高性能。现在每次从文件获取下一组字节时都重新分配缓冲区。这是没必要的。如果我们在循环之前进行字节切片分配，然后重新运行基准测试，会看到提升：

BenchmarkFileLen/FileLen-1-12          25  46167597 ns/op     137 B/op  4 allocs/op
BenchmarkFileLen/FileLen-10-12        261   4592019 ns/op     152 B/op  4 allocs/op
BenchmarkFileLen/FileLen-100-12      2518    478838 ns/op     248 B/op  4 allocs/op
BenchmarkFileLen/FileLen-1000-12    20059     60150 ns/op    1160 B/op  4 allocs/op
BenchmarkFileLen/FileLen-10000-12   62992     19000 ns/op   10376 B/op  4 allocs/op
BenchmarkFileLen/FileLen-100000-12  51928     21275 ns/op  106632 B/op  4 allocs/op

现在分配的次数相同且较小，每个缓冲区大小仅需四次分配。有意思的是，我们现在可以作出权衡。如果内存紧张，可以使用较小的缓冲区大小，在牺牲性能的情况下节约内存。

Go代码性能调优

如果基准测试显示存在性能或内存问题，下一步是确定问题的具体原因。Go 包含了分析工具，可从正在运行的程序中收集 CPU 和内存使用数据，还有用于可视化和解释生成的数据的工具。甚至可以暴露一个 Web 服务端点，远程从运行的 Go 服务中收集分析信息。

讨论性能调优工具不在我们的范畴。线上有许多很好的资源提供相关信息。一个不错的起点是 Julia Evans 的博文使用 pprof 对 Go 程序做性能分析。