最近做了一系列的单元测试相关的工作，除了各种规范及测试框架以外，讨论比较多的就是关于代码覆盖率的产生，c/c++与其他的一些高级语言或者脚本语言相比较而言，例如 Java、.Net和php/python/perl/shell等，由于没有这些高级语言和脚本语言的反射的特性，其代码覆盖率的产生过程会稍微复杂一些。发现许多同学对C++的覆盖率如何产生在都不太清楚，这里做一个简单的介绍。
一、基本使用方法
在Linux上的c/c++开发一般都使用gcc/g++作为主要的编译器，如果需要产生覆盖率数据需要在Makefile或者Scons文件中做下面的编译链接设置，
- 编译的时候，增加 -fprofile-arcs -ftest-coverage 或者 –coverage；
- 链接的时候，增加 -fprofile-arcs 或者 –lgcov；
- 打开–g3 选项，去掉-O2以上级别的代码优化选项；否则编译器会对代码做一些优化，例如行合并，从而影响行覆盖率结果；
基本要求就上面三点，但有一个建议，为了上述几个编译选项的使用不影响到正常的编译过程（否则会极大地影响程序的运行效率）。在使用makefile中通过参数传递来支持覆盖率产生，可以在makefile使用下面的方式，
ifeq ($(coverage), yes)
CXXFLAGS += -fprofile-arcs -ftest-coverage
LINKERCXX += -fprofile-arcs -ftest-coverage
OPT_FLAGS = -g3
endif
这样，可以使用 make coverage=yes 来引入这些编译选项而不会影响到正常的编译（scons同理）。
二、简单示例
这里写了一个简单的程序做测试，主要包含三个文件：Rectangle.cpp, RectangleTest.cpp, Makefile。
1）Rectangle.cpp 是被测代码，里面定义了一个简单的类Rectangle（长方形），里面有三个方法：
- set_values()，设置长方形对象的长和宽；
- area()，求长方形的面积；
- lenth()，求长放形的周长；
2）RectangleTest.cpp 是一个简单的测试程序，为了demo使用，并没有使用cppunit/gtest这样的单元测试框架，直接使用了main()函数来调用Rectangle里面的方法；
Rectangle.cpp和RectangleTest.cpp的代码如下图，
3）Makefile比较简单，主要支持在coverage=yes的参数支持。 可以使用-fprofile-arcs -ftest-coverage 选项，这里为了简化使用了 –coverage。
覆盖率产生的过程如下面四个步骤所示，其中步骤3和4，根据需要使用其中一种即可。
1. 编译链接带覆盖率参数的源代码；
2. 运行测试程序；
3. 使用gcov获取文本形式的覆盖率数据；
4. 使用lcov获取html形式的覆盖率数据；
下面针对本例，做这一过程的逐步演示。
1. 编译链接带覆盖率参数的源代码；
由于Makeifle中已经支持了coverage=yes选项，直接运行 “make coverage=yes”，这个时候会产生测试程序，并同时生成gcno文件（关于gcno文件的详细解释，参见第三部分背后原理），如下图，
2. 运行测试程序；
运行./RectangleTest 测试程序，运行结束后，会针对所有的cpp源代码文件产生相应的*.gcda文件（关于gcda文件的详细解释，参见第三部分背后原理），如下图
3. 使用gcov获取文本形式的覆盖率数据；
需要注意的是，这个步骤不是必须的，如果需要文本格式（*.gcov）的覆盖率结果，可是走这个步骤。如果想看html格式的结果，直接跳过这一步骤。gcov是gcc自带的覆盖率结果产生工具，无需单独安装。
针对某个源代码文件，例如 Rectangle.cpp，执行”gcov Rectangle.cpp” 会产生Rectangle.cpp.gcov文件。
这是一个存文本文件，可以通过vim打开，看到详细的行覆盖率数据，如下
4. 使用lcov获取html形式的覆盖率数据；
有些时候需要使用html结果的数据展示，这样看起来更加直观一些。IBM开源了lcov这个工具，更多参见 http://ltp.sourceforge.net/coverage/lcov.php
工具使用，如下图，
手动把cc_result目录拷贝到http/apache等服务器的htdocs目录下，可以通过浏览器来查看覆盖率结果，如下，
整个覆盖率生成的流程按照上面四个步骤就可以搞定。下面一节对其原理做简单的阐述。
三、基本原理
1. 术语解释
在了解背后原理之前，需要对覆盖率技术的一些概念有简单的了解。主要是基本块（Basic Block），基本块图（Basic Block Graph），行覆盖率（line coverage）, 分支覆盖率（branch coverage）等。
- 基本块（Basic Block），”A basic block is a sequence of instructions with only entry and only one exit. If any one of the instructions are executed, they will all be executed, and in sequence from first to last.” 这里可以把基本块看成一行整体的代码，基本块内的代码是线性的，要不全部运行，要不都不运行；
- 基本块图（Basic Block Graph），基本块的最后一条语句一般都要跳转，否则后面一条语句也会被计算为基本块的一部分。 如果跳转语句是有条件的，就产生了一个分支(arc)，该基本块就有两个基本块作为目的地。如果把每个基本块当作一个节点，那么一个函数中的所有基本块就构成了一个有向图，称之为基本块图(Basic Block Graph)。且只要知道图中部分BB或arc的执行次数就可以推算出所有的BB和所有的arc的执行次数；
- 打桩，意思是在有效的基本块之间增加计数器，计算该基本块被运行的次数；打桩的位置都是在基本块图的有效边上；
- 行覆盖率（line coverage），源代码有效行数与被执行的代码行的比率；
- 分支覆盖率（branch coverage），有判定语句的地方都会出现2个分支，整个程序经过的分支与所有分支的比率是分支覆盖率。注意，与条件覆盖率(condition coverage)有细微差别，条件覆盖率在判定语句的组合上有更细的划分。
gcc需要静态注入目标程序编译选项，在编译链接的时候加入2个选项(-ftest-coverage -fprofile-arcs )，编译结束之后会生成 *.gcno 文件，而经过静态注入的目标程序在“正常结束”后，会在运行目录下产生*.gcda数据文件，通过gcov工具就可产生覆盖率数据结果。
-ftest-coverage
Produce a notes file that the gcov code-coverage utility (see gcov—a Test Coverage Program) can use to show program coverage. Each source file’s note file is called auxname.gcno. Refer to the -fprofile-arcs option above for a description of auxname and instructions on how to generate test coverage data. Coverage data matches the source files more closely if you do not optimize.让编译器生成与源代码同名的.gcno文件（note file），这种文件含有重建基本块依赖图和将源代码关联至基本块的必要信息；
-fprofile-arcs
Add code so that program flow arcs are instrumented. During execution the program records how many times each branch and call is executed and how many times it is taken or returns. When the compiled program exits it saves this data to a file called auxname.gcda for each source file. The data may be used for profile-directed optimizations (-fbranch-probabilities), or for test coverage analysis (-ftest-coverage). Each object file’s auxname is generated from the name of the output file, if explicitly specified and it is not the final executable, otherwise it is the basename of the source file. In both cases any suffix is removed (e.g. foo.gcda for input file dir/foo.c, ordir/foo.gcda for output file specified as -o dir/foo.o). See Cross-profiling.
让编译器静态注入对每个源代码行关联的计数器进行操作的代码，并在链接阶段链入经态度libgcov.a，其中包含在程序正常结束时生成*.gcda文件的逻辑；
下面通过源码解析来说明到底这2个选项做了什么。通过g++ -S选项，产生汇编语言Rectangle.s 和 Rectangle_cc.s (增加–coverage选项），命令如下，
g++ -c -o Rectangle.s Rectangle.cpp -g -Wall -S
g++ -c -o Rectangle_cc.s Rectangle.cpp -g -Wall –coverage -S
vimdiff Rectangle.s 和 Rectangle_cc.s，如下图
通过这样汇编语言的对比，可以看出gcc通过这2个参数，把打桩的过程完成了。
更深入的内容，例如，如果想知道gcno/gcda文件的格式，可以参考 @livelylittlefish 的一篇文章，GCC Coverage代码分析-.gcda/.gcno文件及其格式分析（http://blog.csdn.net/livelylittlefish/article/details/6448885）。
四、扩展话题
通过上面三部分的介绍，相信绝大多数覆盖率问题都可以解决，下面2个问题是我们在实际运行过程中遇到的，也分享一下。
- 覆盖率的结果只有被测试到的文件会被显示，并非所有被编译的代码都被作为覆盖率的分母
实际上，可以看到整个覆盖率的产生的过程是4个步骤的流程，一般都通过外围脚本，或者makefile/shell/python来把整个过程自动化。2个思路去解决这个问题，都是通过外围的伪装。第一个，就是修改lcov的 app.info ，中间文件，找到其他的文件与覆盖率信息的地方，结合makefile，把所有被编译过的源程序检查是否存于 app.info 中，如果没有，增加进去。第二个伪装，是伪装 *.gcda，没有一些源码覆盖率信息的原因就是该文件没有被调用到，没有响应的gcda文件产生。toast（http://toast.taobao.org/）是通过第一种伪装来实现的，更多了解需要去看下开源代码。
其实上述覆盖率信息的产生，不仅可以针对单元测试，对于功能测试同样适用。但功能测试，一般linux下c/c++都是实现了某个Daemon进程，而覆盖率产生的条件是程序需要正常退出，即用户代码调用 exit 正常结束时，gcov_exit 函数才得到调用，其继续调用 __gcov_flush 函数输出统计数据到 *.gcda 文件中。同样2个思路可以解决这个问题，
第一，给被测程序增加一个 signal handler，拦截 SIGHUP、SIGINT、SIGQUIT、SIGTERM 等常见强制退出信号，并在 signal handler 中主动调用 exit 或 __gcov_flush 函数输出统计结果。但这个需要修改被测程序。这个也是我们之前的通用做法。但参加过清无同学的一个讲座后，发现了下面第二种更好的方法。
第二，借用动态库预加载技术和 gcc 扩展的 constructor 属性，我们可以将 signalhandler 和其注册过程都封装到一个独立的动态库中，并在预加载动态库时实现信号拦截注册。这样，就可以简单地通过如下命令行来实现异常退出时的统计结果输出了。
五、其他编程语言
- c/c++, 本文介绍的方法；
- Java, Maven cobertura 插件；
- Python, PyUnit + coverage.py；
- Php, phpunit + –coverage-html ;
- Perl, Test::Class 和 Devel::Cover;
- Shell, shUnit2 + shcov;
