硬核：嵌入式代码覆盖率统计方法和经验

代码覆盖率是衡量软件测试完成情况的指标，通常基于测试过程中已检查的程序源代码比例计算得出。代码覆盖率可以有效避免包含未测试代码的程序被发布。

1. 问题背景

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

在进行代码测试时，常常使用代码覆盖率作为考核测试任务完整性的指标，并且代码覆盖率也被拿来作为衡量代码质量的度量，甚至客户常常要求交付的软件达到一定的代码覆盖率才能进行发布，因此代码覆盖率统计尤为重要。

C语言嵌入式软件的开发与普通的软件的开发很大的不同点就是需要采用交叉开发的方式，即开发工具运行在软硬件配置丰富的编译机上，而嵌入式应用程序则运行在软硬件资源相对缺乏的目标机上。面对C语言的覆盖率工具相对java等语言较少，而对嵌入式软件交叉编译后的工具更是凤毛麟角，所以嵌入式软件的代码覆盖率就成为了一个难题。

2. 解决方法

2.1 覆盖率工具

嵌入式开发一般使用GNU/GCC作为主要的编译器，GCOV是一个GNU/GCC的配套测试覆盖率的工具，是一款的免费的代码覆盖率测试工具，而且可以结合LCOV生成美观的html的测试报表。当对目标代码进行测试后，GCOV编译插桩后的程序会监视目标代码的执行情况，记录执行的代码行和未执行的代码行，并可以记录某代码行的执行次数，为分析代码的执行效率提供依据。

LCOV是GCOV的一个扩展工具，该扩展工具由一套Perl脚本组成，使基于GCOV的文本式输出实现了一下的增强的功能：

1.基于html的输出，使用条形图和不同的颜色来表。

2.支持大型项目，信息汇总页面提供三个层次的代码覆盖细节信息，目录试图、文件试图和源代码试图，允许快速浏览代码覆盖率数据。

2.2 原理简介

2.2.1 概念解释

下面对覆盖率技术的常见概念进行简单介绍。主要是基本块（Basic Block），基本块图（Basic Block Graph），行覆盖率（line coverage）, 分支覆盖率（branch coverage）等。

基本块（Basic Block），'A basic block is asequence of instructions with only entry and only one exit. If any one of theinstructions are executed, they will all be executed, and in sequence fromfirst to last.'  这里可以把基本块看成一行整体的代码，基本块内的代码是线性的，要不全部运行，要不都不运行。

基本块图（Basic Block Graph），基本块的最后一条语句一般都要跳转，否则后面一条语句也会被计算为基本块的一部分。如果跳转语句是有条件的，就产生了一个分支(arc)，该基本块就有两个基本块作为目的地。如果把每个基本块当作一个节点，那么一个函数中的所有基本块就构成了一个有向图，称之为基本块图(Basic Block Graph)。且只要知道图中部分BB或arc的执行次数就可以推算出所有的BB和所有的arc的执行次数。

图1 基本块图

打桩，意思是在有效的基本块之间增加计数器，计算该基本块被运行的次数；打桩的位置都是在基本块图的有效边上。

行覆盖率（line coverage），源代码有效行数与被执行的代码行的比率。

分支覆盖率（branch coverage），有判定语句的地方都会出现2个分支，整个程序经过的分支与所有分支的比率是分支覆盖率。注意，与条件覆盖率(condition coverage)有细微差别，条件覆盖率在判定语句的组合上有更细的划分。

2.2.2 编译选项

gcc需要静态注入目标程序编译选项，在编译链接的时候加入2个选项(-ftest-coverage -fprofile-arcs )，编译结束之后会生成 gcno文件，而经过静态注入的目标程序在“正常结束”后，会在运行目录下产生gcda数据文件，通过gcov工具就可产生覆盖率数据结果。

-ftest-coverage

让编译器生成与源代码同名的gcno文件（note file），这种文件含有重建基本块依赖图和将源代码关联至基本块及源代码行号的必要信息。

-fprofile-arcs

让编译器静态注入对每个源代码行关联的计数器进行操作的代码，并在链接阶段链入经态度libgcov.a，其中包含在程序正常结束时生成gcda文件的逻辑和记录弧跳变的次数及其他的概要信息。

在最终可执行程序进入用户代码入口函数之前调用 gcov_init()内部函数初始化统计数据区，并将gcov_exit()内部函数注册为代码出口。

当程序调用代码出口正常结束时，gcov_exit()内部函数得到调用，其继续调用__gcov_flush()内部函数输出统计数据并生成gcda文件，若程序是一个状态机程序不会自动调用代码出口时，需要增加定时器等方式调用__gcov_flush()内部函数强制输出gcda文件。

2.3 实践应用

利用GCOV和LCOV工具可以进行嵌入式代码覆盖率的统计，需要在Makefile或者Scons文件中做下面的编译链接设置，增加 -fprofile-arcs -ftest-coverage 或者 –coverage，链接的时候，增加 -fprofile-arcs 或者 –lgcov。

为了上述几个编译选项的使用不影响到正常的编译过程和效率。可以使用makefile中通过参数传递来支持覆盖率产生，可以在makefile使用下面的方式：

#代码覆盖率编译选项

ifeq (_CODE_COV,$(CODE))APP_FLAGS += -fprofile-arcs -ftest-coverageendif

#代码覆盖率链接选项

ifeq (_CODE_COV,$(CODE))LD_LINK_LIBFILTER +=  -fprofile-arcs -ftest-coverageendif

这样，可以使用 make CODE=_CODE_COV 来引入这些编译选项而不会影响到正常的编译。

将目标机生成的gcda文件放回至编译目录下，利用LCOV命令“lcov –directory. –capture –output file app.info”可以将gcno文件和gcda文件结合生成代码覆盖率结果info文件，再用LCOV命令“genhtml –o html app.info –title “LCOV–app.Info” –show-details -legend”将info文件和源代码文件结合转化为可视化网页形式。

图2 LCOV生成HTML结果

3. 高手总结方法

代码覆盖率等级

代码覆盖率可以通过多种方法测量。最常用的是测量以下一个或多个指标：语句覆盖率，分支 覆盖率，修订的条件/判定覆盖率（MC/DC）。以下章节中将逐一详解这些代码覆盖率。

语句覆盖率

语句覆盖率用来度量被测代码中的可执行语句是否被执行到，它并不考虑循环或者条件语句， 只针对语句度量可执行代码。应当特别注意的是：“语句”并不等同于代码行。

一般情况下，对于 C，C++，Java或Ada，分号代表语句结束。在某些情况下，一条语句会跨越多行代码。语句覆盖率可以有效度量可执行代码是否被执行，但同时也有一定的局限性。

语句覆盖率的局限

考虑如下图1的代码段：

int* p = NULL;

if (condition)

p = &variable;

*p = 123;

图 1 – 语句覆盖局限代码示例

如果“condition”为true，那么就有可能达到100%的语句覆盖，然而这个测试用例忽略了另一种情况：如果“condition”为假，程序将引用空指针，因此，虽然语句覆盖率是一个很好的度量指标，它仍旧是入门级的代码覆盖率。理想情况下，即使“condition”为false，测试用例也应当被计算。

分支覆盖率

分支覆盖率用来度量程序中所有的判定和分支以及相应的输出是否都被测试执行到，例如 “if”语句必须将“true”和“false”都考虑到以覆盖所有的输出。如果只有一个路径被执行，那么覆盖率将被标记为部分执行。

和语句覆盖率类似，分支覆盖浪费也有一些需要注意的细节，尤其在针对“惰性求值”的编程语言时，惰性求值是将代码的求值操作延迟到需要结果值时再进行的一项技术。

分支覆盖率的局限

典型的情况是当有复杂的布尔表达式的“惰性求值”出现时，如下图2的代码片段：

int* p = NULL;if (condition1 && (condition2 || function1(*p)))statement1;else

考虑“condition1”为假的情况，惰性求值将不会度量“condition2”或，此种情况同样会导致代码“if (condition1 && (condition2 || function1(*p)))”的分支覆盖率计算错误。

继续考虑“condition1”和“condition2”都为真的情况。惰性求值将再次导致“function1(*p)” 不会被度量，也同样会导致代码“if (condition1 && (condition2 || function1(*p)))”的分支覆盖率计算错误。在此种情况下，有可能出现分支覆盖率为100%但软件中仍有潜在缺陷的情况。

修订条件/判定覆盖率（MC/DC）

MC/DC是一种特殊的分支覆盖率，它不但会使用分支覆盖率报告复杂条件下的true和false输出，同时也会报告复杂条件下的全部分支条件输出。

MC/DC最初由波音公司创建，用于航空软件中DO-178B的A级认证。通过对所有的子条件输出分支的独立证明，有效解决了惰性求值带来的问题。

继续讨论代码示例2，我们需要在“condition2”和“function1(*p)”固定的条件下验证“condition1” 的“true”和“false”判定分支，之后继续固定“condition1”和“function1(*p)”验证“condition2” 的判定分支。

同样的，让我们在固定“condition1”和“condition2”的条件下讨论 “function1(*p)”。在其他分支条件固定的情况下验证某个分支条件的“true”和“false”值称作“MC/DC对”。MC/DC对一般 使用MC/DC真值表描述。表1就是一个MC/DC真值表示例。

在软件开发的不同阶段获取覆盖率

软件测试有很多种类，本文将其简要的分为三类：

> 系统/函数测试：测试集成后的整个应用

> 集成测试：测试集成的子系统

> 单元测试：测试一个或多个文件或类

每个软件项目在系统测试的过程中都会模拟最终用户的操作对源代码做一些系统测试。导致软件发布后仍旧存在缺陷最重要的一个原因通常是程序在运行过程中遇到了非预期的，即没有测试的输入组合。

很多软件项目并不是没有做集成测试或者单元测试。只是在完成集成测试或单元测试后，开发团队可能苦于为隔离程序中的单个或多个文必须所需的大量测试代码量。

对于最严格的单元测试和集成测试来说，最终生成的测试代码量比待测代码量还要庞大是很经常出现的情况。因此，这两种级别的测试普遍适用于关键和高安全领域，例如：航空航天、医疗、交通运输、工业过程控制、高速汽车等。此类软件中包含大量的嵌入式应用软件。

关键领域的结构化测试流程一般会将需求的级别高低作为重点，代码覆盖率因而会在这种“基于需求”的测试中进行分析。在许多项目中，高等级的需求最先被测试。此时代码覆盖率可以被用来检测和报告所达到的覆盖比例。

然而不幸的是，在系统测试和功能测试阶段想要达到100%的代码覆盖率几乎是不可能的。通常情况下系统测试和功能测试只能达到60%-70%的代码覆盖率，剩余30%-40%的代码覆盖率需要在单元测试和集成测试阶段才能够完成。

单元测试使用包含驱动和桩的测试代码隔离系统中的特定函数，同时使用测试用例模拟这些函数的执行。这些所谓的“低等级测试需求” 对被测试代码提供了更高的控制，可以提高先前执行的系统测试覆盖率（甚至能达到100%）。因此，在不同的测试之间共享覆盖率数据是非常有必要的。

嵌入式环境中获取覆盖率带来的挑战

常言道“有得必有失”，在嵌入式环境获取代码覆盖率的问题上，要付出的代价是对待测代码额外的插桩工作。插桩是将额外的代码添加到程序中，从而实现测试过程中的覆盖率收集和分析操作。

由于插桩的相关操作将导致程序源代码增多，进而延长程序的执行时间，因而需要预测插桩后的源代码的覆盖范围预测，尤其当测试实时嵌入式系统环境时，此项工作就更为重要。

事实上，要精准的预测程序文件插桩的影响几乎是不可能的。没有算法支持（也不可能有）。每个系统都包含很多的变量，具有独立唯一的复杂性。当然，对于典型的示例系统来说，获取一组准确的估计还是可能实现的。

在共享环境中获取覆盖率数据

在嵌入式环境下管理代码覆盖率的主要问题在于如何配置内存以容纳额外的插桩代码。VectorCAST针对大量示例代码评估后发现添加了上文中提出的各种覆盖率额外配置之后，源代码量增长量普遍达到了10%。对于绝大多数的32位目标板，这并不是一个很大的问题，但对于存储容量有限的8位或者16位目标板来说，几乎可以肯定这会是一个问题。

为了降低可执行文件的大小，各种各样的代码插桩技术被发明出来，针对不同大小的存储区域有不同的数据采集技术。植入存储器内部的收集系统可以用于监测被检测到的代码。这是插桩技术中保证使用最少RAM的关键技术。

4. 结语

通过以上的方法，可以统计C语言嵌入式代码覆盖率，统计结果为提高代码质量提供了有效的依据，也为衡量测试质量提供了重要的指标，并可以通过结果中的代码行执行次数进行效率分析。

然而，代码覆盖率并不能保证执行过的代码质量，也无法作为衡量生产力的指标，代码覆盖率的数据只能表明测试用例的覆盖代码的强度，只有保证测试用例的正确通过和较高的代码覆盖率相结合才能真正意义上提升代码的质量。

代码覆盖率能不能提高软件的可靠性？答案是肯定的，代码的覆盖率分析是保证软件质量最简便易行的方法。

END

---