iOS 覆盖率检测原理与增量代码测试覆盖率工具实现

男娘i 2023-10-18 13:11 100阅读 0赞

## 背景 ##

对苹果开发者而言，由于平台审核周期较长，客户端代码导致的线上问题影响时间往往比较久。如果在开发、测试阶段能够提前暴露问题，就有助于避免线上事故的发生。代码覆盖率检测正是帮助开发、测试同学提前发现问题，保证代码质量的好帮手。

对于开发者而言，代码覆盖率可以反馈两方面信息：

1.  自测的充分程度。
2.  代码设计的冗余程度。

尽管代码覆盖率对代码质量有着上述好处，但在 iOS 开发中却使用的不多。我们调研了市场上常用的 iOS 覆盖率检测工具，这些工具主要存在以下四个问题：

1.  第三方工具有时生成的检测报告文件会出错甚至会失败，**开发者对覆盖率生成原理不了解**，遇到这类问题容易弃用工具。
2.  第三方工具**每次展示全量的覆盖率报告，会分散开发者的很多精力在未修改部分**。而在绝大多数情况下，开发者的关注重点在本次新增和修改的部分。
3.  **Xcode 自带的覆盖率检测只适用于单元测试场景**，由于需求变更频繁，**业务团队开发单元测试的成本很高**。
4.  已有工具**很难和现有开发流程结合起来**，需要额外进行测试，运行覆盖率脚本才能获取报告文件。

为了解决上述问题，我们深入调研了覆盖率报告的生成逻辑，并结合团队的开发流程，开发了**一套嵌入在代码提交流程中、基于单次代码提交（git commit）生成报告、对开发者透明的增量代码测试覆盖率工具**。开发者只需要正常开发，通过模拟器测试开发代码，commit 本次代码（commit 和测试顺序可交换），推送（git push）到远端，就可以在本地看到这次提交代码的详细覆盖率报告了。

本文分为两部分，先从介绍通用覆盖率检测的原理出发，让读者对覆盖率的收集、解析有直观的认识。之后介绍我们增量代码测试覆盖率工具的实现。

## 覆盖率检测原理 ##

生成覆盖率报告，首先需要在 Xcode 中配置编译选项，编译后会为每个可执行文件生成对应的 **.gcno** 文件；之后在代码中调用覆盖率分发函数，会生成对应的 **.gcda** 文件。

其中，.gcno 包含了代码计数器和源码的映射关系， .gcda 记录了每段代码具体的执行次数。覆盖率解析工具需要结合这两个文件给出最后的检测报表。接下来先看看 .gcno 的生成逻辑。

### .gcno ###

利用 Clang 分别生成源文件的 AST 和 IR 文件，对比发现，AST 中不存在计数指令，而 IR 中存在用来记录执行次数的代码。搜索 LLVM 源码可以找到[覆盖率映射关系生成源码][Link 1]。覆盖率映射关系生成源码是 LLVM 的一个 Pass，（下文简称 **GCOVPass**）用来向 IR 中插入计数代码并生成 .gcno 文件（关联计数指令和源文件）。

下面分别介绍IR插桩逻辑和 .gcno 文件结构。

#### IR 插桩逻辑 ####

代码行是否执行到，需要在运行中统计，这就需要对代码本身做一些修改，LLVM 通过修改 IR 插入了计数代码，因此我们不需要改动任何源文件，仅需在编译阶段增加编译器选项，就能实现覆盖率检测了。

从编译器角度看，基本块（[Basic Block][]，下文简称 BB）是代码执行的基本单元，LLVM 基于 BB 进行覆盖率计数指令的插入，BB 的特点是：

1.  只有一个入口。
2.  只有一个出口。
3.  只要基本块中第一条指令被执行，那么基本块内所有指令都会**顺序执行一次**。

覆盖率计数指令的插入会进行两次循环，外层循环遍历编译单元中的函数，内层循环遍历函数的基本块。函数遍历仅用来向 .gcno 中写入函数位置信息，这里不再赘述。

一个函数中基本块的插桩方法如下：

1.  统计所有 BB 的后继数 n，创建和后继数大小相同的数组 ctr\[n\]。
2.  以后继数编号为序号将执行次数依次记录在 ctr\[i\] 位置，对于多后继情况根据条件判断插入。

举个例子，下面是一段猜数字的游戏代码，当玩家猜中了我们预设的数字10的时候会输出`Bingo`，否则输出`You guessed wrong!`。这段代码的控制流程图如图1所示。

- (void)guessNumberGame:(NSInteger)guessNumber
    {
        NSLog(@"Welcome to the game");
        if (guessNumber == 10) {
            NSLog(@"Bingo!");
        } else {
            NSLog(@"You guess is wrong!");
        }
    }

例1 猜数字游戏

这段代码如果开启了覆盖率检测，会生成一个长度为 6 的 64 位数组，对照插桩位置，方括号中标记了桩点序号，图 1 中代码前数字为所在行数。

![20181228111139428][]  
图 1 桩点位置

#### .gcno计数符号和文件位置关联 ####

.gcno 是用来保存计数插桩位置和源文件之间关系的文件。**GCOVPass** 在通过两层循环插入计数指令的同时，会将文件及 BB 的信息写入 .gcno 文件。写入步骤如下：

1.  创建 .gcno 文件，写入 Magic number(oncg+version)。
2.  随着函数遍历写入文件地址、函数名和函数在源文件中的起止行数（标记文件名，函数在源文件对应行数）。
3.  随着 BB 遍历，写入 BB 编号、BB 起止范围、BB 的后继节点编号（标记基本块跳转关系）。
4.  写入函数中BB对应行号信息（标注基本块与源码行数关系）。

从上面的写入步骤可以看出，**.gcno** 文件结构由四部分组成：

*  文件结构
 *  函数结构
 *  BB 结构
 *  BB 行结构

通过这四部分结构可以完全还原插桩代码和源码的关联，我们以 BB 结构 / BB 行结构为例，给出结构图 2 (a) BB 结构，(b) BB 行信息结构，在本章末尾**覆盖率解析**部分，我们利用这个结构图还原代码执行次数（每行等高格代表 64bit）：

![20181228111139473][]  
图2 BB 结构和 BB 行信息结构

### .gcda ###

#### 入口函数 ####

关于 .gcda 的生成逻辑，可参考[覆盖率数据分发源码][Link 2]。这个文件中包含了 `__gcov_flush()`函数，这个函数正是分发逻辑的入口。接下来看看 `__gcov_flush()`如何生成 .gcda 文件。

通过阅读代码和调试，我们发现在二进制代码加载时，调用了`llvm_gcov_init(writeout_fn wfn， flush_fn ffn)`函数，传入了`_llvm_gcov_writeout`（写 gcov 文件），`_llvm_gcov_flush`（gcov 节点分发）两个函数，并且根据调用顺序，分别建立了以文件为节点的链表结构。（`flush_fn_node * ，writeout_fn_node *`）

`__gcov_flush()`代码如下所示，当我们手动调用`__gcov_flush()`进行覆盖率分发时，会遍历`flush_fn_node *`这个链表（即遍历所有文件节点），并调用分发函数`_llvm_gcov_flush`（curr->fn 正是`__llvm_gcov_flush`函数类型）。

void __gcov_flush() {
        struct flush_fn_node *curr = flush_fn_head;
        
        while (curr) {
            curr->fn();
            curr = curr->next;
        }
    }

#### 具体的分发逻辑 ####

观察`__llvm_gcov_flush`的 IR 代码，可以看到：

![20181228111139525][]  
图3 \_\_llvm\_gcov\_flush 代码示例

1.  `__llvm_gcov_flush`先调用了`__llvm_gcov_writeout`，来向 .gcda 写入覆盖率信息。
2.  最后将计数数组清零`__llvm_gcov_ctr.xx`。

而`__llvm_gcov_writeout`逻辑为：

1.  生成对应源文件的 .gcda 文件，写入 Magic number。
2.  循环执行  
    `llvm_gcda_emit_function`: 向 .gcda 文件写入函数信息。
    
    `llvm_gcda_emit_arcs`: 向 .gcda 文件写入BB执行信息，**如果已经存在 .gcda 文件，会和之前的执行次数进行合并**。
3.  调用`llvm_gcda_summary_info`，写入校验信息。
4.  调用`llvm_gcda_end_file`，写结束符。

感兴趣的同学可以自己生成 IR 文件查看更多细节，这里不再赘述。

.gcda 的**文件/函数结构和 .gcno 基本一致**，这里不再赘述，统计插桩信息结构如图 4 所示。定制化的输出也可以通过修改上述函数完成。我们的增量代码测试覆盖率工具解决代码 BB 结构变动后合并到已有 .gcda 文件不兼容的问题，也是修改上述函数实现的。

![20181228111139571][]  
图4 计数桩输出结构

#### 覆盖率解析 ####

在了解了如上所述 .gcno ，.gcda 生成逻辑与文件结构之后，我们以例 1 中的代码为例，来阐述解析算法的实现。

例 1 中基本块 B0，B1 对应的 .gcno 文件结构如下图所示，从图中可以看出，BB 的主结构完全记录了基本块之间的跳转关系。

![20181228111139622][]  
图5 B0，B1 对应跳转信息

B0，B1 的行信息在 .gcno 中表示如下图所示，B0 块因为是入口块，只有一行，对应行号可以从 B1 结构中获取，而 B1 有两行代码，会依次把行号写入 .gcno 文件。

![20181228111139664][]  
图6 B0，B1 对应行信息

在输入数字 100 的情况下，生成的 .gcda 文件如下：

![20181228111140702][]  
图7 输入 100 得到的 .gcda 文件

通过控制流程图中节点出边的执行次数可以计算出 BB 的执行次数，**核心算法为计算这个 BB 的所有出边的执行次数，不存在出边的情况下计算所有入边的执行次数**（具体实现可以参考 [gcov 工具源码][gcov]），对于 B0 来说，即看 index=0 的执行次数。而 B1 的执行次数即 index=1，2 的执行次数的和，对照上图中 .gcda 文件可以推断出，B0 的执行次数为 ctr\[0\]=1，B1 的执行次数是 ctr\[1\]+ctr\[2\]=1， B2 的执行次数是 ctr\[3\]=0，B4 的执行次数为 ctr\[4\]=1，B5 的执行次数为 ctr\[5\]=1。

经过上述解析，最终生成的 HTML 如下图所示（利用 lcov）：

![20181228111140748][]  
图8 覆盖率检测报告

以上是 Clang 生成覆盖率信息和解析的过程，下面介绍美团到店餐饮 iOS 团队基于以上原理做的增量代码测试覆盖率工具。

## 增量代码覆盖率检测原理 ##

### 方案权衡 ###

由于 gcov 工具（和前面的 .gcov 文件区分，gcov 是覆盖率报告生成工具）生成的覆盖率检测报告可读性不佳，如图 9 所示。我们做的增量代码测试覆盖率工具是基于 lcov 的扩展，报告展示如上节末尾图 8 所示。

![20181228111140797][]  
图9 gcov 输出，行前数字代表执行次数，\#\#\#\# 代表没执行

比 gcov 直接生成报告多了一步，**lcov 的处理流程是将 .gcno 和 .gcda 文件解析成一个以 .info 结尾的中间文件**（这个文件已经包含全部覆盖率信息了），之后通过[覆盖率报告生成工具][Link 3]生成可读性比较好的 HTML 报告。

结合前两章内容和覆盖率报告生成步骤，覆盖率生成流程如下图所示。考虑到增量代码覆盖率检测中代码增量部分需要通过 Git 获取，比较自然的想法是用 git diff 的信息去过滤覆盖率的内容。根据过滤点的不同，存在以下两套方案：

1.  通过 **GCOVPass** 过滤，只对修改的代码进行插桩，每次修改后需重新插桩。
2.  通过 .info 过滤，一次性为所有代码插桩，获取全部覆盖率信息，过滤覆盖率信息。

![20181228111140834][]  
图10 覆盖率生成流程

分析这两个方案，第一个方案需要自定义 LLVM 的 Pass，进而会引入以下两个问题：

*  只能使用开源 Clang 进行编译，不利于接入正常的开发流程。
 *  每次重新插桩会丢失之前的覆盖率信息，多次运行只能得到最后一次的结果。

而第二个方案相对更加轻量，只需要过滤中间格式文件，不仅可以解决我们在文章开头提到的问题，也可以避免上述问题：

*  可以很方便地加入到平常代码的开发流程中，甚至对开发者透明。
 *  未修改文件的覆盖率可以叠加（有修改的那些控制流程图结构可能变化，无法叠加）。

因此我们实际开发选定的过滤点是在 .info 。在选定了方案 2 之后，我们对中间文件 .info 进行了一系列调研，确定了文件基本格式（函数/代码行覆盖率对应的文件的表示），这里不再赘述，具体可以参考[ .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 文件获取的不确定性。整个流程如下：

![20181228111140877][]  
图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 会重新生成）。如下图所示：

![20181228111140924][]  
图12 覆盖率冲突解决算法

#### 整体流程图 ####

结合上述流程，我们的增量代码测试覆盖率工具的整体流程如图 13 所示。

开发者只需进行接入配置，再次运行时，工程中那些作为本地仓库进行开发的代码库会被自动插桩，并在 .git 目录插入 hooks 信息；当开发者使用模拟器进行需求自测时，插桩统计结果会被自动分发出去；在代码被推到远端前，会根据插桩统计结果，生成仅包含本次代码修改的详细增量代码测试覆盖率报告，以及向远端推送覆盖率信息；同时如果测试覆盖率小于 80% 会强制拒绝提交（可配置关闭，百分比可自定义），保证只有经过充分自测的代码才能提交到远端。

![20181228111140978][]  
图13 增量代码测试覆盖率生成流程图

## 总结 ##

以上是我们在代码开发质量方面做的一些积累和探索。通过对覆盖率生成、解析逻辑的探究，我们揭开了覆盖率检测的神秘面纱。开发阶段的增量代码覆盖率检测，可以帮助开发者聚焦变动代码的逻辑缺陷，从而更好地避免线上问题。

## 作者介绍 ##

丁京，iOS 高级开发工程师。2015 年 2 月校招加入美团到店餐饮事业群，目前负责大众点评 App 美食频道的开发维护。

王颖，iOS 开发工程师。2017 年 3 月校招加入美团到店餐饮事业群，目前参与大众点评 App 美食频道的开发维护。

### 招聘信息 ###

到店餐饮技术部交易与信息技术中心，负责点评美食用户端业务，服务于数以亿计用户，通过更好的榜单、真实的评价和完善的信息为用户提供更好的决策支持，致力于提升用户体验；同时承载所有餐饮商户端线上流量，为餐饮商户提供多种营销工具，提升餐饮商户营销效率，最终达到让用户“Eat Better、Live Better”的美好愿景！我们的团队包含且不限于 Android、iOS、FE、Java、PHP 等技术方向，已完备覆盖前后端技术栈。只要你来，就能点亮全栈开发技能树。诚挚欢迎投递简历至 [wangkang@meituan.com][wangkang_meituan.com]。

### 参考资料 ###

*  [覆盖率数据分发源码][Link 2]
 *  [覆盖率映射关系生成源码][Link 1]
 *  [基本块介绍][Basic Block]
 *  [gcov 工具源码][gcov]
 *  [覆盖率报告生成工具][Link 3]
 *  [ .info 生成文档][.info]

![2018122811114127][]

[Link 1]: https://github.com/llvm-mirror/llvm/blob/release_70/lib/Transforms/Instrumentation/GCOVProfiling.cpp
[Basic Block]: https://en.wikipedia.org/wiki/Basic_block
[20181228111139428]: https://img-blog.csdnimg.cn/20181228111139428
[20181228111139473]: https://img-blog.csdnimg.cn/20181228111139473
[Link 2]: https://github.com/llvm-mirror/compiler-rt/blob/release_70/lib/profile/GCDAProfiling.c
[20181228111139525]: https://img-blog.csdnimg.cn/20181228111139525
[20181228111139571]: https://img-blog.csdnimg.cn/20181228111139571
[20181228111139622]: https://img-blog.csdnimg.cn/20181228111139622
[20181228111139664]: https://img-blog.csdnimg.cn/20181228111139664
[20181228111140702]: https://img-blog.csdnimg.cn/20181228111140702
[gcov]: http://www.opensource.apple.com/source/gcc/gcc-5484/gcc/gcov.c
[20181228111140748]: https://img-blog.csdnimg.cn/20181228111140748
[20181228111140797]: https://img-blog.csdnimg.cn/20181228111140797
[Link 3]: http://ltp.sourceforge.net/coverage/lcov/genhtml.1.php
[20181228111140834]: https://img-blog.csdnimg.cn/20181228111140834
[.info]: https://manpages.debian.org/stretch/lcov/geninfo.1.en.html
[20181228111140877]: https://img-blog.csdnimg.cn/20181228111140877
[20181228111140924]: https://img-blog.csdnimg.cn/20181228111140924
[20181228111140978]: https://img-blog.csdnimg.cn/20181228111140978
[wangkang_meituan.com]: mailto:wangkang@meituan.com
[2018122811114127]: https://img-blog.csdnimg.cn/2018122811114127