中通科技代码覆盖率应用实践（三）

原创 spencer 科技中通

阅读《中通科技代码覆盖率应用实践（一）/（二）》，可至文章最后点击【阅读原文】。

背景

为了适应多平台应用和复杂业务场景，移动端白盒测试是保障系统质量的方案趋势之一，中通科技测试开发团队也进行了移动端测试代码覆盖率相关的技术探索和实践。目前测试团队使用的是基于JaCoCo做二次开发的代码覆盖率工具，考虑现有测试工具体系，我们选择了中通宝盒Android 端APP作为测试代码覆盖率的实践应用。

现状

JaCoCo是解决Java应用代码覆盖率的成熟解决方案，对于同样生成字节码的Kotlin语言有很好的支持。中通宝盒Android APP使用gradle构建打包，主要开发语言是Java和Kotlin，并且gradle还提供了JaCoCo Plugin插件。于是我们的实践思路就有了：在gradle构建脚本中集成JaCoCo Plugin，在测试过程中生成覆盖率结果文件，结合目前的代码覆盖率后端服务生成代码覆盖率报告，绑定对应的测试用例，并在创建测试计划时推荐测试用例。

探索

怎么做？

首先是客户端集成JaCoCo插件，在build. gradle中引入JaCoCo Plugin，这部分按照官方文档做就可以，需要注意的是JaCoCo版本需要和gradle版本对应，服务端和客户端版本也应该一致。

目前测试开发团队的设计是客户端监听应用状态，每次切换到后台运行或者关闭应用时生成一次覆盖率文件，然后再由测试人员手动绑定当前结果文件和测试用例，提交到代码覆盖率后端服务去生成报告。部分流程和目前测试开发团队已有功能重合，因此只需要关注Android项目与Java项目的差别处理，和测试用例和代码颗粒度的绑定。

对于Java代码的部分，我们遵循已有的方案支持代码覆盖率。而Kotlin的部分，经过调研决定使用kastree库解析代码结构，kastree对于解析结果有比较明确的数据结构，虽然项目已经不再维护，但已经满足了现有需求。

为了将测试用例和覆盖率结果绑定，需要分析建立在代码差异上的基础数据。根据jdt和kastree的解析结果，我们决定将测试用例绑定的代码颗粒度控制在方法级层面，当一个方法发生变更（增、删、改）时，都会推荐出与之绑定的测试用例。

遇到了哪些问题？

Kotlin代码覆盖率结果无法获取

因为是做Android APP的代码覆盖率探索实践，测试开发团队没有Kotlin相关语言经验，一开始也踩了不少坑。对于Java与Kotlin混合开发的项目，需要在build.gradle中指定源码路径，还有注意版本差异导致的代码冲突或者解析问题。一开始，我们沿用Java项目的思路，拉取源码，获得打包编译后的jar包，加上覆盖率结果exec文件，生成报告。但是实际使用后发现，覆盖率会一直为0。之后我们决定改变方式，实时去编译源码，再直接调用gradle命令生成html报告，同时为了优化执行时间，暂存编译后build文件夹。这样，除了第一次运行会耗时外，可以保证覆盖率报告生成的稳定和效率。

无法准确推荐出相关测试用例

成功获得代码覆盖率报告后，我们解析了每次覆盖率结果数据，以source file + package + class + method的组合确定唯一方法，与测试用例建立绑定关系。在每次创建新版本测试计划时，我们的预想是根据当前测试版本与线上版本做code diff，根据代码的差异结果反向关联出测试用例，但是实际却没有相关测试用例被推荐。经过调试分析，最终发现问题出在使用jdt分析出的代码结构和kastree的解析结果不一致导致的，因此我们对kastree的解析结果做了改造，对齐jdt的结果。