增量代码覆盖率检测原理
方案权衡
由于 gcov 工具（和前面的 .gcov 文件区分，gcov 是覆盖率报告生成工具）生成的覆盖率检测报告可读性不佳，如图 9 所示。我们做的增量代码测试覆盖率工具是基于 lcov 的扩展，报告展示如上节末尾图 8 所示。
图9 gcov 输出，行前数字代表执行次数，##### 代表没执行
比 gcov 直接生成报告多了一步，lcov 的处理流程是将 .gcno 和 .gcda 文件解析成一个以 .info 结尾的中间文件（这个文件已经包含全部覆盖率信息了），之后通过覆盖率报告生成工具生成可读性比较好的 HTML 报告。
结合前两章内容和覆盖率报告生成步骤，覆盖率生成流程如下图所示。考虑到增量代码覆盖率检测中代码增量部分需要通过 Git 获取，比较自然的想法是用 git diff 的信息去过滤覆盖率的内容。根据过滤点的不同，存在以下两套方案：
通过 GCOVPass 过滤，只对修改的代码进行插桩，每次修改后需重新插桩。
通过 .info 过滤，一次性为所有代码插桩，获取全部覆盖率信息，过滤覆盖率信息。
图10 覆盖率生成流程
分析这两个方案，第一个方案需要自定义 LLVM 的 Pass，进而会引入以下两个问题：
只能使用开源 Clang 进行编译，不利于接入正常的开发流程。
每次重新插桩会丢失之前的覆盖率信息，多次运行只能得到最后一次的结果。
而第二个方案相对更加轻量，只需要过滤中间格式文件，不仅可以解决我们在文章开头提到的问题，也可以避免上述问题：
可以很方便地加入到平常代码的开发流程中，甚至对开发者透明。
未修改文件的覆盖率可以叠加（有修改的那些控制流程图结构可能变化，无法叠加）。
因此我们实际开发选定的过滤点是在 .info 。在选定了方案 2 之后，我们对中间文件 .info 进行了一系列调研，确定了文件基本格式（函数/代码行覆盖率对应的文件的表示），这里不再赘述，具体可以参考 .info 生成文档。
增量代码测试覆盖率工具的实现
前一节是实现增量代码覆盖率检测的基本方案选择，为了更好地接入现有开发流程，我们做了以下几方面的优化。
降低使用成本
在接入方面，接入增量代码测试覆盖率工具只需一次接入配置，同步到代码仓库后，团队中成员无需配置即可使用，降低了接入成本。
在使用方面，考虑到插桩在编译时进行，对全部代码进行插桩会很大程度降低编译速度，我们通过解析 Podfile（iOS 开发中较为常用的包管理工具 CocoaPods 的依赖描述文件），只对 Podfile 中使用本地代码的仓库进行插桩（可配置指定仓库），降低了团队的开发成本。
对开发者透明
接入增量代码测试覆盖率工具后，开发者无需特殊操作，也不需要对工程做任何其他修改，正常的 git commit 代码，git push 到远端就会自动生成并上传这次 commit 的覆盖率信息了。
为了做到这一点，我们在接入 Pod 的过程中，自动部署了 Git 的 pre-push 脚本。熟悉 Git 的同学知道，Git 的 hooks 是开发者的本地脚本，不会被纳入版本控制，如何通过一次配置就让这个仓库的所有使用成员都能开启，是做好这件事的一个难点。
我们考虑到 Pod 本身会被纳入版本控制，因此利用了 CocoaPods 的一个属性 script_phase，增加了 Pod 编译后脚本，来帮助我们把 pre-push 插入到本地仓库。利用 script_phase 插入还带来了另外一个好处，我们可以直接获取到工程的缓存文件，也避免了 .gcno / .gcda 文件获取的不确定性。整个流程如下：
图11 pre-push 分发流程
覆盖率累计
在实现了覆盖率的过滤后，我们在实际开发中遇到了另外一个问题：修改分支/循环结构后生成的 .gcda 文件无法和之前的合并。 在这种情况下，__gcov_flush会直接返回，不再写入 .gcda 文件了导致覆盖率检测失败，这也是市面上已有工具的通用问题。
而这个问题在开发过程中很常见，比如我们给例 1 中的游戏增加一些提示，当输入比预设数字大时，我们就提示出来，反之亦然。
- (void)guessNumberGame:(NSInteger)guessNumber
{
NSInteger targetNumber = 10;
NSLog(@"Welcome to the game");
if (guessNumber == targetNumber) {
NSLog(@"Bingo!");
} else if (guessNumber > targetNumber) {
NSLog(@"Input number is larger than the given target!");
} else {
NSLog(@"Input number is smaller than the given target!");
}
}
这个问题困扰了我们很久，也推动了对覆盖率检测原理的调研。结合前面覆盖率检测的原理可以知道，不能合并的原因是生成的控制流程图比原来多了两条边（ .gcno 和旧的 .gcda 也不能匹配了），反映在 .gcda 上就是数组多了两个数据。考虑到代码变动后，原有的覆盖率信息已经没有意义了，当发生边数不一致的时候，我们会删除掉旧的 .gcda 文件，只保留最新 .gcda 文件（有变动情况下 .gcno 会重新生成）。如下图所示：
图12 覆盖率冲突解决算法
整体流程图
结合上述流程，我们的增量代码测试覆盖率工具的整体流程如图 13 所示。
开发者只需进行接入配置，再次运行时，工程中那些作为本地仓库进行开发的代码库会被自动插桩，并在 .git 目录插入 hooks 信息；当开发者使用模拟器进行需求自测时，插桩统计结果会被自动分发出去；在代码被推到远端前，会根据插桩统计结果，生成仅包含本次代码修改的详细增量代码测试覆盖率报告，以及向远端推送覆盖率信息；同时如果测试覆盖率小于 80% 会强制拒绝提交（可配置关闭，百分比可自定义），保证只有经过充分自测的代码才能提交到远端。
图13 增量代码测试覆盖率生成流程图
总结
以上是我们在代码开发质量方面做的一些积累和探索。通过对覆盖率生成、解析逻辑的探究，我们揭开了覆盖率检测的神秘面纱。开发阶段的增量代码覆盖率检测，可以帮助开发者聚焦变动代码的逻辑缺陷，从而更好地避免线上问题。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
