CN112181858B - Java软件项目依赖冲突语义一致性的自动化检测方法 - Google Patents

Abstract

本发明公开一种Java软件项目依赖冲突语义一致性的自动化检测方法，该方法包括：获取Maven项目POM文件和项目代码；从项目完全依赖树中分析出依赖冲突；对于所有的依赖冲突，检测是否存在真实风险方法的情况；对检测出的存在真实风险方法的项目构建相应的对象池和API池；对于检测出的真实风险方法，通过自动化测试用例生成工具结合构建的对象池和API池生成测试用例并进行验证；将分析结果生成缺陷结果报告。本发明通过静态分析的方法检测依赖冲突中可能存在不一致语义的行为，再通过动态测试进一步验证风险方法是否真的存在问题，使开发者可以在全自动的情况下，检测软件项目中存在的依赖冲突问题。

Description

Java软件项目依赖冲突语义一致性的自动化检测方法

技术领域

本发明涉及软件可靠性检测技术领域，尤其涉及一种Java软件项目依赖冲突语义一致性的自动化检测方法。

背景技术

在当代的软件开发过程中，第三方库的重用给开发人员带来了极大的便利，使得一些软件开发人员更加专注于自己业务功能的开发，而一些基础功能则越来越依赖于第三方库，这也使得第三方库成为了Java编程中不可缺失的一部分。然而在Maven的中央仓库中，开发者不能删除或者修改已经上传到中央仓库中的构件，所以只能发布新版本的方式进行迭代更新，这也间接导致了Maven中央仓库越来越庞大，这其中很多是因为第三方库的更新而不断迭代开发的构件，而且现在Maven仓库还在继续扩大。软件通过致力于修复错误，引入新的功能，重构现有代码而发展，但是这种发展也可能带来新的问题，例如API的变更导致的兼容性问题。在Maven中央仓库中存在大量构件无法向后兼容，同时开发者并未给出相关标注且更改语义版本。虽然第三方库的重用给开发者带来了极大的便利，而且为了充分利用第三方库，开发者应该尽量保持同步更新软件系统的依赖库，以避免一些已经暴露的漏洞和错误。但是由于一些软件系统的依赖关系过于庞大，并且一些开发者并不清楚更新一下第三方库是否会带来未知的风险。并不是所有的开发者都能完全了解自己软件系统当中的所有依赖关系，包括第三方依赖，因此就会造成很多依赖冲突问题被不断传递。

Maven的依赖管理能够自动的帮助开发者管理依赖关系。当软件系统越来越大时，就会出现多个版本的同一个第三方库同时存在的情况，然而JVM只能允许一个库存在于运行环境中，此时Maven通过仲裁策略帮助开发者自动解决传递依赖中存在的冲突问题。然而，这带来了一种非常严重的风险，因为经过Maven的仲裁机制选择后，最后留在运行环境中的第三方库可能存在严重的漏洞，或者API的变更导致软件系统出现了不一致的缺陷。研究表明，在中央仓库的发行版本中，大约有三分之一的构件在引入重大不兼容性更新的同时，并未标注相关信息，这让开发者在选择版本时无法识别风险存在。

发明内容

针对上述现有技术的不足，本申请提供一种Java软件项目依赖冲突语义一致性的自动化检测方法。

为解决上述技术问题，本发明所采取的技术方案是：一种Java软件项目依赖冲突语义一致性的自动化检测方法，包括如下步骤：

步骤1：获取Maven项目POM文件和项目代码；

步骤2：获取项目完全依赖树，从中分析出依赖冲突并做筛选和过滤，过程如下：

步骤2.1：通过项目源代码中的pom.xml文件获取项目的完全依赖树；

步骤2.2：根据项目的完全依赖树，分析出所有由于Maven仲裁机制所屏蔽掉的第三方依赖，作为初始依赖冲突问题；

步骤2.3：对于检测出来的依赖冲突问题，筛选掉所有不参与项目正常运行的依赖包，以及自定义的过滤项。

步骤3：对于所有的依赖冲突，检测是否存在真实风险方法的情况，过程如下：

步骤3.1：在步骤2中可以得到项目的依赖冲突，检测其中是否包含完全限定名相同的方法；

步骤3.2：对于在两个冲突包中的完全限定名相同的方法，通过反编译技术，把二进制文件反编译成源文件；

步骤3.3：根据反编译出来的源文件，通过抽象语法树的对比，对比两个方法的方法体是否存在较为明显的差异，如果没有明显差异，则判断不是风险方法，否则判断属于风险方法；

步骤3.4：对于所有的风险方法，通过静态分析技术，构建当前项目的完全调用路径图，通过分析完全调用路径图，可以判断出当前风险方法是否被当前项目调用，如果没有被调用，则过滤；如果被调用则属于真实的风险方法。

所述通过静态分析技术，构建当前项目的完全调用路径图的过程如下：

步骤3.4.1：通过静态分析技术，解析出当前项目中的所有依赖包内部方法之间的调用关系，并将调用关系保存；

步骤3.4.2：对于步骤3中获取的存在真实风险方法视为目标风险方法，把目标风险方法视为调用图的终点，把当前项目的入口方法视为调用图的起点；

步骤3.4.3：取出所有保存的调用关系，通过广度优先搜索的方式，把所有方法的调用关系组合成完整的调用路径图。

步骤4：对步骤3检测出的存在真实风险方法的项目构建相应的对象池和API池，过程如下：

步骤4.1：对于步骤3中检测出存在真实风险方法的项目，获取项目源代码中所有的对象构造方式和方法的声明方式；

步骤4.2：对当前项目所有代码文件进行扫描，获取当前项目所有的类，然后在项目中搜索所有在本项目中类被实例化的位置，然后在实例化的位置处，搜索获取实例一个类所需的所有构造参数，最终生成<Object-Parameter>对象参数的对应关系，形成项目的对象池，然后对所有API进行API生成池的构造，保存方式依旧为API加参数的方式；

步骤4.3：把初始化好的对象池和API池补充给自动化测试用例生成工具。

步骤5：对于检测出的真实风险方法，通过自动化测试用例生成工具结合步骤4构建的对象池和API池生成测试用例并进行验证，过程如下：

步骤5.1：对于检测出的真实风险方法，通过自动化测试用例生成工具结合步骤4给出的对象池和API池，对目标风险方法进行测试用例生成；

步骤5.2：将生成出的测试用例分别在冲突的两个依赖包的环境下运行，如果运行结果不一致，则说明当前风险方法是一个真实的缺陷。

步骤6：将分析结果生成相应的缺陷结果报告，报告给开发者，并及时修正和预测依赖冲突问题。

采用上述技术方案所产生的有益效果在于：

1、本发明通过对依赖冲突的依赖包进行分析，获取所有可能对软件系统项目造成风险的方法，然后通过自动化测试用例生成对该方法进行验证，最终达到可以检测软件系统项目中由于依赖冲突问题所导致的语义行为不一致的缺陷并形成相关文档，可以使开发者更快的确认项目中出现的问题并解决。

2、本发明通过静态分析的技术检测依赖冲突中可能存在不一致语义行为的方法，然后通过动态测试技术进一步验证风险方法是否真的存问题，通过静态分析技术，能够快速高效的找出所有可能存在语义行为不一致的方法，结合动态测试技术，可以很好的弥补由于静态分析技术所导致的一些误差，使得结果更准确。

3、本发明对二进制格式的java的依赖包进行分析，将其中的方法名和调用关系解析出来，然后通过组合的方式去生成整个项目的调用路径图，结合整个项目的完全调用路径图，我们可以清楚的判断出哪些风险方法会被项目本身所调用到，只有被调用到的风险方法才有可能在项目中引入缺陷，通过完全调用路径图的分析，可以最大可能的降低开发者的修复成本，使得开发者更快的进行修复。

4、本发明可以帮助开发人员更方便的检测在Maven项目中的依赖冲突问题，确定这些依赖冲突问题是否会引发真正的系统缺陷。本发明可以在发现问题的同时给出原因和解决方案。同时开发者还可以通过本发明更好的了解在自己的项目中升级或降级第三方依赖包会不会引发新的运行时刻异常，这种问题在开发过程中是非常难以被察觉的，通过本发明，开发者可以最大可能的发现项目中存在的语义行为不一致的问题。

附图说明

图1为本发明实施例中Java软件项目依赖冲突语义一致性的自动化检测方法的流程图；

图2为本发明实施例中检测出真实风险方法的流程图；

图3为本发明实施例中对检测出的真实风险方法进行验证和生成缺陷报告的流程图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

本实施例通过研究Java环境下第三方库多个版本之间的冲突所造成的语义行为不一致问题，使得开发者在面对依赖冲突问题时，可以尽量减少开发者的工作，使得开发者可以在全自动的情况下，检测软件项目中存在的依赖冲突问题，并且可以更加安全的对第三方依赖库进行升级和降级操作，具体流程如图1所示，过程如下：

步骤1：获取Maven项目POM文件和项目代码；

在命令行下，进入当前项目pom.xml所在的根目录，通过Maven命令的方式运行本工具，通过相关参数设置输入pom.xml文件。

步骤2：获取项目完全依赖树，从中分析出依赖冲突并做筛选和过滤，过程如下：

步骤2.1：通过项目源代码中的pom.xml文件获取项目的完全依赖树；

通过输入的pom.xml文件和Maven构建当前项目的完全依赖树，并通过依赖的加载策略确定依赖包的加载顺序。

步骤2.2：根据项目的完全依赖树，可以获取项目中所有的依赖，根据Maven的加载原则：先声明优先和最短路径优先，确定被加载的依赖包和被屏蔽的依赖包，将分析结果保存，将分析出的所有由于Maven仲裁机制所屏蔽掉的第三方依赖，作为初始依赖冲突问题；

步骤2.3：对于检测出来的依赖冲突问题，筛选掉所有不参与项目正常运行的依赖包，以及自定义的过滤项。

步骤3：对于所有的依赖冲突，检测是否存在真实风险方法的情况，过程如下：

步骤3.1：在步骤2中可以得到项目的依赖冲突，检测其中是否包含完全限定名相同的方法，并将结果加入到待测方法集中；

然后分析所有存在父类动态绑定的情况，在这种情况下，如果冲突的包中不包含相关的方法，正常JVM会报出异常，但是由于此时存在动态绑定，实际调用的是父类的相关方法，导致不会报异常。这种情况下，实际调用可能出现语义行为不一致。将所有这些方法也加入待测方法集中。

分析项目中存在的类级别冲突情况，根据JVM的加载原则，完全限定名相同的类会通过先声明优先的原则加载进JVM，所以通过分析项目中所有的类文件，将所有完全限定名相同的类文件中的相同方法加入待测方法集中。

步骤3.2：对于在两个冲突包中的完全限定名相同的方法，通过反编译技术，把二进制文件反编译成源文件；

步骤3.3：根据反编译出来的源文件，通过抽象语法树的对比，对比两个方法的方法体是否存在较为明显的差异，如果没有明显差异，则判断不是风险方法，否则判断属于风险方法；

步骤3.4：对于所有的风险方法，通过静态分析技术，构建当前项目的完全调用路径图，通过分析完全调用路径图，可以判断出当前风险方法是否被当前项目调用，如果没有被调用，则过滤；如果被调用则属于真实的风险方法。

所述通过静态分析技术，构建当前项目的完全调用路径图的过程如下：

步骤3.4.1：通过静态分析技术，解析出当前项目中的所有依赖包内部方法之间的调用关系，并将调用关系保存；

步骤3.4.2：对于步骤3中获取的存在真实风险方法视为目标风险方法，把目标风险方法视为调用图的终点，把当前项目的入口方法视为调用图的起点；

步骤3.4.3：取出所有保存的调用关系，通过广度优先搜索的方式，把所有方法的调用关系组合成完整的调用路径图。

调用路径分析，用于检查是否存在一条路径可以从项目入口一直调用到该方法。

上述步骤为检测出真实风险方法的过程，其流程如图2所示。

步骤4：对步骤3检测出的存在真实风险方法的项目构建相应的对象池和API池，过程如下：

步骤4.1：对于步骤3中检测出存在真实风险方法的项目，获取项目源代码中所有的对象构造方式和方法的声明方式；

步骤4.2：对当前项目所有代码文件进行扫描，获取当前项目所有的类，然后在项目中搜索所有在本项目中类被实例化的位置，然后在实例化的位置处，搜索获取实例一个类所需的所有构造参数，最终生成<Object-Parameter>对象参数的对应关系，形成项目的对象池；

步骤4.3：构造API池，通过静态分析获取当前项目所有的方法名和参数列表以及该方法在项目中出现的位置，然后在该方法被调用的位置，搜索获取该方法调用所需的所有参数，生成<API-Parameter>API加参数的对应关系，保存并生成API池；

步骤4.4：把初始化好的对象池和API池补充给自动化测试用例生成工具，如果调用的实例或API存在于构造的对象池和API池中，则直接取出。

步骤5：对于检测出的真实风险方法，通过自动化测试用例生成工具结合步骤4构建的对象池和API池生成测试用例并进行验证，过程如下：

步骤5.1：对于检测出的真实风险方法，通过自动化测试用例生成工具结合步骤4给出的对象池和API池，对目标风险方法进行测试用例生成；

步骤5.2：将生成出的测试用例分别在冲突的两个依赖包的环境下运行，如果运行结果不一致，则说明当前风险方法是一个真实的缺陷。

步骤6：将分析结果生成相应的缺陷结果报告，报告给开发者，并及时修正和预测依赖冲突问题。

上述步骤为对检测出的真实风险方法进行验证和生成缺陷报告的过程，其流程如图3所示。

Claims (4)

1.一种Java软件项目依赖冲突语义一致性的自动化检测方法，其特征在于，包括如下步骤：

步骤1：获取Maven项目POM文件和项目代码；

步骤2：获取项目完全依赖树，从中分析出依赖冲突并做筛选和过滤，过程如下；

步骤2.1：通过项目源代码中的pom.xml文件获取项目的完全依赖树；

步骤2.2：根据项目的完全依赖树，分析出所有由于Maven仲裁机制所屏蔽掉的第三方依赖，作为初始依赖冲突问题；

步骤2.3：对于检测出来的依赖冲突问题，筛选掉所有不参与项目正常运行的依赖包，以及自定义的过滤项；

步骤3：对于所有的依赖冲突，检测是否存在真实风险方法的情况，过程如下；

步骤3.1：在步骤2中可以得到项目的依赖冲突，检测其中是否包含完全限定名相同的方法；

步骤3.2：对于在两个冲突包中的完全限定名相同的方法，通过反编译技术，把二进制文件反编译成源文件；

步骤3.3：根据反编译出来的源文件，通过抽象语法树的对比，对比两个方法的方法体是否存在较为明显的差异，如果没有明显差异，则判断不是风险方法，否则判断属于风险方法；

步骤3.4：对于所有的风险方法，通过静态分析技术，构建当前项目的完全调用路径图，通过分析完全调用路径图，可以判断出当前风险方法是否被当前项目调用，如果没有被调用，则过滤；如果被调用则属于真实的风险方法；步骤4：对步骤3检测出的存在真实风险方法的项目构建相应的对象池和API池；

步骤5：对于检测出的真实风险方法，通过自动化测试用例生成工具结合步骤4构建的对象池和API池生成测试用例并进行验证；

步骤6：将分析结果生成相应的缺陷结果报告，报告给开发者，并及时修正和预测依赖冲突问题。

2.根据权利要求1所述的Java软件项目依赖冲突语义一致性的自动化检测方法，其特征在于，所述通过静态分析技术，构建当前项目的完全调用路径图的过程如下：

步骤3.4.1：通过静态分析技术，解析出当前项目中的所有依赖包内部方法之间的调用关系，并将调用关系保存；

步骤3.4.2：对于步骤3中获取的存在真实风险方法视为目标风险方法，把目标风险方法视为调用图的终点，把当前项目的入口方法视为调用图的起点；

步骤3.4.3：取出所有保存的调用关系，通过广度优先搜索的方式，把所有方法的调用关系组合成完整的调用路径图。

3.根据权利要求1所述的Java软件项目依赖冲突语义一致性的自动化检测方法，其特征在于，所述步骤4的过程如下：

步骤4.1：对于步骤3中检测出存在真实风险方法的项目，获取项目源代码中所有的对象构造方式和方法的声明方式；

步骤4.2：对当前项目所有代码文件进行扫描，获取当前项目所有的类，然后在项目中搜索所有在本项目中类被实例化的位置，然后在实例化的位置处，搜索获取实例一个类所需的所有构造参数，最终生成<Object-Parameter>对象参数的对应关系，形成项目的对象池；然后对所有API进行API生成池的构造，保存方式依旧为API加参数的方式；

步骤4.3：把初始化好的对象池和API池补充给自动化测试用例生成工具。

4.根据权利要求1所述的Java软件项目依赖冲突语义一致性的自动化检测方法，其特征在于，所述步骤5的过程如下：

步骤5.1：对于检测出的真实风险方法，通过自动化测试用例生成工具结合步骤4给出的对象池和API池，对目标风险方法进行测试用例生成；

步骤5.2：将生成出的测试用例分别在冲突的两个依赖包的环境下运行，如果运行结果不一致，则说明当前风险方法是一个真实的缺陷。

Images