背景介绍
- 每次上线一大堆代码改动，到底影响了哪些功能，比较依赖经验
- 测试完了之后，不清楚把这次改动涉及到的功能点是否都测到了
- 在敏捷迭代的背景下，发布频繁，测试时间不足，我们必须要了解核心流量在哪里，优先保障核心流量经过的功能高可用
- 服务中的废弃代码，留着又不知道做什么的，删的话又没把握
- 微服务架构下，如何评估对业务方的影响
方案设计
对于上述测试痛点，要解决的核心问题就是测试效率和测试质量，我们从以下几个方面来逐个击破：
- 首先要解决的问题就是，科学地评估代码变更影响到的功能点；最好能够做到智能推荐用例
- 再就是要获取到测试的增量覆盖，清楚的知道哪些变更的代码还未覆盖到
测试功能点评估
这里涉及到几个关键能力：
1. 从代码变更获取方法集合
- 通过 Jgit 来获取代码差异
- 使用 classParser，通过解析源 class 文件，获取常量池
2. 通过变更方法获取影响接口
- BCEL：通过深入 JVM 的汇编来创建、分析、操纵 class 文件
- 常量池：包含 class 文件中所有的东西，通过对常量池的分析可以得出函数间的调用关系
覆盖结果分析
在增量覆盖率的基础上，通过对未覆盖方法的分析，可以得知影响到了哪些接口，结合下面的接口分析能力来进行测试
接口分析
有了之前的能力，我们可以知道通过哪些接口可以去测试这次改动的代码；然而不同的接口重要程度是不同的，在时间有限的情况下，我们需要清楚哪些接口是一定要保证，这就需要获取到接口的以下信息：
- 接口的优先级，帮助我们明确该接口是否在核心功能路径上
- 接口是否有自动化覆盖，包括接口自动化和流量回放等自动化手段；以及自动化 case 覆盖到的代码方法树
- 接口的前端调用入口，方便快速找到测试入口
- 接口影响的业务方，用以判断是否需要通知业务方进行回归
接口优先级分析
- 假设选取 1 个月作为时间窗口，拉取系统 API 1 个月的调用情况。时间窗口选取过长，可能会有历史高调用量数据影响结果，而这些接口可能已经下线；选取过短，可能有运营活动或其他突发状况造成的次优先级 API 调用量较高，不具有统计分析的意义。
- 对拉取的离散数据进行曲线拟合，采用简单的最小二乘法
- 对拟合后的数据求取拐点。假设：相同 priority 的数据有相同的分布
4.采用拐点切分数据，获得 priority 区间
接口自动化覆盖情况
接口自动化覆盖的情况可以从持续集成的结果获取，需要自动化平台提供相关接口。
自动化用例覆盖代码函数
通过自动化框架调度与精准测试和覆盖率平台对接可以获取每个自动化 case 覆盖到的方法树。
接口入口以及影响业务方接口
从监控系统获取服务间调用关系的数据进行分析，获取影响的依赖方接口以及调用入口。
智能用例推荐
应用场景
具备以上的能力后，回过头来看精准测试解决了哪些问题：
- 明确代码影响范围，避免全量测试
- 测试用例平台可以通过代码变更智能推荐用例，方便开发自测；结合增量覆盖率，可以提高测试准入门槛
- 单 case 测试时能够收集到影响代码中的方法树，可以帮助新人快速熟悉业务
- 集成测试环境的增量覆盖率可以评估测试效果，做上线卡点
- 根据单 case 覆盖率数据可以精简流量，提高回归效率
- 线上的覆盖率数据可以标记冗余代码
- 中台类服务可以明确被影响的依赖方，提供业务方回归范围
想了解更多关于酷家乐技术质量的文章，欢迎关注我们的公众号
