背景
移动互联网浪潮中，To C的移动应用迭代速度非常之快，应用的玩法也是层出不穷，那么相应的对于应用质量的保障也提出了更高的要求：响应迅速、目标明确、手段有效等。质量保障团队为了更好地达成上述要求，需要制定一系列的流程、系统或者工具来辅助测试的展开，但无论测试侧要建立的是什么，都有一个明确的原则贯穿始终，即有效性（由于流程、系统或工具等都用于测试，也称为测试有效性）。
那么如何来衡量测试有效性变得尤为重要，其评估体系的建设则是重中之重。本着从实践中来到实践中去的原则，建设了优酷客户端测试有效性评估能力去辅助测试人员调整测试方向，改变测试策略等。
方案选型
不同团队会定义自己的规则去衡量测试有效性，这些规则几乎包罗万象，例如：Bug数量和趋势、测试用例的评审、测试策略的评审亦或代码覆盖率的数据等等。
评价测试的有效性是无法脱离开发的实现及项目的上下文的，测试从来就不是独立存在的，测试和开发密不可分。
结合优酷质量保障体系的现状，我们优先选择最直接的，也最能从数据化的角度评估测试有效性的规则入手：即代码测试覆盖率。
代码测试覆盖率工具（Android端）
- JaCoCo - 通过代码注入的方式来实现获取覆盖率的功能
- 优酷内部覆盖率采集工具 - 优酷自研的类覆盖统计工具
【工具对比】
| 工具名称 | 代码侵入 | 性能损耗 | 可否用于灰度发布 | 统计范围 |
| JaCoCo | 需要侵入并针对每个模块进行打包 | 性能损耗较大，可以会引入非功能性bug | 不可以用于灰度发布 | 模块、类、方法和行级别 |
| 优酷内部覆盖率采集工具 | 无代码侵入且无须进行单模块重新打包 | 几乎无性能损耗，不会引入额外bug | 可用于灰度发布，用户无感知 | 模块和类级别 |
通过两个版本的线下测试覆盖率数据的收集，优酷客户端测试在类这个纬度上的覆盖率数据当前是不尽如人意的，当前只有40%左右。
结合工具对比结论和客户端测试现状，优酷内部覆盖率采集工具作为当前的首选方案进行实施。
从宏观到微观地进行测试有效性分析。
整体架构及流程
参考上图，具体获取类是否被加载的流程概述如下：
- 通过Native层的ClassTable获取所有ClassLoader的ClassTable对象
- 通过ClassTable对象获取类名列表
- 通过libart.so中ClassTable的Lookup方法判断类是被加载
整体方案的设计参考下图：
示例结果
优酷客户端测试平台
- 综述结果
- TOP模块类覆盖率对比结果
- 模块细节对比数据
技术实现
1. 数据下载与分析部分使用Python3开发完成
2. 30万zip * (10万-12万)个类，分析统计时间在1小时左右完成。
分析机器为8*CPU，16GRAM Ubuntu20.04LTS
3. 主要包四个部分
- 数据反混淆逻辑
- 类覆盖统计算法相关
- 元数据下载，基于pyspark对模块与类调用次数进行分析统计
> 下载逻辑基于multiprocessing与asyncio实现
> 进程间(下载&分析)通信基于队列实现
- 基于测试平台的任务创建与定时机制进行任务触发
结果收益
- 建立了Android端主客模块/类纬度的测试有效性评估手段
- 由于使用了线上代码热度分析机制，基于其性能无损性，可以直接用于日常自动化测试及灰度测试
- 有效地收集了优酷主客多个版本的测试有效性数据
- 有效地针对业务模块进行测试覆盖优化
后续计划
- 推动测试有效性分析能力落地优酷主客TOP模块，提升单模块覆盖率不低于10%。
- 全链路自动化，基于优酷客户端测试平台进行的自动化测试专项任务，都可以进行测试覆盖率统计。
- 结合优酷主客技术图谱进行覆盖率可视化输出，更加直观地展示测试链路覆盖情况。
- And more...
