"聊点干货"

覆盖率技术基础

截止到 Go1.15.2 以前，关于覆盖率技术底层实现，以下知识点您应该知道：

package main

import "github.com/qiniu/goc/cmd"

func main() {CoverageVariableName.Count[0]++;
    cmd.Execute()
}

var CoverageVariableName = struct {
    Count     [1]uint32
    Pos       [3 * 1]uint32
    NumStmt   [1]uint16
} {
    Pos: [3 * 1]uint32{
        21, 23, 0x2000d, // [0]
    },
    NumStmt: [1]uint16{
        1, // 0
    },
}

依托于 go 语言官方强大的工具链，大家可以非常方便的做单测覆盖率收集与统计。但是集测/E2E 就不是那么方便了。不过好在我们现在有了https://github.com/qiniu/goc。

集测覆盖率收集利器 - Goc 原理

go test -cover_testmain.gogocgo test -c -cover
goc servergoc profile

整体架构参见:

代码覆盖率的最佳实践

技术需要为企业价值服务，不然就是在耍流氓。可以看到，目前玩覆盖率的，主要有以下几个方向:

  • 度量 - 深度度量，各种包，文件，方法度量，都属于该体系。其背后的价值在于反馈与发现。反馈测试水平如何，发现不足或风险并予以提高。比如常见的作为流水线准入标准，发布门禁等等。度量是基础，但不能止步于数据。覆盖率的终极目标，是提高测试覆盖率，尤其是自动化场景的覆盖率，并一以贯之。所以基于此，业界我们看到，做的比较有价值的落地形态是增量覆盖率的度量。goc diff 结合 Prow 平台也落地了类似的能力，如果您内部也使用 Kubernetes，不妨尝试一下。当然同类型的比较知名的商业化服务，也有 CodeCov/Coveralls 等，不过目前她们多数是局限在单测领域。

  • 精准测试方向 - 这是个很大的方向，其背后的价值逻辑比较清晰，就是建立业务到代码的双向反馈，用于提升测试行为的精准高效。但这里其实含有悖论，懂代码的同学，大概率不需要无脑反馈；不能深入到代码的同学，你给代码级别的反馈，也效果不大。所以这里落地姿势很重要。目前业界没还看到有比较好的实践例子，大部分都是解决特定场景下的问题，有一定的局限。

而相较于落地方向，作为广大研发同学，下面这些最佳实践可能对您更有价值：

  • 高代码覆盖率并不能保证高产品质量，但低代码覆盖率一定说明大部分逻辑没有被自动化测到。后者通常会增加问题遗留到线上的风险，当引起注意。
  • 没有普适的针对所有产品的严格覆盖率标准。实际上这更应该是业务或技术负责人基于自己的领域知识，代码模块的重要程度，修改频率等等因素，自行在团队中确定标准，并推动成为团队共识。
  • 低代码覆盖率并不可怕，能够主动去分析未被覆盖到的部分，并评估风险是否可接受，会更加有意义。实际上笔者认为，只要这一次的提交比上一次要好，都是值得鼓励的。

谷歌有篇博客 (见参考资料) 提到，其经验表明，重视代码覆盖率的团队通常会更加容易培养卓越工程师文化，因为这些团队在设计产品之初就会考虑可测性问题，以便能更轻松的实现测试目标。而这些措施反过来会促使工程师编写更高质量的代码，更注重模块化。

最后，欢迎加入七牛云 Goc 交流群，我们一起聊聊 goc，聊聊研发效能那些事。

更多工程效能、测开技术讨论可以关注公账号: 大卡尔

参考资料