一、前文回顾
在上一次的文章中，介绍了谷歌关于代码覆盖率最佳实践经验的探讨。内容总结如下：
代码覆盖的使用对软件开发流程的提高有显著的益处。
单一使用代码覆盖（来评估测试效果）能否减少软件缺陷是一个仍有争议的研究问题，但是我们的经验表明，努力提高代码覆盖有助于改进整个工程效率，长此以往就能达到减少代码缺陷的效果。
高代码覆盖率并不能保证高质量的测试效果，但低代码覆盖率则一定表明产品中存在大量的测试漏洞。
实际生产中并没有一个通用于所有产品的“理想的代码覆盖”，想要或需要测试到达的程度应该根据以下因素具体情况具体设定：（1）代码对业务的影响力或者代码的重要性；（2）代码更新的频率；（3）代码的生存周期，复杂度，以及它所包含的领域变量。
总的说来，很多产品的代码覆盖都偏低，我们应该致力在整个行业内显著提高代码覆盖。
在代码覆盖率上我们不需过分追求精益求精，比如，把代码覆盖率从90%提高到95%。
对测试缺口进行分析能帮助我们对未被覆盖的代码（和功能）及其导致的风险可接受程度进行人为判断。
代码覆盖率低的产品可以采取具体的递进的办法来逐步改进它。
确保经常变动的代码能被测试覆盖。
单元测试的代码覆盖只是保证产品质量的一部分。
对于没有达到代码覆盖标准的产品发布我们应当采用门禁机制。
在接下来几期里，我们将深入详细介绍代码覆盖在谷歌中的具体应用。
二、文章概述
在谷歌，代码覆盖率计算系统每天都要对超过十亿行使用七种不同编程语言的代码进行覆盖率的测量计算。为了使这样大规模的测量计算在实际操作中具有可行性，一个关键因素是测量的时机和范围的选择。谷歌选择将其应用在代码变更集（changesets）和代码审查（code review）中。这篇论文介绍了谷歌的代码覆盖系统的基础架构，以及这些代码覆盖信息是如何被视觉化和应用的。论文也讨论了大规模采用代码覆盖的挑战和解决方案。为了了解程序员是如何在日常工作中应用和看待代码覆盖的，我们对3000多名程序员进行了调查，在这篇论文中我们公布了其中512份合格的答复；同时，我们也分析报告了5年以来搜集的相关数据，包括代码覆盖的采用率，错误率，以及平均代码覆盖率。最后，这篇论文对如何在工业环境中布局使用代码覆盖提出了具体的建议。
以上是全论文的摘要，论文将分几期详细介绍给大家。前两期主要介绍代码覆盖系统的架构和功能，以及如何克服技术上的难题而实现这些功能。后续将报告谷歌的开发人员使用这个代码覆盖系统的具体反馈与成效。具体地，本期对该覆盖系统的开发背景，覆盖率的类型和计算范围，以及基础架构进行概括介绍，下一期将对该系统的每一个组成模块及其功能作具体介绍。
三、代码覆盖系统的现状及架构功能
代码覆盖在大型软件开发中使用的现状：
尽管代码覆盖在软件工程的研究中被广泛使用，它在实际开发中对提高测试效果的有效性一直存有争议，并且它在工业中的应用也并不统一 [1, 2]。一份关于IBM使用代码覆盖的大型调查报告显示[3] ，代码覆盖的采用会导致测试用例质量的提升；但是，代码覆盖使用的难易度及其可扩展性是决定它是否会被第一时间采纳的主要因素。
为了解决上述顾虑，谷歌花了超过十年的时间不断改进它的代码覆盖系统，并实现和验证学术界的各种方法。谷歌的代码覆盖系统支持七种编程语言，可以处理十亿级别的代码量，以及每天上万条的代码提交。这篇论文详细描述了谷歌代码覆盖系统的基础架构，讨论了在实现这个基础架构中遇到的技术难题和设计方案。这个系统已经集成在整个软件开发流程中的多个节点，本论文也将介绍这些集成的细节，并通过分析五年搜集的历史数据以及对512名程序员的调查回复，报告该系统在谷歌内部的采用率和有效性。
谷歌代码覆盖自动化测量系统:
谷歌的代码覆盖系统测量的是代码行覆盖率（line coverage），也就是被一组测试用例执行的代码的行数占总的代码行数的百分比。需要注意的是，代码中的空白行和注释行均不包含在内。因为谷歌严格制定并执行了各种主流编程语言的代码规范和格式 [4]，所以在谷歌的代码库里，代码行覆盖率和常用的指令覆盖率（statement coverage）是强相关的。
针对C++，Java和Python编写的代码，谷歌的代码覆盖系统也测量分支覆盖率（branch coverage），也就是有多大比例的条件语句（比如，if 语句）分支被给一组测试用例执行。分支覆盖率与控制流程图（CFG）里所有条件边的覆盖率是等效的。
这篇论文从两个范围来讨论代码覆盖率：
1. 项目覆盖（率）：一个项目里所有测试用例所覆盖的代码行相对于这个项目所有代码行的比率。每一个项目每天计算一次项目覆盖。
2. 代码变更集覆盖（率）：所有*项目*里所有测试用例的代码行覆盖率的总和。特别的，这里的*项目*指被代码变更集影响的项目，也即那些代码路径出现在代码变更集中的项目。每一个代码变更集都会被计算一次到多次代码覆盖率。具体的，它又可以被细分为两类：
（1）总体覆盖率：对于出现在变更集里的文件中的所有代码的覆盖率
（2）变量覆盖率：仅仅对于在变更集中被修改或添加的代码行的覆盖率 （被删除的代码行不再存在，因此也不会被覆盖）
这篇论文只考虑了那些在单一机器上执行的测试用例的代码覆盖率，通常情况下也是单进程程序。在谷歌，这类测试用例被通俗称为单元测试。这篇论文没有讨论更加复杂的涉及运行多台机器的测试类别（比如集成或系统测试）。集成测试的核心是测试（子）系统之间的交互情况而不是单个（子）系统内部的执行情况，对这类测试，代码行覆盖率并不是最合适的测量单位。
谷歌的代码覆盖系统架构从2012年投入开发，期间不断迭代更新以提高兼容性和解决各种技术难题。图3给出了这个系统的架构概览，包括四层结构和五个模块。
下一期将对该系统的每一个组成模块及其功能作具体介绍。
[1] Gopinath, R., Jensen, C., and Groce, A. Code coverage for suite evaluation by developers. In Proceedings of the 36th International Conference on Software Engineering (2014), ACM, pp. 72–82.
[2] Inozemtseva, L., and Holmes, R. Coverage is not strongly correlated with test suite effectiveness. In Proceedings of the 36th International Conference on Software Engineering (2014), ACM, pp. 435–445.
[3] Piwowarski, P., Ohba, M., and Caruso, J. Coverage measurement experience during function test. In Proceedings of the 15th international conference on Software Engineering (1993), IEEE Computer Society Press, pp. 287–301. https://ieeexplore.ieee.org/document/346035
[4] Inc., G. Google C++ Style Guide. https://google.github.io/styleguide/cppguide.html.
来源：Code Coverage at Google. 27th Joint European SoftwareEngineering Conference and Symposium on the Foundations of Software Engineering, 2019. https://doi.org/10.1145/3338906.3340459
原作者：Marko Ivanković, Goran Petrović, René Just, and Gordon Fraser.
原文网址：https://www.researchgate.net/publication/334259697_Code_Coverage_at_Google
译者：shower
日期：2021-03-12
审校：shower ，土司阿哈
图片文章来源：土司阿哈：致力于提供最具价值的测试及测试管理领域原创文章。包括测试技术、测试方法、测试思想、测试管理等。
