转转fe增量代码覆盖率统计实现方案（侵入源代码）

1. 背景

代码覆盖率是衡量测试用例对代码的覆盖程度的指标，可以帮助开发人员和测试人员优化测试用例、提高代码质量。此外，代码覆盖率也可以帮助领导和项目经理评估开发进度和质量，以便及时调整计划和资源分配。总之，代码覆盖率功能对于保证软件质量、提高开发效率和降低维护成本都具有重要意义。转转公司内部已经成功实现了针对Java项目的增量代码覆盖率，但是前端项目的覆盖率并没有得到有效的监测和管理。为此我们开发了针对fe项目的增量代码覆盖率功能，并在本文中与大家分享我们的经验、挑战和解决方案。希望能够抛砖引玉，与各位同行进行深入的探讨和交流。

2. 技术选型

Istanbul, ScriptCover和JsCover都是常用的代码覆盖率工具，它们可以用于跟踪JavaScript代码的测试覆盖情况。下面是它们的简要对比：

工具特点Istanbul支持语句覆盖、分支覆盖、条件覆盖和路径覆盖等多种覆盖率度量，可以集成到各种测试框架中，生成的覆盖率报告通常以lcov格式输出ScriptCover支持语句覆盖、分支覆盖、条件覆盖等多种度量，可以集成到各种测试框架中，特点之一是可以在浏览器中实时查看代码覆盖率JsCover支持语句覆盖和分支覆盖，可以生成HTML格式的覆盖率报告，提供了直观的可视化界面来展示代码覆盖情况，可以集成到各种测试框架中

前端测试框架（如jest、karma、cypress）内置了代码覆盖率统计，统一使用了istanbul工具。istanbul是一种成熟的前端代码覆盖率技术方案，虽然维护不活跃，但几乎是唯一可选方案。诸多前端测试框架的覆盖率统计都使用了它，在一定程度上也能说明 istanbul 是可行的。它提供了插桩、合并和生成覆盖率报告的工具，但是没有完全适配转转的增量代码覆盖率的统计方案。因此我们基于istanbul设计了覆盖率统计流程，结合公司内部的后端代码覆盖率统计平台，完成了前端代码覆盖率的统计和可视化工作。

3. 实现方案

基于 istanbul 做的覆盖率统计大致可以分为以下五步：插桩，覆盖率数据收集，数据上报，数据接收，报告生成。

3.1 插桩

插桩是通过在源代码中插入特定的监测代码来跟踪程序运行过程中的路径和条件分支的执行情况。istanbul 只会对 js 代码插桩，也就是仅跟踪我们程序的逻辑执行。

测试代码如下：

function istanbul_test() { console.log('istanbul_test'); } function istanbul_test2() { console.log('istanbul_test2'); } var test = false if (test) { istanbul_test(); } else { istanbul_test2(); }

插桩后

对于前端来说，覆盖率主要有四个准则：

1.行覆盖率（Line Coverag）：是否每一行都执行了

2.函数覆盖率（Function Coverage）：是否每个函数都调用了

3.分支覆盖率（Branch Coverage）：是否每个分支都执行了

4.语句/指令/声明覆盖率（statement Coverage）：是否每个语句都执行了

在上述代码中可以看到，我们用 _cov 收集了文件中函数和语句的执行次数，由此就能知道代码有没有被覆盖（是否执行过）。

全局变量中记录了这些信息：

path：路径
s：statement 数量
b：branch 数量
f：function 数量
fnMap：function 的开始结束位置信息
statementMap：statement 的开始结束位置信息
branchMap： branch 的开始结束位置信息

覆盖率的原理就是对每个 statement、function、branch 都插入一段计数代码，记录在一个全局对象中。

需要注意的是插桩会侵入源码（会在代码中插入一些计数器），istanbul 统计前端代码覆盖率的这套方案设计上即是如此，因此难以避免会增加项目打包后的包体积。目前我们要求只在测试环境 编译代码时对发生变更的类进行插桩和覆盖率统计，因此不会影响生产环境的代码。虽然破坏了Devops的从测试到上线使用同一个包的基本原则，但是考虑到插桩的基本原理是插入计数器，原则认为他们能是同一个包。

3.2 数据收集

从用户浏览器中开始进行功能测试到用户关闭浏览器，这个过程中产生的覆盖率数据是累计的。如果我们能够获取到本次测试的”覆盖率对象”并将其存储起来，就能用来生成本次访问的覆盖率报告。

getAllCoverage() { const coverage = window.__coverage__ if(coverage == undefined) return [] return Object.entries(coverage).reduce((prev,cur)=>{ const [key,value] = cur prev.push({ pathName: key, coveredLines: this.getLines(value), totalLines: this.getLineCoverages(value) }) return prev },[]) } getLines(data = {}){ const lines = [] const { s = {}, statementMap = {} } = data Object.entries(s).forEach(([key,count])=>{ if(count > 0){ const { start, end } = statementMap[key] for(let i = start.line; i<= end.line; i ){ lines.push(i) } } }) return [...new Set(lines)] } getLineCoverages(data) { const lines = [] const { s = {}, statementMap = {} } = data Object.entries(s).forEach(([key,count])=>{ const { start, end } = statementMap[key] for(let i = start.line; i<= end.line; i ){ lines.push(i) } }) return [...new Set(lines)] }3.3 数据上报

我们通过webpack的插件来实现的数据上报，每10s上报一次数据到覆盖率统计平台或者用户关闭页面自动触发上报，由覆盖率统计平台对改动的代码进行统计，并对插桩成功和已覆盖行进行标注，生成增量代码覆盖率统计报告。

上报文件级别的代码行统计数据是生成可视化覆盖率报告的基础，为后续方便研发和测试人员查看代码的执行和覆盖情况提供数据支撑。针对转转当前测试环境申请标签并在标签上部署服务的现状，目前上报数据格式定义在（标签，服务，分支，用户）的维度，方便覆盖率统计平台快速统计用户在单个标签上的某个服务的覆盖率数据并完成格式化的展示。

const PAGE_META = window.__PAGE_META__ if(PAGE_META == undefined) return const submitData = { clusterName: PAGE_META.cluster, branchName: PAGE_META.branch, ipOrTagName: PAGE_META.tag, uniqId: this.uid, feClassCoverInfoList: data.map(item=>{ return { ...item, pathName: this.handlePath(item.pathName), } }), nowTimestamp: Date.now() }

通过构建工具，我们将页面中全部变量注入到 _window.PAGE_META 。从而在上报数据的时候，可以获取到项目信息、分支信息、插桩行和覆盖行信息，同时也方便开发者快速排查代码行是否覆盖的正确性问题。

此外，为了减少上报数据的量级，降低覆盖率统计系统处理数据的复杂度，我们只对发生变更的文件进行插桩和数据上报。通过构建平台在编译阶段向项目中写入增量目录到diffFileList.conf文件，然后在babel-plugin-istanbul中传入include参数来控制只对比增量。

3.4 数据接收

在功能测试阶段，覆盖率系统负责接收统计数据。如果上报数据的时间间隔太长会导致用户查看覆盖率有较大的延迟，如果间隔太短，会增加系统需要处理的数据量级，综合评估，目前我们将时间间隔定义为10S。

为了提高数据接收接口的性能，我们采用同步记录DB后立刻返回结果，线程异步处理历史数据的方案。在异步处理阶段，因为每个用户在同一个环境进行测试时，产生的覆盖率数据会一直上报最新的全量覆盖率数据，因此我们会对当前环境当前用户上报的数据进行预处理，将最新上报的数据和历史数据合并然后插入数据库，以便后续用户获取最终覆盖率结果时，减少需要处理的数据量，降低接口响应耗时。