详解代码覆盖率及各语言主流工具

更多内容关注微信公众号：fullstack888

代码覆盖（英语：Code coverage）是软件测试中的一种度量，描述程序中源代码被测试的比例和程度，所得比例称为代码覆盖率。

在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标，甚至，用代码覆盖率来考核测试任务完成情况，比如，代码覆盖率必须达到60%、80％或 90％。

最近做了一些关于代码覆盖率工具的调查，调研了一些主流的代码覆盖率的工具，本篇简要介绍：

• 代码覆盖率是什么？
• 为什么需要统计代码覆盖率？
• 代码覆盖率有哪些指标？
• 代码覆盖率的指标、工作方式和一些主流的代码覆盖率工具。

一、什么是代码覆盖率？

代码覆盖率是对整个测试过程中被执行的代码的衡量，它能测量源代码中的哪些语句在测试中被执行，哪些语句尚未被执行。

无论是单元测试、API测试、功能测试还是集成测试，本质上都是调用代码；如何评价测试的效率?这些测试是否真正全部或者大部分覆盖了产品的代码，这个时候，代码覆盖率（code coverage）就是一个比较有价值的参考指标了。

二、为什么需要统计代码覆盖率？

众所周知，测试可以提高软件版本的质量和可预测性。但是，你知道你的单元测试甚至是你的功能测试实际测试代码的效果如何吗？是否还需要更多的测试？

这些是代码覆盖率可以试图回答的问题。总之，出于以下原因我们需要测量代码覆盖率：

• 了解我们的测试用例对源代码的测试效果
• 了解我们是否进行了足够的测试
• 在软件的整个生命周期内保持测试质量举例：假设代码覆盖率只在某一些模块代码覆盖率很高，但在一些关键模块并没有足够的测试用例覆盖，那样虽然代码覆盖率很高，但并不能说明产品质量就很高。

注：代码覆盖率不是灵丹妙药，覆盖率测量不能替代良好的代码审查和优秀的编程实践。

通常，我们应该采用合理的覆盖目标，力求在代码覆盖率在所有模块中实现均匀覆盖，而不是只看最终数字的是否高到令人满意。

三、代码覆盖率有哪些的指标？

代码覆盖率工具通常使用一个或多个标准来确定你的代码在被自动化测试后是否得到了执行，常见的覆盖率报告中看到的指标包括（代码覆盖率达到 100% 不代表设计没有问题）：

• 分支覆盖率（Branch coverage）针对 if…else、case 等分支语句，看代码中设计的分支是否都被测试到了
• 语句覆盖率（Statement Coverage）语句覆盖率上不去时，可以查看未覆盖处的代码是测试用例的疏忽、冗余代码或是保护用途的代码，比如case的default（如果出现此类，一般是case的条件已经全部列出，可以将最后一个条件改为default）；
• 翻转覆盖率（Toggle coverage）包括两态翻转（0/1）和三态翻转（0/1/Z），常用的是两态翻转。对于单比特信号而言，若仿真用例使得该信号从0到1和从1到0的翻转均发生，则认为这里的翻转覆盖率是全面的（100%）。即使翻转覆盖率达到 100%，分支覆盖率和语句覆盖率也不一定达到 100%。
• 条件覆盖率（Conditional coverage）条件覆盖率可以看作是对分支覆盖率的补充。每一个分支条件表达式中，所有条件的覆盖。
• 状态机覆盖率（FSM coverage）状态机覆盖率主要检查当前状态到下一个状态的跳转是否都跳转过。

四、代码覆盖率是如何工作的？

代码覆盖率测量主要有以下三种方式：

1. Source code instrumentation - 源代码检测

将检测语句添加到源代码中，并使用正常的编译工具链编译代码以生成检测的程序集。这是我们常说的插桩，Gcov 是属于这一类的代码覆盖率工具。

2. Runtime instrumentation - 运行时收集

这种方法在代码执行时从运行时环境收集信息以确定覆盖率信息。以我的理解 JaCoCo 和 Coverage 这两个工具的原理属于这一类别。

3. Intermediate code instrumentation - 中间代码检测

通过添加新的字节码来检测编译后的类文件，并生成一个新的检测类。说实话，我 Google 了很多文章并找到确定的说明哪个工具是属于这一类的。

了解这些工具的基本原理，结合现有的测试用例，有助于正确的选择代码覆盖率工具。比如：

• 产品的源代码只有 E2E（端到端）测试用例，通常只能选择第一类工具，即通过插桩编译出的可执行文件，然后进行测试和结果收集。
• 产品的源代码有单元测试用例，通常选择第二类工具，即运行时收集。这类工具的执行效率高，易于做持续集成。

五、当前主流代码覆盖率工具

不同语言有不同的代码覆盖率工具，大家在选择的时候最好选择那种社区活跃度高、开源和网上评论好的工具。

- END -

往期回顾

◆Redis和Mysql如何保持数据一致性

◆谷歌公开了内部管理Infra层的两个工具的Paper

◆软件架构可能不是你想象的那个样子

◆容器与Pod到底有什么区别和联系？

◆如何从0到1进行电商平台订单系统的搭建？

◆SRE本质就是一个懂运维的资深开发

◆Spring Cloud应用的优雅下线与灰度发布

技术交流，请加微信： jiagou6688 ，备注：Java，拉你进架构