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

 配景

对苹果开辟者而言，由于平台考核周期较长，客户端代码导致的线上题目影响时间每每比较久。假如在开辟、测试阶段可以或许提前暴露题目，就有助于避免线上变乱的发生。代码覆盖率检测正是资助开辟、测试同砚提前发现题目，保证代码质量的好帮助。
对于开辟者而言，代码覆盖率可以反馈两方面信息：

• 自测的充实程度。
  
• 代码筹划的冗余程度。
  

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

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

为相识决上述题目，我们深入调研了覆盖率报告的天生逻辑，并结合团队的开辟流程，开辟了一套嵌入在代码提交流程中、基于单次代码提交（git commit）天生报告、对开辟者透明的增量代码测试覆盖率工具。开辟者只必要正常开辟，通过模仿器测试开辟代码，commit 本次代码（commit 和测试顺序可互换），推送（git push）到远端，就可以在本地看到这次提交代码的详细覆盖率报告了。
本文分为两部门，先从介绍通用覆盖率检测的原理出发，让读者对覆盖率的网络、剖析有直观的认识。之后介绍我们增量代码测试覆盖率工具的实现。
覆盖率检测原理

天生覆盖率报告，起首必要在 Xcode 中配置编译选项，编译后会为每个可实验文件天生对应的 .gcno 文件；之后在代码中调用覆盖率分发函数，会天生对应的 .gcda 文件。
此中，.gcno 包罗了代码计数器和源码的映射关系， .gcda 记录了每段代码详细的实验次数。覆盖率剖析工具必要结合这两个文件给出末了的检测报表。接下来先看看 .gcno 的天生逻辑。
.gcno

利用 Clang 分别天生源文件的 AST 和 IR 文件，对比发现，AST 中不存在计数指令，而 IR 中存在用来记录实验次数的代码。搜刮 LLVM 源码可以找到覆盖率映射关系天生源码。覆盖率映射关系天生源码是 LLVM 的一个 Pass，（下文简称 GCOVPass）用来向 IR 中插入计数代码并天生 .gcno 文件（关联计数指令和源文件）。
下面分别介绍IR插桩逻辑和 .gcno 文件结构。
IR 插桩逻辑

代码行是否实验到，必要在运行中统计，这就必要对代码自己做一些修改，LLVM 通过修改 IR 插入了计数代码，因此我们不必要改动任何源文件，仅需在编译阶段增长编译器选项，就能实现覆盖率检测了。
从编译器角度看，根本块（Basic Block，下文简称 BB）是代码实验的根本单元，LLVM 基于 BB 进行覆盖率计数指令的插入，BB 的特点是：

• 只有一个入口。
  
• 只有一个出口。
  
• 只要根本块中第一条指令被实验，那么根本块内所有指令都会顺序实验一次。
  

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

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

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

1. - (void)guessNumberGame:(NSInteger)guessNumber
2. {
3.     NSLog(@"Welcome to the game");
4.     if (guessNumber == 10) {
5.         NSLog(@"Bingo!");
6.     } else {
7.         NSLog(@"You guess is wrong!");
8.     }
9. }

复制代码

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

图 1 桩点位置
.gcno计数符号和文件位置关联

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

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

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

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

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

图2 BB 结构和 BB 行信息结构
.gcda

入口函数

关于 .gcda 的天生逻辑，可参考覆盖率数据分发源码。这个文件中包罗了 __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函数范例）。

1. void __gcov_flush() {
2.     struct flush_fn_node *curr = flush_fn_head;
3.    
4.     while (curr) {
5.         curr->fn();
6.         curr = curr->next;
7.     }
8. }

复制代码

详细的分发逻辑

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

图3 __llvm_gcov_flush 代码示例

• __llvm_gcov_flush先调用了__llvm_gcov_writeout，来向 .gcda 写入覆盖率信息。
  
• 末了将计数数组清零__llvm_gcov_ctr.xx。
  

而 __llvm_gcov_writeout 逻辑为：

• 天生对应源文件的 .gcda 文件，写入 Magic number。
  
• 循环实验
  
  
  
  • llvm_gcda_emit_function: 向 .gcda 文件写入函数信息。
    
  • llvm_gcda_emit_arcs: 向 .gcda 文件写入BB实验信息，假如已经存在 .gcda 文件，会和之前的实验次数进行合并。
    
  
  
• 调用llvm_gcda_summary_info，写入校验信息。
  
• 调用llvm_gcda_end_file，写结束符。
  

感爱好的同砚可以自己天生 IR 文件查看更多细节，这里不再赘述。
.gcda 的文件/函数结构和 .gcno 根本一致，这里不再赘述，统计插桩信息结构如图 4 所示。定制化的输出也可以通过修改上述函数完成。我们的增量代码测试覆盖率工具解决代码 BB 结构变动后合并到已有 .gcda 文件不兼容的题目，也是修改上述函数实现的。

图4 计数桩输出结构
覆盖率剖析

在相识了如上所述 .gcno ，.gcda 天生逻辑与文件结构之后，我们以例 1 中的代码为例，来阐述剖析算法的实现。
例 1 中根本块 B0，B1 对应的 .gcno 文件结构如下图所示，从图中可以看出，BB 的主结构完全记录了根本块之间的跳转关系。

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

图6 B0，B1 对应行信息
在输入数字 100 的情况下，天生的 .gcda 文件如下：

图7 输入 100 得到的 .gcda 文件
通过控制流程图中节点出边的实验次数可以计算出 BB 的实验次数，核默算法为计算这个 BB 的所有出边的实验次数，不存在出边的情况下计算所有入边的实验次数（详细实现可以参考 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）：

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

方案权衡

由于 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 中的游戏增长一些提示，当输入比预设数字大时，我们就提示出来，反之亦然。

1. - (void)guessNumberGame:(NSInteger)guessNumber
2. {
3.     NSInteger targetNumber = 10;
4.     NSLog(@"Welcome to the game");
5.     if (guessNumber == targetNumber) {
6.         NSLog(@"Bingo!");
7.     } else if (guessNumber > targetNumber) {
8.         NSLog(@"Input number is larger than the given target!");
9.     } else {
10.         NSLog(@"Input number is smaller than the given target!");
11.     }
12. }

复制代码

这个题目困扰了我们好久，也推动了对覆盖率检测原理的调研。结合前面覆盖率检测的原理可以知道，不能合并的原因是天生的控制流程图比原来多了两条边（ .gcno 和旧的 .gcda 也不能匹配了），反映在 .gcda 上就是数组多了两个数据。思量到代码变动后，原有的覆盖率信息已经没有意义了，当发生边数不一致的时间，我们会删除掉旧的 .gcda 文件，只保存最新 .gcda 文件（有变动情况下 .gcno 会重新天生）。如下图所示：

图12 覆盖率冲突解决算法
团体流程图

结合上述流程，我们的增量代码测试覆盖率工具的团体流程如图 13 所示。
开辟者只需进行接入配置，再次运行时，工程中那些作为本地堆栈进行开辟的代码库会被自动插桩，并在 .git 目录插入 hooks 信息；当开辟者利用模仿器进行需求自测时，插桩统计效果会被自动分发出去；在代码被推到远端前，会根据插桩统计效果，天生仅包罗本次代码修改的详细增量代码测试覆盖率报告，以及向远端推送覆盖率信息；同时假如测试覆盖率小于 80% 会强制拒绝提交（可配置关闭，百分比可自界说），保证只有经过充实自测的代码才气提交到远端。

图13 增量代码测试覆盖率天生流程图
总结

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


from :
iOS 覆盖率检测原理与增量代码测试覆盖率工具实现 - 美团技术团队
日常开辟Guava提效工具库核心实用指南梳理_guava string转list-CSDN博客
从ES的JVM配置起步思考JVM常见参数优化_es jvm配置-CSDN博客
异步处理优化：多线程线程池与消息队列的选择与应用_模版模式利用-CSDN博客




免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。