起点客户端精准化测试的演进之路

针对上面的这些问题，在开发的角度，我们希望能对测试的效率进行提升。

JaCoco默认场景下是不支持增量插入探针的，但在实际开发过程中，一般不太会对全量代码做检测，所以，我们需要改造JaCoco，为精准化测试平台提供增量探针功能。同时，还需要接入CI系统，与现有软件开发流程对接，完成「开发-测试-回归」的闭环。

大部分公司的CI系统都会采用Jenkins来搭建，起点在接入腾讯的蓝盾之前，也是采用的Jenkins，所以，整体的系统流程图如下所示。

1. 创建一个新的Jenkins Job，负责编译插桩包，在这个Job中，需要执行者输入：分支名、BaseCommitID和EndCommitID，这两个CommitID，就对应git diff中的对比id，Jenkins根据指定的CommitID和分支，拉取代码
2. 这个Job在执行编译后，会将这些参数在编译时写入App的asset目录下的具体文件
3. 测试下载增量包后进行手工测试，测试完毕后在App中的某个后门入口上传覆盖率文件
4. 覆盖率文件上传后，触发新的Jenkins Job，在上报的同时，App从文件中读取前一步写入到assert中的文件，将分支名、BaseCommitID和EndCommitID这些信息同时上报
5. 新的Jenkins Job拿到这些信息后，根据上报的CommitID和分支名等信息，重新进行一次编译，复刻第一次插桩包的编译过程
6. 这个Job编译完成后，在脚本中继续调用generateCoverageReport指令来生成报告，这个时候编译的产物就和编译插桩包的内容一模一样了

至此，我们就完成了从开发到测试，并支持完整CI流程的方案设计。

拓展增量实现

由于JaCoco Android Plugin在客户端没有增量的实现，所以，我们需要单独实现一套Plugin系统，在借助JaCoco探针的插入机制基础上，完成对增量代码的探针修改。

通常在增量修改方案有以下三种：

1. 增量方案1：在插桩时，对diff信息做增量，精确到行级别插桩

2. 增量方案2：插桩时做全量插桩，在生成报告时对diff信息做过滤，在报告级别做行增量

3. 增量方案3：插桩时对Class级别做diff过滤，并进行Class内的全量插桩，在生成报告时，针对diff信息的行级别做报告的过滤

这里我们选择的第三种方案来实现。这是一种性价比最高的方案，通过获取diff信息，在插件层不用做太多的修改，只需要过滤掉非diff的文件，而在生成报告时，再借助diff行号来做高亮展示即可。

在Gradle插件中，我们在Transform过程中来获取增量内容，借助Git diff的执行结果，过滤需要做增量的修改Class文件，相关代码如下所示。

增量探针的问题解决了，那么下面的问题就是如何获取diff信息了。在Git中，我们可以很方便的通过git diff命令来获取增量信息。

该命令格式如下所示，它用来对比不同commit（或分支）间的增量代码：git diff [<options>] <commit> <commit>

其中commit可以是分支名，也可以是commit的id，对比分支间的差异，可以简写为 git diff targetBranchName，表示对比当前分支与目标分支间的代码差异。diff文件的解析这里不做过多的解释，感兴趣的朋友可以参考我的博客 https://xuyisheng.top/diff/ 

获取到diff增量信息之后，就可以借助正则来获取我们需要的信息了——diff文件，以及该文件中的diff行号。

修改Report生成逻辑

一般来说，修改JaCoco的Report生成逻辑，通常是通过修改JaCoco Analyzer类的analyzeClass函数。但实际上，JaCoco的Report库，给我们提供了修改的接口。在修改之前，我们先来了解下JaCoco默认的Report机制。

原始报告解读

JaCoco覆盖率报告分为三层递进数据：Package——Class——Method，其覆盖率统计实际上是由内向外的。先了解下场景，我们修改了两行代码，并执行了其中一行。我们先看Method级别：

这里由于是增量代码检测，所以在MainActivity里面的所有代码中，只有有代码修改的两个方法有覆盖率数据，即test2和test3。其中test2执行了，所以其覆盖率为100%，而test3未执行，所以其覆盖率数据未0%。再来看看Class级别：

增量覆盖率的统计

在前面的插桩过程中，实际上我们已经拿到了「修改的文件」——「修改的具体行号」这样的一个对应关系文件，只要我们再读出JaCoco覆盖率文件中，这些修改的行，是否被执行的数据，其实就可以完成覆盖率的统计了，我们简单的定义「增量覆盖率」的统计规则：

• 该文件中被修改的代码中已执行或者部分执行的代码行数 / 该文件中被修改的所有代码行数 %

• 有了这些数据之后，我们也不需要再使用JaCoco的覆盖率报表了，直接使用自己的统计数据，而只需要最后跳转每个文件的源代码覆盖文件即可。

• 那么现在的问题就剩下如何拿到行是否被执行的覆盖率数据了。核心代码如下所示。

修改报表

JaCoco的原生报表，结构比较复杂，不适合展示和汇总，特别是不利于非技术人员的使用，所以，我们需要对原生报表进行修改，让报表更加直观。

所以，在梳理了覆盖率真正的需求之后，我们抽象出了新的覆盖率报表的必须项目：

• 文件名

• 已覆盖了多少行

• 总共修改了多少行

• 提交信息

• 覆盖率数据

这是汇总表，针对每个文件的详情，我们可以继续使用JaCoco的明细报表。在官方Demo中，我们发现，报表数据实际上都被解析到了IBundleCoverage中，所以，我们只需要遍历IBundleCoverage数据，就可以拿到JaCoco的统计数据，IBundleCoverage的统计维度和它原生的报表结构类似，最外层是packages数据，内部遍历是sourceFiles数据，再到内部，就能拿到行数据，在行数据中，就可以拿到该行是否被覆盖的状态，OK，顺着这个思路，我们就可以自己来统计相关的覆盖率数据了，在遍历的过程中，我们可以使用一些Map来保存遍历出来的数据，最后输出到文件中，通过自定义的HTML文件展示出来。核心代码如下所示。

这里有几个细节需要注意：

1. sourceFiles的firstLine和lastLine，封装了可执行的所有代码起始值（因为字节码中是不包含import和package信息的），所以这样会导致git diff信息中的import等修改不会被遍历到，这部分数据默认为已执行，需要手动处理掉
2. 前面分析了我们的增量逻辑，在插桩时，只对文件做增量，所以这个文件主要有修改，那么整个文件都会被插桩，而在JaCoco生成每个文件的覆盖率信息时，需要对行做过滤，将不在diff文件中的行设置为Empty，取消覆盖率的高亮显示

3. 在统计覆盖率时，我们进行了包容处理，即只要不是完全未执行的代码，我们都认为是已执行，这样做的原因主要是因为PARTLY_COVERED在Kotlin中经常会因为一些语法而产生一些无效的标识，而且有些场景下，一个条件分支的部分执行，就已经完成了逻辑的处理，所以，这样的计算也是合理的

上面这张图就是最终生成的覆盖率报告，点击相关类，就可以跳转到相关的类详细覆盖率文件界面，这里是复用的JaCoco覆盖率展示页面，这里不再赘述。