基于知识图谱的调用链分析精准化测试平台

传统软件测试技术主要基于测试人员对业务的理解，但由于经验的局限性、被测系统的复杂性以及与真实业务数据的差距，肯定存在测试不充分的情况，所以， 虽然整个测试流程很规范，但最终软件质量还是不尽如人意 。而随着分布式、微服务架构、大数据技术的出现，软件越来越复杂，迭代越来越快，测试的挑战性越来越大。 测试人员急切的需要一套更加精确、高效的测试技术和方法 。精准化测试技术就在这种背景下应运而生并快速发展。

在对精准测试下定义之前我们先看几个精准测试需要解决的问题：

• 如何刻画和度量有限测试集合的充分性

• 如何挑选有限测试集合并充分执行

• 如何让上述过程更加自动化、更加精准

那我们可以得到精准测试需要包含的几个特性：

• 全不全：通过代码覆盖率度量测试充分性

• 准不准：通过精准推荐代替人工进行变更影响范围评估指导用例回归

• 快不快：精准推荐自动化&用例执行失败快速定位等

1. 静态 扫描+推荐 测试范围 ，流程如下：

• 原始代码静态扫描，获取基础函数调用链

• 原数据解析，扫描结果存储至Neo4j

• 代码diff获取版本差异，图谱查询影响接口范围

• 测试范围推荐

2. 动态 追踪+推荐 测试用例 ，流程如下：

• 业务代码插桩

• 插桩后执行业务/自动化测试用例

• 采集“用例-函数调用链”权重

• 代码diff获取版本差异

• 测试用例推荐

在获取项目调用链原数据后，再深度遍历每一条调用链路采集每个 包、文件、函数 的对应关系，以及 路径、所处位置、出参入参、注释、代码行 等信息，写入Neo4j。

下面举例几种不同的权重计算方式：

假如有一条测试用例，执行时经过了 Api_1 和 Api_2 两个接口

实际使用中，我们会采取不同的特征来训练GCN，用于计算不同场景的结果

在这里我们举一个简单的例子，用于计算case的相似性：

1. 我们通过采集不同case对函数的调用层级，构成一个 C × N 的稀疏矩阵 （ C： 测试用例个数， N： 函数节点数）

2. 将调用层级数 取反 ，然后 归一化 ，得到训练模型用的矩阵

如果是业务用例则自动创建测试计划，并关联测试用例。

目前平台在MR、冒烟、提测、回归、上线等不同阶段，采取了8种不同的质量保障措施：

• 迭代时间由 3周 缩短至 2周

• 版本平均需执行自动化用例数减少 80%
• 回归测试阶段平均需执行用例数减少 60%
• 覆盖率需统计代码减少 90%