背景

结合代码设计测试用例能够有效提高测试精准度，为此我们研发了一种可以实时收集代码覆盖率的工具 Timon。Timon 与公司容器化构建系统 ZAE 打通；支持 Java、 Python 和 Golang 三种语言的覆盖率统计；能够产出全量和增量代码覆盖率报告；支持合并覆盖率数据；可以在接口测试和集成测试等场景使用。Timon 工具支持 90% 以上自动化接口用例的覆盖率统计；使用 Timon 辅助功能测试的 QA，增量代码覆盖率平均达到 80% 以上。在以下的内容中，文章将介绍工具的原理和使用实践。

测试覆盖率工具选择

我们选择的测试覆盖率工具包括 Jacoco、Coverage.py 和 go test 命令。各工具的详细介绍可以在官网中查看，文章不再赘述。表 2.1 对比了三种工具。其中 Jacoco 使用 On-the-fly 的模式插桩已满足使用需求。 Coverage.py 和 go test 需要杀掉应用进程才能获取报告。 go test 需要在编译阶段进行插桩。

表 2.1 工具对比

原理和模块设计

在编译阶段，我们对代码进行插桩。部署阶段，Timon 客户端被部署到容器当中。开启应用时，ZAE 将自动修改应用启动命令，以启动 Timon 客户端。Timon 工具包括两个大的模块：客户端和服务端。客户端又有三个子模块，分别对应三种语言。主要职责是上传容器信息、监听端口、请求配置文件、生成覆盖率原始数据文件、上传代码 diff 信息等。服务端的主要功能包括增量代码覆盖率计算、生成配置文件、历史数据管理、报告展示界面等。详细的模块列表可以查看系统模块图（图3.1 ）。下面将介绍工具重点功能的实现方法。

图 3.1 系统模块

1、编译阶段插桩

Golang 应用需要在编译阶段进行代码插桩才可以统计覆盖率数据。开发在 CI 配置文件中加入如下配置后，ZAE 平台自动完成插桩过程。配置文件包含的信息包括项目源码、目标文件以及各服务入口的路径。ZAE 在检测到插桩配置后，首先将 Timon 客户端提供的 test 文件放到服务入口所在的目录中，然后在生成的 Jenkinsfile 中插入编译命令。Python 和 Java 语言的项目不需要在编译阶段插桩。

2、部署阶段初始化

Timon 客户端在启动的时候，会进行上传容器信息、监听端口、请求配置文件等操作。图 3.2 展示了客户端的初始化过程。

图 3.2 Timon 客户端初始化过程

Timon 客户端启动之后的主要任务是监听覆盖率报告请求、容器销毁信息并上传覆盖率报告。因为代码更新后，测试联调环境会自动部署新版本的代码并销毁当前容器，所以 Timon 客户端需要在容器销毁前上传覆盖率数据。Java 语言覆盖率检测工具采用的方案是每 10 分钟上传一次覆盖率数据。但是 Go 和 Python 语言的覆盖率检测工具需要重启应用才能上传，为了不让服务进程频繁重启，我们采用了另一种方案：Timon 客户端监听系统发给容器的销毁信号，收到信号后客户端上传覆盖率数据。除此之外用户请求生成覆盖率报告时，Timon 客户端也会实时上传覆盖率报告。

3、上传覆盖率数据

一个用户从请求当前部署版本覆盖率报告到获得报告的时序图见图 3.3。假设某个测试环境当中只有一个应用，这个应用有三个容器提供服务，Timon 服务器等待容器一和二上传原始数据后，向容器三发送原始数据集合，最后容器三合并数据后，生成 html 格式的全量代码覆盖率报告。如果测试环境有多个应用，那么时序图当中的过程是并行进行的。在容器销毁前，保存覆盖率原始数据的方案也是类似的。

图 3.3 客户端与服务器端交互时序图

4、计算覆盖率数据

统计覆盖率的方式有分支覆盖率和可执行代码覆盖率等。在实践中通常通过可执行代码来计算覆盖率，Timon 也是如此。增量代码覆盖率的计算需要代码与主分支的 diff 数据和全量代码覆盖率报告。分子是增量代码且已经覆盖的执行代码行数，其中会去除测试文件等非业务代码文件。分母是增量代码部分执行代码的行数。为了能够帮助使用者及时找到增量代码，我们对第三方工具生成的报告做了一些修改。比如 Java 的增量代码覆盖率报告中只显示有增量代码的文件，在浏览器直接搜索「新增代码」即可跳转到增量代码位置。Golang 和 Python 语言的覆盖率报告也有类似的功能。

图 3.4 增量代码覆盖率报告 Java版

如果是计算MR整体的增量代码覆盖率，那么还需要合并多个 Commit 的覆盖率数据。假设有 Commit A、Commit B、Commit C 三个版本的覆盖率报告，Commit C 是最后一次提交，Commit C 有增量代码的文件是 c。下面介绍一下合并过程。

找到 Commit A 文件 c 中被执行的代码内容
在 Commit C 中寻找相同的代码内容
在 Commit C 的覆盖率报告中标注该行被执行
重复以上三个过程，其他 Commit 代码与 Commit C 的代码比对

合并后生成的覆盖率报告能够辅助 QA 分析，未覆盖的部分是因为测试用例遗漏，还是测试环境无法覆盖，又或者冗余代码等其他问题。

用户使用流程

我们做到了零成本接入，用户在测试联调环境加入应用时，打开「启动覆盖率检测环境」按钮即可。用户可以在工具的前端界面查看报告，也可以在 MR 中添加评论获取覆盖率数据报表。用户使用流程图（图2.1 ) 展示了使用覆盖率报告分析测试用例的流程。如果使用自动化脚本进行测试，单版本的的代码覆盖率报告可以帮助分析。如果是手工测试，由于代码持续更新，MR 整体的增量代码覆盖率报告能够帮助查找遗漏的测试用例。

图 4.1 用户使用流程图

图 4.2 前端请求覆盖率报告

图 4.3 MR 评论请求覆盖率报告

业务实践

在 Timon 工具出现之前，黑盒测试无从保证覆盖所有逻辑和异常情况；跟进自动化测试脚本的开发进度，一般是比较用例完成百分比；自动化测试用例的质量评估也大多靠测试经验。Timon 帮助测试人员快速找到遗漏测试场景，提高了工作效率，且推动测试人员更加关注代码本身。Timon 也为评估自动化测试用例提供了新的方法。除此以外，我们在实践过程中发现覆盖率工具也能够帮助测试人员发现其他问题，比如开发提交了非需求相关的代码，手工测试环境当中无法制造某些异常情况等。Timon 工具是知乎质量保障体系的一个模块，为精准测试舔砖加瓦。 QA 因为使用 Timon 工具改变了测试习惯。我们将持续寻找 Timon 覆盖率工具在产研体系中的最佳实践，同时与其他质量保障平台联动，发挥它的最大价值。

本文转载自知乎技术专栏。

原文链接：

https://zhuanlan.zhihu.com/p/102744098

创作场景

Timon 覆盖率工具在知乎测试实践中的应用