测试覆盖率是一个术语，用于统计通过运行程序包的测试多少代码得到执行。 如果执行测试套件导致80％的语句得到了运行，则测试覆盖率为80％。
计算测试覆盖率的通常方法是埋点二进制可执行文件。 例如，GNU gcov 在二进制文件中设置执行分支断点。 当每个分支执行时，断点被清除，并且分支的目标语句被标记为“被覆盖”。
这种方法是成功和广泛使用的。 Go的早期测试覆盖工具甚至以相同的方式工作。但它有问题。 由于分析二进制文件的执行是很困难的，所以很难实现。 它还需要将执行跟踪绑定回源代码的可靠方法，这也可能是困难的。 那里的问题包括不正确的调试信息和诸如内联功能的问题, 使分析变得复杂。 最重要的是，这种方法非常不具有可移植性。 对于每个机器架构需要重新编写，在某种程度上,可能对于每个操作系统都需要重新编写，因为从系统到系统的调试支持差异很大。
Go 1.2 的发布引入了一个 test coverage 的新工具， 它采用了一种不寻常的方式来生成覆盖率统计数据，这种方法建立在Godoc的技术的基础上。
1 Go的测试覆盖率
对于Go的新测试覆盖工具，采取了一种避免动态调试的不同方法。 想法很简单：在编译之前重写包的源代码，以埋点，编译和运行修改的源，并转储统计信息。 重写很容易编排，因为 go的工具链 控制从源到测试到执行的整个流程。
示例代码如下：
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"
}测试代码如下：
type Test struct {
in int
out string
}
var tests = []Test{
{-1, "negative"},
{5, "small"},
}
func TestSize(t *testing.T) {
for i, test := range tests {
size := Size(test.in)
if size != test.out {
t.Errorf("#%d: Size(%d)=%s; want %s", i, test.in, size, test.out)
}
}
}执行代码覆盖率测试如下：
cd ../src/cover/size/ go test ./... -cover cd -
PASS coverage: 42.9% of statements ok _/home/parallels/program/org/github-pages/source/src/cover/size 0.001s /home/parallels/program/org/github-pages/source/_posts
启用测试覆盖后，/go test/ 运行 cover 工具，在编译之前重写源代码。 以下是重写后的 Size 函数：
func Size(a int) string {
GoCover.Count[0] = 1
switch {
case a < 0:
GoCover.Count[2] = 1
return "negative"
case a == 0:
GoCover.Count[3] = 1
return "zero"
case a < 10:
GoCover.Count[4] = 1
return "small"
case a < 100:
GoCover.Count[5] = 1
return "big"
case a < 1000:
GoCover.Count[6] = 1
return "huge"
}
GoCover.Count[1] = 1
return "enormous"
}上面示例的每个可执行部分用赋值语句进行注解，赋值语句用于在运行时做统计。 计数器与 cover 工具生成的第二个只读数据结构记录的语句的原始源位置相关联。 测试运行完成后，收集计数器，通过查看设置的数量的来计算百分比。
虽然分配注解看起来可能很昂贵，但是它被编译为单个“移动”指令。 因此，其运行时开销不大，运行典型（或更实际）测试时只增加约3％开销。 这使得把测试覆盖率作为标准开发流程的一部分是合情合理的。
2 查看结果
上面的例子的测试覆盖率很差。 为了探索具体为什么，需要 go test 写一个 coverage profile ， 这是一个保存收集的统计信息的文件，以便能详细地研究覆盖的细节。 这很容易做：使用 -coverprofile 标志来指定输出的文件：
cd ../src/cover/size/ go test -coverprofile=size_coverage.out
注： -coverprofile 标志自动设置 -cover 来启用覆盖率分析。
测试与以前一样运行，但结果保存在文件中。 要研究它们，需要运行 test coverage tool 。 一开始，可以要求 覆盖率 按函数分解，虽然在当前情况下没有太多意义，因为只有一个函数：
cd ../src/cover/size/ go tool cover -func=size_coverage.out
查看的更有趣的方式是获取 覆盖率信息注释的源代码 的HTML展示。 该显示由 -html 标志调用：
cd ../src/cover/size/ go tool cover -html=size_coverage.out
运行此命令时，浏览器将弹出窗口，已覆盖（绿色），未覆盖（红色）和 未埋点（灰色）。 下面是一个屏幕截图：
<img src="/images/go-test-cover-set.png"/>
有了这个信息页，问题变得很明显：上面忽略了几个 case 的测试！ 可以准确地看出具体是哪一个，这样可以轻松地提高的测试覆盖率。
3 热力图
源代码级方式来测试覆盖率的一大优点在于，可以很容易用不同的方式对代码进行埋点处理。 例如，不仅可以检测是否已执行了一个语句，而且还可以查询执行了多少次。
go test 命令接受 -covermode 标志将覆盖模式设置为三种设置之一：
- set: 每个语句是否执行？
- count: 每个语句执行了几次？
- atomic: 类似于 count, 但表示的是并行程序中的精确计数
set 是默认设置，上面示例已经看到了。 只有运行并行算法需要精确的计数时，才需要进行 atomic 设置。 它使用来自 sync/atomic 包的原子操作，这可能会相当昂贵。 然而，对于大多数情况， count 模式工作正常，并且像默认设置模式一样非常快。
下面来试试一个标准包， fmt 格式化包语句执行的计数。 进行测试并写出 coverage profile ，以便能够很好地进行信息的呈现。
go test -covermode=count -coverprofile=../src/cover/count.out fmt
这比以前的例子好的测试覆盖率。 （覆盖率不受覆盖模式的影响）可以显示函数细节：
go tool cover -func=../src/cover/count.out
HTML输出产生了巨大的回报：
go tool cover -html=../src/cover/count.out
pad 函数如下所示：
<img src="/images/go-test-cover-count.png"/>
注意绿色的强度是如何变化。 最明亮的绿色的代表较高的执行数; 较少灰暗的绿色代表较低的执行数。 甚至可以将鼠标悬停在语句上，以便在弹出的 tool tip 中提示实际计数。 test coverage 产生了关于函数执行的大量信息，在分析中很有用的信息。
4 基础块
你可能已经注意到，上一个示例中/ 有关于闭合大括号中间的行的计数/ 不是你所期望的那样。 这是因为一直以来 test coverage 都不是一个不精确的科学。
这里发生的很值得解释。 我们希望覆盖注解由程序中的分支划分，当二进制文件在传统方法中被调用时，它们是分开的。 不过，通过重写源代码很难做到这一点，因为分支没有明确展示在源代码中。
覆盖注解的作用是是埋点，通常由大括号来限定。 一般来说，使之工作正常是非常困难的。 所使用的算法的处理结果是闭合括号看起来像属于它配对的块，而开放大括号看起来像属于块之外。 一个更有趣的结果出现在如下的一个表达式中：
f() && g()
没有试图单独调用对f和g的调用，无论事实如何，它们总是看起来像是运行相同的次数。
公平来说，即使gcov在这里也有麻烦。 该工具使机制正确，但呈现是基于行的，因此可能会错过一些细微差别。
5 总结
这是关于 Go 1.2 test coverage 故事。 具有有趣实现的新工具不仅可以实现测试覆盖率的统计，而且易于解释，甚至可以提取 profile 信息。
测试是软件开发和的重要组成部分，/test coverage/ 为测试策略添加一个简单的标准。 走向前， test 和 cover 。
有疑问加站长微信联系（非本文作者）
