转转App代码覆盖率方案

代码覆盖率是业内常用的统计代码被执行程度的手段。覆盖率数据结果是对测试工作的一种保证，可以赢得信任、增加上线信心。今天就让我们来聊聊 转转App代码覆盖率方案的实现及应用，希望可以给大家带来一些思路和参考。

3、数据上报、接收、存储：

（1）什么时候上报数据

如果频繁上报，可能会影响App的正常使用，也并没有必要。所以考虑在一些 察觉不到/不太Care的 操作节点进行数据上报。

• Android：页面的创建、不可见、销毁 时 上报

• iOS：App 启动、退后台、唤醒 时上报

（2）上报哪些内容

• project: 与 代码覆盖率服务约定的唯一 覆盖率项目名，区分终端，如zhuanzhuanAndroid / zhuanzhuanIos

• version: 版本号

• uniqueId: methodMapping 文件上传时时间戳，文件的唯一标识

• record: 数组数据

（3）数据存储

服务端接收数据后，根据project、version、uniqueId，查询出记录的 record数据，与上报的record 数据 做按位或计算，即 只要有1出现，该位即为1，已覆盖，再将结果存储起来

所以覆盖率数据都是按 uniqueId 进行区分存储的，即每个安装包的覆盖率数据都单独存储。

4、数据合并计算：

（1）两个安装包的覆盖率数据如何合并

数据库中存储的覆盖率数据是每个安装包的数据以及基础信息，当两个安装包并不是同一个Tag，有代码差异的时候，是不能直接进行按位或计算合并数据的。

这时 methodMapping文件就起到了作用。查找到两个安装包对应的methodMapping文件，对其中的内容进行解析，就可以分别获得两个安装包中的所有类名、方法名、方法签名等信息. 通过循环对比，即可进行数据合并：

为了区分两个不同Tag的安装包，方便后续描述的理解，这里将Tag创建时间较早的安装包称之为Old, 将Tag创建时间较晚的安装包称之为New.

• 遍历New 的Mapping数据

• 如果Old 的Mapping数据中 有相同的方法签名，则方法内部的所有逻辑分支进行被执行状态的合并计算

• 如果Old 的Mapping数据中没有相同的方法签名，则认为该方法为新增/修改过的方法，被执行状态以 New 的覆盖率数据为准

最终会得到以New 的代码为准的覆盖率数据，即相对较新代码的整体覆盖率数据

（2）要合并哪些安装包

我们存储了那么多安装包的覆盖率数据，那么在实际的客户端迭代流程中，我们应该合并哪些安装包的数据，才可以帮助我们进行分析，实现我们的方案目的呢？

我们对 单次打包纬度、单Tag纬度、版本纬度、分支纬度 几种统计纬度进行了利弊分析&对比，最后我们选择使用分支纬度进行覆盖率数据的汇总统计，即根据Tag的前后节点关系，合并同一分支线上的所有Tag（以前一版本的发版Tag为起点，以当前分支线中最新的Tag为终点）的所有安装包的覆盖率数据。

 （3）多个安装包的数据集如何快速合并

为了保证合并计算效率，采用多线程来处理。

• 以前一版本的发版Tag为起点，以当前分支线中最新的Tag为终点，根据记录的Tag前后节点关系，查询出分支线中的Tag列表，再查询出对应的所有安装包覆盖率数据集

• 多线程分别合并数据集

流程

1、简化流程