CN115934157B - 软件依赖范围自动推断方法、装置、计算机设备和存储器 - Google Patents
软件依赖范围自动推断方法、装置、计算机设备和存储器 Download PDFInfo
- Publication number
- CN115934157B CN115934157B CN202211694947.8A CN202211694947A CN115934157B CN 115934157 B CN115934157 B CN 115934157B CN 202211694947 A CN202211694947 A CN 202211694947A CN 115934157 B CN115934157 B CN 115934157B
- Authority
- CN
- China
- Prior art keywords
- change
- incompatible
- backward
- software
- changes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 67
- 230000008859 change Effects 0.000 claims abstract description 338
- 238000001514 detection method Methods 0.000 claims abstract description 113
- 230000007547 defect Effects 0.000 claims abstract description 42
- 230000001419 dependent effect Effects 0.000 claims abstract description 28
- 238000004458 analytical method Methods 0.000 claims abstract description 25
- 238000007781 pre-processing Methods 0.000 claims abstract description 21
- 230000006870 function Effects 0.000 claims description 18
- 238000004590 computer program Methods 0.000 claims description 14
- 238000012217 deletion Methods 0.000 claims 2
- 230000037430 deletion Effects 0.000 claims 2
- 230000005251 gamma ray Effects 0.000 description 27
- 239000008186 active pharmaceutical agent Substances 0.000 description 14
- 230000003068 static effect Effects 0.000 description 7
- 230000018109 developmental process Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 239000011800 void material Substances 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000011895 specific detection Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 239000010437 gem Substances 0.000 description 1
- 229910001751 gemstone Inorganic materials 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
Landscapes
- Stored Programmes (AREA)
Abstract
本申请涉及软件依赖缺陷检测技术领域的一种软件依赖范围自动推断方法、装置、计算机设备和存储器。该方法包括：获取第三方库的若干个后向不兼容改变，对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，得到后向不兼容库版本，并报告依赖缺陷；根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到所有不兼容库版本；根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。采用本方法检测不兼容库版本更加准确高效，误报率更低，从而推断依赖范围更精确，可以帮助终端用户避免兼容性错误的发生。
Description
技术领域
本申请涉及软件依赖缺陷检测技术领域，特别是涉及一种软件依赖范围自动推断方法、装置、计算机设备和存储器。
背景技术
随着社会的进步与发展，计算机软件技术应用越来与广泛，软件已成为信息化社会的基础设施，同时软件的规模也在不断增加。传统软件系统开发方式虽然可以满足不同的功能需求，但不可避免的需要软件开发人员对相同的软件功能进行重复开发，效率低下，同时代码冗余，即软件工程领域常说的“重复造轮子”问题。因此为了避免重复开发，软件开发过程中依赖于第三方开源库和组件是一种提高开发效率的普遍做法。然而第三方库在演化的过程中可能会发生不兼容的改变(例如增加或者删除接口)，进而导致软件依赖于第三方库时因兼容性而产生运行时错误。
软件兼容性错误通常涉及第三方库开发人员、软件开发人员、终端用户三方软件参与者。当库发生不兼容改变时，通常有三种方法可以避免软件发生兼容性错误：1)第三方库开发人员在开发最新的库版本中撤销不兼容的改变；2)软件开发人员升级软件以适应第三方库的变化；3)终端用户可以避免使用不兼容的第三方库版本。目前，有很多研究工作关注检测第三方库的变化，并报告给库开发者建议不进行不兼容的改变，以Darius Foo等人在FSE2018发表的“Efficient Static Checking of Library Updates(库更新的高效静态检查)”为代表，能够自动有效地检查库升级是否引入了应用程序编程接口(ApplicationProgram Interface，简称API)不兼容。还有一些工作可以帮助软件开发人员更新软件，以实现软件和库共同演化，主要包括两类。第一类工作以Li等人在ISSTA2018发表的“CiD:Automating the Detection of API-Related Compatibility Issues in Android Apps(CiD：自动检测Android应用程序中与API相关的兼容性问题)”为代表，主要关注检测软件对不兼容API的使用，第二类工作以Zhenchang Xing等人在TSE2007发表的“API-EvolutionSupport with Diff-CatchUp(使用Diff-CatchUp支持API演化)”为代表，主要关注如何帮助软件适应库的变化，以便最新版本的软件能够更好的工作。
但上述两种做法均作为一种事后的考虑，帮助最新的软件版本和最新的库版本能够良好的运行，然而此时终端用户均已经遭受软件兼容性错误，需要等待软件或第三方库发布新的版本。相比之下，第三种方法更为高效和可靠：终端用户从一开始就可以避免使用不兼容的库版本，从而避免软件出现兼容性错误。已有研究工作无法自动帮助用户选择兼容的库版本。Darius Foo等人在FSE2018发表的“Efficient static checking of libraryupdates(库更新的高效静态检查)”和Steven Raemaekers等人发表在SCAM2014的“Semantic Versioning versus Breaking Changes:A Study of the Maven Repository(语义版本控制与重大更改：Maven存储库研究)”通过调研发现，平均26％到1/3的库版本违反语义版本控制，它们在非主要版本更新的情况下破坏了向后兼容性。对于库或API的用户来说，向后兼容是一个理想的特性。如果没有兼容性，库用户在升级其依赖项时将面临更大的风险和成本。库的演化历史中，打破前向兼容或后向兼容的改变均可能导致软件兼容性错误，但后向不兼容改变导致的软件兼容性错误问题尤为严重。
随着软件开发人员对第三方库的依赖性增强，人工维护软件依赖费时费力且容易出错。因此一种常用的方法是使用依赖管理工具去管理软件项目的依赖。操作系统的依赖管理工具，比如CentOS的yum，Debian的apt，Fedora的dnf，Arch的Packman，macOS的Homebrew；编程语言的依赖管理工具，比如Java的Maven，Net的nuget，Nodeis的npm，Golang的goget，Python的pip，Ruby的Gem。这些依赖管理平台的解决思路都是将依赖放到共同的仓库，开发人员人工指定需要的库和相应的版本，然后管理工具通过依赖描述文件去中央仓库获取相应的库包。在使用第三方库时，时常会面临版本更新的权衡问题：是为了保持软件项目稳定，将第三方库版本进行限定(使用固定版本，软件不会出现任何不兼容问题，可靠但损失了灵活性，如库在新版本中修复了一个重大缺陷但软件无法自动使用新库版本)；还是不断迭代更新第三方库的版本，以使用新特性(自动获取满足版本范围的新库版本，但新库版本可能打破了后向兼容性进而引发软件兼容性错误，提升了灵活性但是不可靠)。软件开发人员更新或者不更新第三方库版本的原因是不尽相同的。
综上所述，如何检测和修复上述依赖管理系统中的依赖缺陷是本领域技术人员正在探讨的热点问题。
发明内容
基于此，有必要针对上述技术问题，提供一种软件依赖范围自动推断方法、装置、计算机设备和存储器。该方法能自动检测软件和库的每一个版本是否兼容来帮助用户选择正确的版本从而预防软件兼容性错误，从而帮助开发人员在保证软件灵活性的同时提高可靠性。
一种软件依赖范围自动推断方法，所述方法包括：
获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合。
对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理。
根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；
根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本。
根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。
一种软件依赖范围自动推断装置，所述装置包括：
后向不兼容改变获取模块，用于获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合。
后向不兼容版本检测模块，用于对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；
不兼容库版本确定模块，用于根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本。
软件的正确依赖范围确定模块，用于根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。
在其中一个实施例中，后向不兼容改变获取模块，还用于以第三方库的所有版本作为输入，采用ABI合规性检测器收集后向不兼容改变集合，所述后向不兼容改变集合为：BICS(vpre,vnext)；第三方库的所有版本是源码或二进制文件；当第三方库包括N个版本时，收集到的所有后向不兼容改变集合为： 将后向不兼容改变集合中每个后向不兼容改变实例用三元组表示，得到每个库的后向不兼容改变三元组集合；所述后向不兼容改变实例bics的三元组为：<库名称，改变前后版本，改变内容>；每个库的后向不兼容改变三元组集合的三元组为{<库名称，改变前后版本1，改变内容1>，<库名称，改变前后版本2，改变内容2>，……<库名称，改变前后版本M，改变内容M>}，其中M为每个库的后向不兼容改变的数量，M为大于0的整数。
一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一所述方法的步骤。
一种计算机可读存储器，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述方法的步骤。
上述软件依赖范围自动推断方法、装置、计算机设备和存储器。该方法包括：获取第三方库的若干个后向不兼容改变，对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本；根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。基于源码和二进制分析，检测不兼容库版本更加准确高效，误报率更低，从而推断依赖范围更精确，可以帮助终端用户从一开始就避免使用不兼容的库版本，从而避免兼容性错误的发生。
附图说明
图1为一个实施例中软件依赖范围自动推断方法的流程示意图；
图2为另一个实施例中软件依赖范围自动推断方法的流程示意图；
图3为一个实施例中软件依赖范围自动推断装置的结构框图；
图4为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本发明主要关注破坏后向兼容性的源码和二进制级的库依赖缺陷检测。后向兼容性包括：1)向后二进制兼容性(即应用程序二进制接口(Application Binary Interface，简称ABI)兼容性)允许使用旧版本库编译的旧程序无需重新编译即可使用新版本运行，这使用户可以轻松升级到软件库的新版本；2)向后源代码兼容性(即API兼容性)允许旧程序使用较新版本的库成功重新编译。
在一个实施例中，如图1所示，提供了一种软件依赖范围自动推断方法，该方法包括以下步骤：
步骤100：获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合。
具体的，以每个第三方库comp为的所有版本为输入，收集其演化历史中的两两相邻版本的打破后向兼容性的不兼容改变集合BICS。第三方库的每个版本可以是源码形式或者带有调试符号的二进制形式。
二进制不兼容可能会导致使用旧版本库构建的应用程序在新版本上运行时崩溃或行为不正确。源不兼容可能会导致使用新库版本重新编译错误。
本方法只关注后向不兼容(不用管前向不兼容或者两者结合)，就可以避免软件兼容性错误的发生。
步骤102：对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理。预处理用于排除后向不兼容改变集合中与待检测软件的源码或二进制文件没有关系的后向不兼容改变。
具体的，预处理主要是为了排除两种情况：第一个是排除依赖版本范围不包括后向不兼容发生的库版本的情况，例如，软件指定依赖库glib>＝2.37.6，但后向不兼容改变是从版本glib-2.37.0到版本glib-2.37.3发生的变化；第二个排除是即使依赖版本范围包含了后向不兼容的库版本，但是软件并没有使用后向不兼容改变中变化的元素的情况，例如，后向不兼容改变为库中的一个符号删除了一个参数，但此符号没有被软件使用。所以这里首先要把这2部分都排除掉，相当于这里先做一个初筛，因为库的后向不兼容改变并不一定会导致软件产生兼容性问题的。
当旧的库版本发生后向不兼容改变(如删除接口)，软件开发者基于旧的库版本开发软件，终端用户在运行时将软件链接到新的库版本，此时库的新版本就和软件不兼容。库的后向不兼容改变不一定会导致软件出现兼容性错误，首先分析每个后向不兼容改变实例bics中变化的元素在待检测软件sw中的使用情况，并检测vnext是否和待检测软件sw不兼容。如果是，进一步判断不兼容版本是否被包含于sw指定的版本范围中。如果是，就报告一个软件依赖缺陷。常见应用场景是检测软件代码仓库中的依赖缺陷，如以apt整个软件仓库作为输入，检测仓库中的每个软件是否因bics而出现依赖缺陷。由于软件仓库可能包括成千上万的软件包，逐一分析每个软件包费时费力。因此在检测后向不兼容库版本之前先进行预处理。
首先，排除依赖版本范围不包括bics发生的库版本的情况。例如，sw指定依赖glib>＝2.37.6，但bics是从版本glib-2.37.0到版本glib-2.37.3发生的变化。
步骤104：根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；
具体的，分析bics中变化的元素在sw中的使用情况，并检测vnext是否和sw不兼容。如果bics打破了后向兼容，并且相应元素在sw中的使用符合vpre中的定义，则vnext被认为是不兼容版本。
对于每个后向不兼容改变，对比待检测软件中API的使用和新、旧库版本中API的定义，检测和待检测软件不兼容的库版本。当库打破后向兼容性且软件的API使用匹配旧版本的API定义时，则库的新版本和待检测软件不兼容，报告一个依赖缺陷。
本发明工作于二进制和源码级别，检测软件和第三方库之间的兼容性，不同于编译器从源码级别分析软件对API的使用。原因在于终端用户在安装软件时通常都会直接安装二进制文件(如使用命令aptinstall或yuminstall安装二进制软件)，而非选择源码编译安装软件，因此用户更加关注二级制级别的兼容性，但源码级别的兼容无法保证二进制级别的兼容，我们基于源码和二进制分析，检测不兼容库版本更加准确高效，误报率更低，从而推断依赖范围更精确。
步骤106：根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本。
具体的，将旧库版本和其他所有库版本进行对比，任何后向不兼容于此旧库版本的其他版本将同样被标记为不兼容版本，即可以得到所有的不兼容版本。
步骤108：根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。
具体的，自动推断出软件的正确的依赖范围，可帮助用户选择正确的库版本，从而预防兼容性错误。
采用本发明可以在一开始就避免软件兼容性错误的发生。相较于Darius Foo等人在FSE2018发表的“Efficient Static Checking of Library Updates(库更新的高效静态检查)”工作主要关注检测第三方库的变化，Li Li等人在ISSTA2018发表的“CiD:Automating the Detection of API-Related Compatibility Issues in Android Apps(CiD：自动检测Android应用程序中与API相关的兼容性问题)”工作主要关注检测软件对不兼容API的使用，Zhenchang Xing等人在TSE2007发表的“API-Evolution Support withDiff-CatchUp(使用Diff-CatchUp支持API演化)”工作主要关注如何帮助软件适应库的变化，本发明可以帮助终端用户从一开始就避免使用不兼容的库版本，从而避免兼容性错误的发生，而上述已有研究工作是无法自动帮助用户选择兼容的库版本，推断依赖范围。
上述软件依赖范围自动推断方法中，该方法包括：获取第三方库的若干个后向不兼容改变，对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本；根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。基于源码和二进制分析，检测不兼容库版本更加准确高效，误报率更低，从而推断依赖范围更精确，可以帮助终端用户从一开始就避免使用不兼容的库版本，从而避免兼容性错误的发生。
在其中一个实施例中，步骤100包括：以第三方库的所有版本作为输入，采用ABI合规性检测器收集后向不兼容改变集合，后向不兼容改变集合为：BICS(vpre,vnext)；第三方库的所有版本是源码或二进制文件；当第三方库包括N个版本时，收集到的所有后向不兼容改变集合为： 将后向不兼容改变集合中每个后向不兼容改变实例用三元组表示，得到每个库的后向不兼容改变三元组集合；后向不兼容改变实例bics的三元组为：<库名称，改变前后版本，改变内容>(例如：<glib(库名称)，<2.39.1,2.39.2>(改变前后版本)，g_hash_table_replace删除gboolean类型返回值(改变内容)>)；每个库的后向不兼容改变三元组集合的三元组为{<库名称，改变前后版本1，改变内容1>，<库名称，改变前后版本2，改变内容2>，……<库名称，改变前后版本M，改变内容M>}，其中M为每个库的后向不兼容改变的数量，M为大于0的整数。后向不兼容改变三元组集合是将后向不兼容改变集合中的每一个元素用三元组表示后得到的。后向不兼容改变三元组集合包括多个三元组，如：{<glib，<2.39.1,2.39.2>，g_hash_table_replace删除gboolean类型返回值>，<glib，<2.39.7,2.39.9>，g_hash_table_insert删除gboolean类型返回值>，<glib，<2.40.1,2.42.1>，g_hash_table_delete删除gboolean类型返回值>}。
具体的，ABI合规性检测器(ABI Compliance Checker，简称：ABICC)是一种用于检查C/C++软件库的向后二进制和源代码级兼容性的工具，可以检测库中打破后向兼容性的改变，用于检查C/C++软件库与库之间的向后二进制和源代码级兼容性，分析可能破坏二进制兼容性和源兼容性的API/ABI(ABI＝API+编译器ABI)的变化：调用堆栈的变化、虚函数表(v-table)的变化、删除的符号、重命名的字段等，为库的头文件和共享对象创建和比较ABI转储。ABI合规性检测器适用于对确保向后兼容性感兴趣的软件库开发人员和Linux维护人员，即允许旧应用程序运行或使用较新的库版本重新编译。
假设给定第三方库从版本vpre到版本vnext中，后向不兼容改变集合为BICS(vpre,vnext)，BICS(vpre,vnext)表示从版本vpre到版本vnext的后向不兼容改变集合(BackwardIncompatible Change Set，简称：BICS)。
当用户无法提供带有调试符号的二进制文件时，可以使用源码作为输入，使用提供的内置编译脚本自行编译出带有调试符号的二进制文件。在自行编译时，仅使用默认编译选项，同时接收用户提供的自定义编译选项。使用ABICC工具收集BICS(vpre,vnext)，当输入库包含N个版本时，收集当前库的所有后向不兼容改变集合每个后向不兼容改变实例bics是一个三元组：<库名称，改变前后版本，改变内容>。最终得到每个库的后向不兼容改变三元组集合{<库名称，改变前后版本，改变内容>……}。
在其中一个实施例中，步骤102具体包括如下步骤：
步骤200：分析待检测软件的所有依赖，提取待检测软件的库和每个库的版本范围。
具体的，分析待检测软件sw的所有依赖(软件包中定义的依赖描述文件，例如DEB包中的control文件，或RPM包中的.spec文件)，提取待检测软件sw依赖的库和每个库的版本范围。
步骤202：当发生后向不兼容改变的库不被待检测软件依赖，和/或当发生后向不兼容改变的版本不被包含于待检测软件依赖的版本范围，则报告没有依赖缺陷，并退出；
具体的，检测发生bics的库是否被待检测软件sw依赖，bics发生的版本vnext是否被包含于sw依赖的版本范围中；当不满足上述两个条件中的任意一个时，bics就无法对sw产生任何影响，因此报告没有依赖缺陷并退出。
步骤204：当待检测软件中没有使用后向不兼容改变中改变的符号，或当待检测软件中没有使用后向不兼容改变中改变的数据类型时，则报告没有依赖缺陷，并退出。
具体的，本步骤用于排除待检测软件sw中没有使用bics中变化的元素的情况。例如，bics为库中的一个符号删除了一个参数，但此符号没有被sw使用。bics中变化的元素通常可以被分两种情况：变化符号(例如从bar(node a)到bar())和变化数据类型(例如从struct node{long l；}到struct node{int i；})。分析sw中包含的二进制文件。具体包括：
(1)当bics改变的是一个符号时，使用readelf工具检测sw中是否有一个二进制文件使用了bics中改变的符号。
(2)当bics改变的是一个数据类型时，收集库中所有使用了此数据类型的符号，并检测软件包中是否有任意一个二进制文件使用了任意一个符号。
(3)如果是，则意味着bics可能会影响sw进而导致sw出现兼容性错误。否则，停止分析并报告没有依赖缺陷。
在其中一个实施例中，步骤104包括：对C/C++库中的每类二进制后向不兼容改变和源码后向不兼容改变制定相应的检测规则；二进制后向不兼容改变包括：数据类型改变、符号改变以及常量改变；源码后向不兼容改变包括：数据类型改变和符号改变；以输入为待检测软件的二进制文件或源码为输入，根据后向不兼容改变中的改变的类型，采取相应的检测规则，确定后向不兼容改变中变化的元素在待检测软件中的使用情况；如果后向不兼容改变打破了后向兼容，并且后向不兼容改变中发生改变的相应元素在待检测软件中的使用符合vpre版本中的定义，则vnest版本为后向不兼容库版本，并报告依赖缺陷。
具体的，后向不兼容库版本的检测阶段具体包括：
(1)使用待检测软件sw带有调试信息的二进制文件作为输入。当bics改变的是一个符号时，从二进制文件中提取相应符号签名；当bics改变的是一个数据类型时，从二进制文件中提取相应数据类型定义。参考https://lvc.github.io/abi-compliance-checker/列举了C/C++库中可能的二进制后向不兼容改变，并针对每种改变制定相应的不兼容版本检测规则，如表1所示。
表1检测二进制兼容性问题
将库的变化分为21种不同的类型，包含数据类型改变，符号改变，常量改变。具体检测方法如下：
1)对于数据类型改变(1-13类)，需要确认改变的元素被待检测软件sw使用；
2)对于符号改变(14-20类)，已经在预处理阶段确认改变的元素被待检测软件sw使用；
3)对于常量改变(21类)，同样需要确认改变的元素被待检测软件sw使用；
(2)如果用户无法提供带有调试信息的二进制文件，可以从待检测软件sw源码中提取相关元素的使用情况。例如，当分析软件仓库时，大部分软件并未发布带有调试信息的二进制文件，可下载待检测软件sw的源码并进行分析。当使用待检测软件sw源码作为输入时，由于无法获得相关库的头文件，因此难以提取相关符号签名或数据类型定义。也需要针对不同的bics类型，采取不同的规则，以检测不兼容版本。例如，当bics在一个结构体中删除了一个域时，需要检测删除的域是否在sw中被使用；当bics将一个函数返回值从non-void变为void时，需要检测sw源码中是否使用了返回值。为解决这一问题，同样列举了C/C++软件库中可能的源后向不兼容改变，并针对每种改变制定相应的不兼容版本检测规则。使用srcML工具对软件源码进行分析。因为sw的源码缺失库的头文件所以无法编译，而srcML能够对不可编译的代码片段进行词法分析和语法分析。列举的结果和相应的不兼容版本检测规则如表2所示。
表2检测源码兼容性问题
将库的变化分为12种不同的类型，包含数据类型改变，符号改变。具体方法如下：
1)对于数据类型改变(1-6类)，需要确认改变的元素被sw使用；
2)对于符号改变(7-12类)，已经在预处理阶段确认改变的元素被sw使用；
(3)最终返回一个二元组：<vpre,vnext>。bics发生的新版本和sw不兼容，且被sw指定版本范围包含时，vnext返回新版本的版本号，否则vnext返回-1。
在其中一个实施例中，以输入为待检测软件的二进制文件或源码为输入，根据后向不兼容改变中的改变的类型，采取相应的检测规则，确定后向不兼容改变中变化的元素在待检测软件中的使用情况，步骤中，如果输入为待检测软件的源码时，使用srcML工具对待检测软件的源码进行词法分析和语法分析。
在其中一个实施例中，步骤106包括：检测后向不兼容改变中改变的元素在第三方库的所有版本的兼容性，得到被检测软件的所有不兼容版本；不兼容版本的判断原则为：根据任一版本中关于后向不兼容改变中改变的元素的定义是否后向不兼容于发生改变的起始版本中后向不兼容改变中改变的元素的定义，如果是，则该版本是待检测软件的不兼容版本；根据第三方库的所有版本以及被检测软件的所有不兼容版本，设置布尔型变量isIV(vi)，布尔型变量isIV(vi)的表达式为：
其中，isIV(vi)表示版本vi是否为不兼容版本，vi为第三方库的第i个版本，i为大于0小于等于N的整数，N为第三方库包括的版本数量，bbc(vpre,vi,obj)为布尔类型，其含义为关于后向不兼容改变中改变的元素从vpre到vi是否打破后向兼容，如果是则返回1，否则返回0；
将第三方库的所有版本的布尔型变量isIV(vi)组成一个布尔值列表ISIV；布尔值列表ISIV为：
ISIV＝[isIV(v1),isIV(v2),…,isIV(vN) ] (2)
其中，isIV(vi)表示版本vi是否为不兼容版本的布尔型变量，如果isIV(vi)为1，且版本vi被包含于待检测软件指定的版本范围，则版本vi为不兼容版本；
根据布尔值列表ISIV、待检测软件以及第三方库，为每一个后向不兼容改变报告一个不兼容库版本集合，得到待检测软件和第三方库之间的不兼容版本。
应该理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
在一个具体的实施例中，如图2所示，提供了一种软件依赖范围自动推断方法，使用Ubuntu-19.10的软件仓库以评估本发明预防兼容性错误的有效性。在已有依赖管理系统中，apt可以自动解析软件依赖，而其他大多数系统需要开发人员人工输入。因此将apt作为已有做好工具，使用Ubuntu-19.10(使用apt管理软件)的软件仓库以评估预防兼容性错误的有效性。
第一步，收集第三方库的后向不兼容改变。例如以目标库zlib、qtbase、alsa为输入，收集其演化历史中的后向不兼容改变集合BICS。已有工具ABI Compliance Checker(ABICC)可以检测库中打破后向兼容性的改变，用于检查C/C++软件库与库之间的向后二进制和源代码级兼容性，分析可能破坏二进制兼容性和源兼容性的API/ABI(ABI＝API+编译器ABI)的变化：调用堆栈的变化、虚函数表(v-table)的变化、删除的符号、重命名的字段等，为库的头文件和共享对象创建和比较ABI转储。二进制不兼容可能会导致使用旧版本库构建的应用程序在新版本上运行时崩溃或行为不正确。源不兼容可能会导致使用新库版本重新编译错误。该工具适用于对确保向后兼容性感兴趣的软件库开发人员和Linux维护人员，即允许旧应用程序运行或使用较新的库版本重新编译。假设给定库从版本vpre到版本vnext中，后向不兼容改变集合为BISC(vpre,vnext)，BICS(vpre,vnext)表示从版本vpre到版本vnext的后向不兼容改变集合(BICS：Backward Incompatible Change Set)。对于每个库版本，需要库的所有版本作为输入。每个版本可以是源码形式或者带有调试符号的二进制形式。当用户无法提供带有调试符号的二进制文件时，可以使用源码作为输入，使用提供的内置编译脚本自行编译出带有调试符号的二进制文件。在自行编译时，仅使用默认编译选项，同时接收用户提供的自定义编译选项。我们使用默认编译选项，编译出zlib、qtbase、alsa库的带有调试符号的二进制文件，使用ABICC工具收集库zlib、qtbase、alsa库的BICS(vpre,vnext)。当输入库包含N个版本时，收集当前库的所有后向不兼容改变集合每个后向不兼容改变实例bics是一个三元组：<库名称，改变前后版本，改变内容>。最终得到zlib库的后向不兼容改变集合为{<zlib，1.2.5.1，1.2.5.2，gzflags>，<zlib，1.2.6.1，1.2.7，get_crc_table>……}；qtbase库的后向不兼容改变集合为{<qtbase，5.10.0，5.10.1，_ZN13QEglFSContext11runGLChecksEv>，<qtbase，5.13.2，5.14.0，_Z32qt_register_signal_spy_callbacksRK21QSignalSpyCallbackSet@@Qt_5>……}；alsa库的后向不兼容改变集合{<alsa，1.1.5，1.1.6，alsa_lisp_result_free@@ALSA_0.9.7>，<alsa，1.1.9，1.2.1，snd_tplg_new@@ALSA_0.9>……}；
第二步，基于源码和二进制分析，检测后向不兼容库版本，报告依赖缺陷。当旧库发生后向不兼容改变(如删除接口)，软件开发者基于旧的库版本开发软件，终端用户在运行时将软件链接到新的库版本，此时库的新版本就和软件不兼容。库的后向不兼容改变不一定会导致软件出现兼容性错误，分析每个后向不兼容改变实例bics中变化的元素在软件sw中的使用情况，并检测vnext是否和sw不兼容。如果是，进一步判断不兼容版本是否被包含于sw指定的版本范围中。如果是，就报告一个软件依赖缺陷。常见应用场景是检测软件代码仓库中的依赖缺陷，如以apt整个软件仓库作为输入，检测仓库中的每个软件是否因bics而出现依赖缺陷。由于软件仓库可能包括成千上万的软件包，逐一分析每个软件包费时费力。因此将检测过程分为两个阶段：预处理阶段和检测阶段。具体分析库zlib的每个后向不兼容改变实例在软件unalz_0.65-7(库依赖范围zlib1g>＝1.1.4)中的使用情况；库qtbase每个后向不兼容改变实例在软件gammaray_2.9.0(库依赖范围libqt5core5a>＝5.12.2)中的使用情况；库alsa每个后向不兼容改变实例在软件alsa-utils_1.1.9(库依赖范围libasound2>＝1.1.1)中的使用情况。方法是：
2.1预处理阶段。首先，排除依赖版本范围不包括bics发生的库版本的情况。例如，sw指定依赖glib>＝2.37.6，但bics是从版本glib-2.37.0到版本glib-2.37.3发生的变化。具体方法如下：
2.1.1分析unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9的所有依赖(软件包中定义的依赖描述文件，例如DEB包中的control文件，或RPM包中的.spec文件)，提取unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9依赖的库和每个库的版本范围；
2.1.2检测发生bics的库是否被unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9依赖，同时bics发生的版本vnext是否被包含于unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9依赖的版本范围中；
2.1.3当上述两个条件中的任何一个不被满足时，bics无法对unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9产生任何影响，因此报告没有依赖缺陷并退出；
2.1.4排除软件unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9中没有使用bics中变化的元素的情况。例如，bics为库中的一个符号删除了一个参数，但此符号没有被sw使用。bics中变化的元素通常可以被分两种情况：变化符号(例如从bar(node a)到bar())和变化数据类型(例如从struct node{long l；}到struct node{int i；})。分析unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9中包含的二进制文件。具体方法如下：
2.1.4.1当bics改变的是一个符号时，使用readelf工具检测unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9中是否有一个二进制文件使用了bics中改变的符号；
2.1.4.2当bics改变的是一个数据类型时，收集库中所有使用了此数据类型的符号，并检测软件包unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9中是否有任意一个二进制文件使用了任意一个符号；
2.1.4.3如果是，则意味着bics可能会影响unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9进而导致兼容性错误。否则，停止分析并报告没有依赖缺陷；
2.2检测阶段。分析bics中变化的元素在unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9中的使用情况，并检测vnext是否和unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9不兼容。如果bics打破了后向兼容，并且相应元素在unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9中的使用符合vpre中的定义，则vnext被认为是不兼容版本。
2.2.1使用unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9带有调试信息的二进制文件作为输入。当bics改变的是一个符号时，从二进制文件中提取相应符号签名；当bics改变的是一个数据类型时，从二进制文件中提取相应数据类型定义。参考https://lvc.github.io/abi-compliance-checker/列举了C/C++库中可能的二进制不兼容改变，并针对每种改变制定相应的不兼容版本检测规则，如表1所示。将库的变化分为21种不同的类型，包含数据类型改变，符号改变，常量改变。具体检测方法如下：
2.2.1.1对于数据类型改变(1-13类)，需要确认改变的元素被unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9使用；
2.2.1.2对于符号改变(14-20类)，已经在预处理阶段确认改变的元素被unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9使用；
2.2.1.3对于常量改变(21类)，同样需要确认改变的元素被unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9使用；
2.2.2如果用户无法提供带有调试信息的二进制文件，可以从unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9源码中提取相关元素的使用情况。例如，当分析软件仓库时，大部分软件并未发布带有调试信息的二进制文件，因此自动下载unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9的源码并进行分析。当使用unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9源码作为输入时，由于无法获得相关库的头文件，因此难以提取相关符号签名或数据类型定义。也需要针对不同的bics类型，采取不同的规则，以检测不兼容版本。例如，当bics在一个结构体中删除了一个域时，需要检测删除的域是否在se中被使用；当bics将一个函数返回值从non-void变为void时，需要检测sw源码中是否使用了返回值。为解决这一问题，同样列举了C/C++软件库中可能的源不兼容改变，并针对每种改变制定相应的不兼容版本检测规则。使用srcML(http://www.srcml.org/)工具对软件源码进行分析。因为unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9的源码缺失库的头文件所以无法编译，而srcML能够对不可编译的代码片段进行词法分析和语法分析。列举的结果和相应的不兼容版本检测规则如表2所示。将库的变化分为12种不同的类型，包含数据类型改变，符号改变。具体方法如下：
2.2.2.1对于数据类型改变(1-6类)，需要确认改变的元素被unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9使用；
2.2.2.2对于符号改变(7-12类)，已经在预处理阶段确认改变的元素被unalz_0.65-7、gammaray_2.9.0、alsa-utils_1.1.9使用；
2.2.3最终返回一个二元组：<vpre,vnext>。bics发生的新版本和sw不兼容，且被sw指定版本范围包含时，vnext返回新版本的版本号，否则vnext返回-1；
下表列举了一些依赖缺陷示例。软件unalz_0.65-7依赖于库zlib1g>＝1.1.4。zlib1g从版本1.2.6.1到版本1.2.7get_crc_table函数的返回值从long改为int，上述软件使用了long类型的返回值，因此1.2.7为不兼容版本，报告一个依赖缺陷。软件gammaray_2.9.0依赖于库libqt5core5a>＝5.12.2。qtbase从版本5.13.2到版本5.14.0改变了一个符号qt_register_signal_spy_callbacks()的参数类型，上述软件使用了之前参数类型的符号，因此5.14.0为不兼容版本，报告一个依赖缺陷。软件alsa-utils_1.1.9依赖于库libasound2>＝1.1.1。alsa从版本1.1.9到版本1.2.1删除符号snd_tplg_new@@ALSA_0.9，上述软件使用了该符号，因此1.2.1为不兼容版本，报告一个依赖缺陷。检测依赖缺陷示例如表3所示。
表3检测依赖缺陷示例
第三步，面向全局检测，得到所有不兼容库版本，自动推断出软件依赖范围。同一个元素可能会经历多次改变，需要面向所有库版本进行全局检测，以推断当前库后向不兼容改变引发的不兼容版本范围以得到软件正确的依赖范围。假设上一步得到的不兼容版本为vincomp，后向不兼容改变bics可能会导致vincomp之外的多个版本和sw不兼容。需要检测bice导致的所有后向不兼容于sw的库版本。为达到这一目标，我们不能简单地认为大于或者小于vincomp的版本为不兼容版本，因为在bics中改变的元素可能会经历多次修改。软件unalz_0.65-7的不兼容库版本为zlib1g-1.2.7，软件gammaray_2.9.0的不兼容库版本为libqt5core5a-5.14.0，软件alsa-utils_1.1.9的不兼容库版本为libasound2-1.2.1。不能简单以为上述软件依赖中大于或者小于这些库的版本为不兼容版本。具体方法如下：
3.1将bics中改变的元素记为obj。检测obj在comp的所有版本中的兼容性：对于任一版本v，如果v中关于obj的定义后向不兼容于vpre中obj的定义，则v也被认为是待检测软件sw的不兼容版本。假设comp有N个版本，对于计算布尔类型变量isIV(vi)，表示vi是否为不兼容版本：/> 其中bbc(vpre,vi,obj)同样为布尔类型，其含义为obj从vpre到vi是否打破后向兼容(break backwardcompatibility)。如果是则返回1，否则返回0；
3.2输出一个布尔值列表ISIV，其中的每一个元素分别表示相应版本是否为待检测软件sw后向不兼容版本：ISIV＝[isIV(v1),isIV(v2),…,isIV(vN)]，对于ISIV中的每一个元素isIV(vi)，如果isIV(vi)为1，且vi被包含于待检测软件sw指定的版本范围，将vi标记为不兼容版本。此外，对于没有在软件仓库中管理的软件，由于软件没有指定版本范围，软件可能不包含依赖描述文件，假设其接受库的所有版本；
3.3对于待检测软件sw和库comp，为每一个bics报告一个不兼容库版本集合IV<comp,sw,bics＞，假设库comp中共有M个不兼容改变。最终输出待检测软件sw和comp之间的不兼容库版本：其中bicsi代表库的第i个后向不兼容改变；
第四步，得到所有的不兼容库版本，自动推断出软件的正确的依赖范围，避免软件出现兼容性错误问题，推断流程结束。
最终推断软件unalz_0.65-7不兼容库版本范围为[1.2.7,vlast]，依赖范围为[1.1.4，1.2.6.1]；软件gammaray_2.9.0不兼容库版本范围为[5.14.0,vlast]，依赖范围为[5.12.2，5.13.2]；软件alsa-utils_1.1.9不兼容库版本范围为[1.2.1,vlast]，依赖范围为[1.1.1，1.1.9]。vlast表示拥有相同soname的最大库版本。推断依赖范围示例如表4所示。
表4推断依赖范围示例
| 软件 | 库(依赖范围) | 库变化版本 | 不兼容版本 | 正确依赖范围 |
| unalz_0.65-7 | zlib1g>＝1.1.4 | <1.2.6.1,1.2.7> | [1.2.7,vlast] | [1.1.4，1.2.6.1] |
| gammaray_2.9.0 | libqt5core5a>＝5.12.2 | <5.13.2,5.14.0> | [5.14.0,vlast] | [5.12.2，5.13.2] |
| alsa-utils_1.1.9 | libasound2>＝1.1.1 | <1.1.9,1.2.1> | [1.2.1,vlast] | [1.1.1，1.1.9] |
在一个实施例中，如图3所示，提供了一种软件依赖范围自动推断装置，包括：后向不兼容改变获取模块、后向不兼容版本检测模块、不兼容库版本确定模块和软件的正确依赖范围确定模块，其中：
后向不兼容改变获取模块，用于获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合；
后向不兼容版本检测模块，用于对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；
不兼容库版本确定模块，用于根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本；
软件的正确依赖范围确定模块，用于根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围。
在其中一个实施例中，后向不兼容改变获取模块，还用于以第三方库的所有版本作为输入，采用ABI合规性检测器收集后向不兼容改变集合，后向不兼容改变集合为：BICS(vpre,vnext)；第三方库的所有版本是源码或二进制文件；当第三方库包括N个版本时，收集到的所有后向不兼容改变集合为： 将后向不兼容改变集合中每个后向不兼容改变实例用三元组表示，得到每个库的后向不兼容改变三元组集合；后向不兼容改变实例bics的三元组为：<库名称，改变前后版本，改变内容>；每个库的后向不兼容改变三元组集合的三元组为{<库名称，改变前后版本1，改变内容1>，<库名称，改变前后版本2，改变内容2>，……<库名称，改变前后版本M，改变内容M>}，其中M为每个库的后向不兼容改变的数量，M为大于0的整数。
在其中一个实施例中，后向不兼容版本检测模块，还用于分析待检测软件的所有依赖，提取待检测软件的库和每个库的版本范围；当发生后向不兼容改变的库不被待检测软件依赖，和/或当发生后向不兼容改变的版本不被包含于待检测软件依赖的版本范围，则报告没有依赖缺陷，并退出；当待检测软件中没有使用后向不兼容改变中改变的符号，或当待检测软件中没有使用后向不兼容改变中改变的数据类型时，则报告没有依赖缺陷，并退出。
在其中一个实施例中，后向不兼容版本检测模块，还用于对C/C++库中的每类二进制后向不兼容改变和源码后向不兼容改变制定相应的检测规则；二进制后向不兼容改变包括：数据类型改变、符号改变以及常量改变；源码后向不兼容改变包括：数据类型改变和符号改变；以输入为待检测软件的二进制文件或源码为输入，根据后向不兼容改变中的改变的类型，采取相应的检测规则，确定后向不兼容改变中变化的元素在待检测软件中的使用情况；如果后向不兼容改变打破了后向兼容，并且后向不兼容改变中发生改变的相应元素在待检测软件中的使用符合vpre版本中的定义，则vnext版本为后向不兼容库版本，并报告依赖缺陷。
在其中一个实施例中，后向不兼容版本检测模块中，如果输入为待检测软件的源码时，使用srcML工具对待检测软件的源码进行词法分析和语法分析。
在其中一个实施例中，不兼容库版本确定模块，还用于检测后向不兼容改变中改变的元素在第三方库的所有版本的兼容性，得到被检测软件的所有不兼容版本；不兼容版本的判断原则为：根据任一版本中关于后向不兼容改变中改变的元素的定义是否后向不兼容于发生改变的起始版本中后向不兼容改变中改变的元素的定义，如果是，则该版本是待检测软件的不兼容版本；根据第三方库的所有版本以及被检测软件的所有不兼容版本，设置布尔型变量isIV(vi)，布尔型变量isIV(vi的表达式为：
其中，isIV(vi)表示版本vi是否为不兼容版本，vi为第三方库的第i个版本，i为大于0小于等于N的整数，N为第三方库包括的版本数量，bbc(vpre,vi,obj)为布尔类型，其含义为关于后向不兼容改变中改变的元素从vpre到vi是否打破后向兼容，如果是则返回1，否则返回0；
将第三方库的所有版本的布尔型变量isIV(vi)组成一个布尔值列表ISIV；布尔值列表ISIV为：
ISIV＝[isIV(v1),isIV(v2),…,isIV(vN)]
其中，isIV(vi)表示版本vi是否为不兼容版本的布尔型变量，如果isIV(vi)为1，且版本vi被包含于待检测软件指定的版本范围，则版本vi为不兼容版本；
根据布尔值列表ISIV、待检测软件以及第三方库，为每一个后向不兼容改变报告一个不兼容库版本集合，得到待检测软件和第三方库之间的不兼容版本。
关于软件依赖范围自动推断装置的具体限定可以参见上文中对于软件依赖范围自动推断方法的限定，在此不再赘述。上述软件依赖范围自动推断装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种软件依赖范围自动推断方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该处理器执行计算机程序时实现上述方法实施例中的步骤。
在一个实施例中，提供了一种计算机可读存储器，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例中的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储器中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。
Claims (9)
1.一种软件依赖范围自动推断方法，其特征在于，所述方法包括：
获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合；
对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；所述预处理用于排除后向不兼容改变集合中与待检测软件的源码或二进制文件没有关系的后向不兼容改变；
根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；
根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本；
根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围；
其中，根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷，包括：
对C/C++库中的每类二进制后向不兼容改变和源码后向不兼容改变制定相应的检测规则；二进制后向不兼容改变包括：用于数据类型改变、符号改变以及常量改变；其中，二进制后向不兼容改变中的数据类型改变的结构体和类的检测规则包括：对结构体和类的添加/删除字段的不兼容改变的类型使用字段检测规则，对大小变化的不兼容改变类型使用字段检测规则，对字段顺序变化的不兼容改变类型使用字段比较顺序的检测规则，对字段类型变化的不兼容改变类型使用字段和匹配字段类型的检测规则；二进制后向不兼容改变中的数据类型改变的类不兼容改变类型的检测规则包括：对添加/删除虚函数的不兼容性改变类型使用虚函数检测规则，对虚函数位置变化的不兼容性改变类型使用比较虚函数位置的检测规则，对虚函数重写的不兼容性改变类型使用虚函数的检测规则，对添加/删除基类的不兼容性改变类型使用基类的检测规则；二进制后向不兼容改变中的数据类型改变的联合体不兼容改变类型的检测规则包括：对添加/删除字段的不兼容性改变类型使用字段的检测规则，对大小变化的不兼容改变类型使用字段检测规则，字段类型的变化的不兼容改变类型使用字段和匹配字段类型的检测规则；二进制后向不兼容改变中的数据类型改变的枚举不兼容改变类型的检测规则包括：对成员值变化和删除/重命名成员的不兼容改变类型均使用成员检测规则；二进制后向不兼容改变中符号改变的不兼容改变检测规则包括：对删除符号、符号改变的不正确的版本变化以及属性变化的不兼容改变类型使用符号检测规则，对默添加/删除参数、认参数值变化以及重命名参数的不兼容改变类型使用参数检测规则，对参数/返回值类型变化的不兼容改变类型使用匹配参数/返回值类型检测规则；二进制后向不兼容改变中常量改变的不兼容改变检测规则包括：对值变化的不兼容改变使用常量值检测规则；源码后向不兼容改变包括：数据类型改变和符号改变；其中，源码后向不兼容改变中的数据类型改变的检测规则包括：对于结构体、类以及联合体的删除/重命名字段的不兼容改变类型的检测规则为使用字段进行检测；对于结构体、类以及联合体的字段类型变化的不兼容改变类型的检测规则为使用字段和匹配字段类型进行检测；对于类数据类型添加/删除基类的不兼容改变类型，使用基类的检测规则；对于类数据类型更改字段或方法的访问级别的不兼容改变类型，使用字段或方法检测规则；对于类数据类型添加纯虚方法的不兼容改变类型，使用纯虚方法检测规则；对于枚举数据类型删除/重命名成员的不兼容改变类型，使用成员检测规则；源码后向不兼容改变中的符号改变包括：对于删除符号的不兼容改变类型使用符号的检测规则；对于添加/删除参数的不兼容改变模型使用参数的检测规则；对于改变参数类型的不兼容改变类型采用匹配参数类型的检测规则；对于删除默认参数值的不兼容改变类型使用参数检测规则，对于返回值类型变化的不兼容改变类型使用匹配返回值类型检测规则，对于属性变化的不兼容改变类型使用符号检测规则；
以待检测软件的二进制文件或源码为输入，根据后向不兼容改变中的改变的类型，采取相应的检测规则，确定后向不兼容改变中变化的元素在待检测软件中的使用情况；其中，对于二进制文件确定后向不兼容改变中变化的元素在待检测软件中的使用情况的具体步骤包括：对于二进制后向不兼容改变的数据类型改变，确认改变的元素是否被待检测软件使用；对于二进制后向不兼容改变的符号改变，确认已经在预处理阶段确认改变的元素被待检测软件使用；对于二进制后向不兼容改变的常量改变，确认改变的元素被待检测软件使用；对于源码确定后向不兼容改变中变化的元素在待检测软件中的使用情况的具体步骤包括：对于源码后向不兼容改的变数据类型改变，确认改变的元素被待检测软件使用；对于源码后向不兼容改变的符号改变，确认已经在预处理阶段确认改变的元素被待检测软件使用；
如果后向不兼容改变打破了后向兼容，并且后向不兼容改变中发生改变的相应元素在待检测软件中的使用符合vpre版本中的定义，则vnext版本为后向不兼容库版本，并报告依赖缺陷；其中，vpre为前一个版本，vnext为后一个版本。
2.根据权利要求1所述的方法，其特征在于，获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合，包括：
以第三方库的所有版本作为输入，采用ABI合规性检测器收集后向不兼容改变集合，所述后向不兼容改变集合由多个后向不兼容改变组成，所述后向不兼容改变为：BICS(vpre,vnext)，其中，所述第三方库的所有版本是源码或二进制文件；
当第三方库包括N个版本时，收集到的所有后向不兼容改变集合为： 其中，i为大于0小于等于N的整数；
将后向不兼容改变集合中每个后向不兼容改变实例用三元组表示，得到每个库的后向不兼容改变三元组集合；后向不兼容改变实例的三元组为：<库名称，改变前后版本，改变内容>；每个库的后向不兼容改变三元组集合的三元组为{<库名称，改变前后版本1，改变内容1>，<库名称，改变前后版本2，改变内容2>，……<库名称，改变前后版本M，改变内容M>}，其中M为每个库的后向不兼容改变的数量，M为大于0的整数。
3.根据权利要求1所述的方法，其特征在于，对待检测软件进行分析，根据分析结果对后向不兼容改变集合进行预处理，包括：
分析待检测软件的所有依赖，提取待检测软件的库和每个库的版本范围；
当发生后向不兼容改变的库不被待检测软件依赖，或当发生后向不兼容改变的版本不被包含于待检测软件依赖的版本范围，则报告没有依赖缺陷，并退出；
当待检测软件中没有使用后向不兼容改变中改变的符号，或当待检测软件中没有使用后向不兼容改变中改变的数据类型时，则报告没有依赖缺陷，并退出。
4.根据权利要求1所述的方法，其特征在于，以待检测软件的二进制文件或源码为输入，根据后向不兼容改变中的改变的类型，采取相应的检测规则，确定后向不兼容改变中变化的元素在待检测软件中的使用情况，步骤中，如果输入为待检测软件的源码时，使用srcML工具对待检测软件的源码进行词法分析和语法分析。
5.根据权利要求1所述的方法，其特征在于，根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本，包括：
检测后向不兼容改变中改变的元素在第三方库的所有版本的兼容性，得到被检测软件的所有不兼容版本；不兼容版本的判断原则为：根据任一版本中关于后向不兼容改变中改变的元素的定义是否后向不兼容于发生改变的起始版本中后向不兼容改变中改变的元素的定义，如果是，则该版本是待检测软件的不兼容版本；
根据第三方库的所有版本以及被检测软件的所有不兼容版本，设置布尔型变量isIV(vi)，布尔型变量isIV(vi)的表达式为：
其中，isIV(vi)表示版本vi是否为不兼容版本，vi为第三方库的第i个版本，i为大于0小于等于N的整数，N为第三方库包括的版本数量，bbc(vpre,vi,obj)为布尔类型，其含义为关于后向不兼容改变中改变的元素从vpre到vi是否打破后向兼容，如果是则返回1，否则返回0；obj为后向不兼容改变中改变的元素；
将第三方库的所有版本的布尔型变量isIV(vi)组成一个布尔值列表ISIV；布尔值列表ISIV为：
ISIV＝[isIV(v1),isIV(v2),…,isIV(vN)]
其中，isIV(vi)表示版本vi是否为不兼容版本的布尔型变量，如果isIV(vi)为1，且版本vi被包含于待检测软件指定的版本范围，则版本vi为不兼容版本；
根据布尔值列表ISIV、待检测软件以及第三方库，为每一个后向不兼容改变报告一个不兼容库版本集合，得到待检测软件和第三方库之间的不兼容版本。
6.一种软件依赖范围自动推断装置，其特征在于，所述装置包括：
后向不兼容改变获取模块，用于获取第三方库的若干个后向不兼容改变，得到后向不兼容改变集合；
后向不兼容版本检测模块，用于对待检测软件的源码或二进制文件进行分析，根据分析结果对后向不兼容改变集合进行预处理；根据待检测软件的源码或二进制文件，对预处理后的后向不兼容改变集合进行检测，确定后向不兼容改变中变化的元素在待检测软件中的使用情况以及后向不兼容库版本，并报告依赖缺陷；
不兼容库版本确定模块，用于根据后向不兼容改变对第三方库的所有库版本进行全局检测，得到与待检测软件不兼容的所有不兼容库版本；
软件的正确依赖范围确定模块，用于根据所有的不兼容库版本，自动推断出待检测软件的正确依赖范围；
其中，后向不兼容版本检测模块，还用于对C/C++库中的每类二进制后向不兼容改变和源码后向不兼容改变制定相应的检测规则；二进制后向不兼容改变包括：用于数据类型改变、符号改变以及常量改变；其中，二进制后向不兼容改变中的数据类型改变的结构体和类的检测规则包括：对结构体和类的添加/删除字段的不兼容改变的类型使用字段检测规则，对大小变化的不兼容改变类型使用字段检测规则，对字段顺序变化的不兼容改变类型使用字段比较顺序的检测规则，对字段类型变化的不兼容改变类型使用字段和匹配字段类型的检测规则；二进制后向不兼容改变中的数据类型改变的类不兼容改变类型的检测规则包括：对添加/删除虚函数的不兼容性改变类型使用虚函数检测规则，对虚函数位置变化的不兼容性改变类型使用比较虚函数位置的检测规则，对虚函数重写的不兼容性改变类型使用虚函数的检测规则，对添加/删除基类的不兼容性改变类型使用基类的检测规则；二进制后向不兼容改变中的数据类型改变的联合体不兼容改变类型的检测规则包括：对添加/删除字段的不兼容性改变类型使用字段的检测规则，对大小变化的不兼容改变类型使用字段检测规则，字段类型的变化的不兼容改变类型使用字段和匹配字段类型的检测规则；二进制后向不兼容改变中的数据类型改变的枚举不兼容改变类型的检测规则包括：对成员值变化和删除/重命名成员的不兼容改变类型均使用成员检测规则；二进制后向不兼容改变中符号改变的不兼容改变检测规则包括：对删除符号、符号改变的不正确的版本变化以及属性变化的不兼容改变类型使用符号检测规则，对默添加/删除参数、认参数值变化以及重命名参数的不兼容改变类型使用参数检测规则，对参数/返回值类型变化的不兼容改变类型使用匹配参数/返回值类型检测规则；二进制后向不兼容改变中常量改变的不兼容改变检测规则包括：对值变化的不兼容改变使用常量值检测规则；源码后向不兼容改变包括：数据类型改变和符号改变；其中，源码后向不兼容改变中的数据类型改变的检测规则包括：对于结构体、类以及联合体的删除/重命名字段的不兼容改变类型的检测规则为使用字段进行检测；对于结构体、类以及联合体的字段类型变化的不兼容改变类型的检测规则为使用字段和匹配字段类型进行检测；对于类数据类型添加/删除基类的不兼容改变类型，使用基类的检测规则；对于类数据类型更改字段或方法的访问级别的不兼容改变类型，使用字段或方法检测规则；对于类数据类型添加纯虚方法的不兼容改变类型，使用纯虚方法检测规则；对于枚举数据类型删除/重命名成员的不兼容改变类型，使用成员检测规则；源码后向不兼容改变中的符号改变包括：对于删除符号的不兼容改变类型使用符号的检测规则；对于添加/删除参数的不兼容改变模型使用参数的检测规则；对于改变参数类型的不兼容改变类型采用匹配参数类型的检测规则；对于删除默认参数值的不兼容改变类型使用参数检测规则，对于返回值类型变化的不兼容改变类型使用匹配返回值类型检测规则，对于属性变化的不兼容改变类型使用符号检测规则；以待检测软件的二进制文件或源码为输入，根据后向不兼容改变中的改变的类型，采取相应的检测规则，确定后向不兼容改变中变化的元素在待检测软件中的使用情况；其中，对于二进制文件确定后向不兼容改变中变化的元素在待检测软件中的使用情况的具体步骤包括：对于二进制后向不兼容改变的数据类型改变，确认改变的元素是否被待检测软件使用；对于二进制后向不兼容改变的符号改变，确认已经在预处理阶段确认改变的元素被待检测软件使用；对于二进制后向不兼容改变的常量改变，确认改变的元素被待检测软件使用；对于源码确定后向不兼容改变中变化的元素在待检测软件中的使用情况的具体步骤包括：对于源码后向不兼容改的变数据类型改变，确认改变的元素被待检测软件使用；对于源码后向不兼容改变的符号改变，确认已经在预处理阶段确认改变的元素被待检测软件使用。
7.根据权利要求6所述的装置，其特征在于，后向不兼容改变获取模块，还用于以第三方库的所有版本作为输入，采用ABI合规性检测器收集后向不兼容改变集合，所述后向不兼容改变集合为：BICS(vpre,vnext)；第三方库的所有版本是源码或二进制文件；当第三方库包括N个版本时，收集到的所有后向不兼容改变集合为：将后向不兼容改变集合中每个后向不兼容改变实例用三元组表示，得到每个库的后向不兼容改变三元组集合；所述后向不兼容改变实例bics的三元组为：<库名称，改变前后版本，改变内容>；每个库的后向不兼容改变三元组集合的三元组为{<库名称，改变前后版本1，改变内容1>，<库名称，改变前后版本2，改变内容2>，……<库名称，改变前后版本M，改变内容M>}，其中M为每个库的后向不兼容改变的数量，M为大于0的整数。
8.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5中任一项所述的方法。
9.一种计算机可读存储器，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至5中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211694947.8A CN115934157B (zh) | 2022-12-28 | 2022-12-28 | 软件依赖范围自动推断方法、装置、计算机设备和存储器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211694947.8A CN115934157B (zh) | 2022-12-28 | 2022-12-28 | 软件依赖范围自动推断方法、装置、计算机设备和存储器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115934157A CN115934157A (zh) | 2023-04-07 |
| CN115934157B true CN115934157B (zh) | 2024-04-16 |
Family
ID=86555771
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211694947.8A Active CN115934157B (zh) | 2022-12-28 | 2022-12-28 | 软件依赖范围自动推断方法、装置、计算机设备和存储器 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115934157B (zh) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105843614A (zh) * | 2016-03-22 | 2016-08-10 | 东南大学 | 一种面向软件演化的代码可兼容性评估方法 |
| CN110543423A (zh) * | 2019-09-05 | 2019-12-06 | 中国人民解放军国防科技大学 | 一种软件依赖包能力检测方法、系统及介质 |
| CN112596779A (zh) * | 2020-12-16 | 2021-04-02 | 中国建设银行股份有限公司 | 兼容双版本的依赖包生成方法、装置、设备及存储介质 |
| CN112764797A (zh) * | 2021-01-06 | 2021-05-07 | 浙江大华技术股份有限公司 | 软件兼容性检测方法、装置、电子装置和存储介质 |
| CN112860545A (zh) * | 2021-01-25 | 2021-05-28 | 国电南瑞科技股份有限公司 | 一种软件缺陷检测方法与装置 |
| CN113688045A (zh) * | 2021-08-26 | 2021-11-23 | 烽火通信科技股份有限公司 | 一种二进制接口兼容性自动检查方法及装置 |
| CN114780950A (zh) * | 2022-06-20 | 2022-07-22 | 中国人民解放军国防科技大学 | 应用软件跨版本兼容运行的方法、系统、装置及存储介质 |
| CN115268991A (zh) * | 2022-08-05 | 2022-11-01 | 中国平安财产保险股份有限公司 | 依赖分析的优化方法、装置、设备和存储介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030191870A1 (en) * | 2002-04-02 | 2003-10-09 | Dominic Duggan | Method and apparatus for updating software libraries |
| US20110302565A1 (en) * | 2010-06-07 | 2011-12-08 | Ferris Michael S | Implicit workspace dependencies |
| US9483284B2 (en) * | 2011-02-25 | 2016-11-01 | Red Hat, Inc. | Version compatibility determination |
| US11086619B2 (en) * | 2019-01-04 | 2021-08-10 | Morgan Stanley Services Group Inc. | Code analytics and publication platform |
-
2022
- 2022-12-28 CN CN202211694947.8A patent/CN115934157B/zh active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105843614A (zh) * | 2016-03-22 | 2016-08-10 | 东南大学 | 一种面向软件演化的代码可兼容性评估方法 |
| CN110543423A (zh) * | 2019-09-05 | 2019-12-06 | 中国人民解放军国防科技大学 | 一种软件依赖包能力检测方法、系统及介质 |
| CN112596779A (zh) * | 2020-12-16 | 2021-04-02 | 中国建设银行股份有限公司 | 兼容双版本的依赖包生成方法、装置、设备及存储介质 |
| CN112764797A (zh) * | 2021-01-06 | 2021-05-07 | 浙江大华技术股份有限公司 | 软件兼容性检测方法、装置、电子装置和存储介质 |
| CN112860545A (zh) * | 2021-01-25 | 2021-05-28 | 国电南瑞科技股份有限公司 | 一种软件缺陷检测方法与装置 |
| CN113688045A (zh) * | 2021-08-26 | 2021-11-23 | 烽火通信科技股份有限公司 | 一种二进制接口兼容性自动检查方法及装置 |
| CN114780950A (zh) * | 2022-06-20 | 2022-07-22 | 中国人民解放军国防科技大学 | 应用软件跨版本兼容运行的方法、系统、装置及存储介质 |
| CN115268991A (zh) * | 2022-08-05 | 2022-11-01 | 中国平安财产保险股份有限公司 | 依赖分析的优化方法、装置、设备和存储介质 |
Non-Patent Citations (3)
| Title |
|---|
| Windows Shellcode自动构建方法研究;朱帅;罗森林;柯懂湘;;信息网络安全;20170410(第04期);全文 * |
| Zhouyang Jia ; Shanshan Li等.Detecting Dependency Bugs to Prevent Compatibility Failures.IEEE.2021,正文第1页至第13页. * |
| 大规模软件系统日志研究综述;廖湘科;李姗姗;董威;贾周阳;刘晓东;周书林;;软件学报;20151106(第08期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115934157A (zh) | 2023-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7725881B2 (en) | Automatically extracting coupling metrics from compiled code | |
| US6071317A (en) | Object code logic analysis and automated modification system and method | |
| US8352921B2 (en) | Static analysis defect detection in the presence of virtual function calls | |
| Marcilio et al. | SpongeBugs: Automatically generating fix suggestions in response to static code analysis warnings | |
| US20170169229A1 (en) | Vulnerability analysis of software components | |
| EP1752874A1 (en) | Adaptive evolutionary computer software product | |
| US20110126179A1 (en) | Method and System for Dynamic Patching Software Using Source Code | |
| Kirbas et al. | The relationship between evolutionary coupling and defects in large industrial software | |
| US10514898B2 (en) | Method and system to develop, deploy, test, and manage platform-independent software | |
| CN112965913B (zh) | 一种Java软件依赖冲突问题自动化修复的方法 | |
| CN112181858B (zh) | Java软件项目依赖冲突语义一致性的自动化检测方法 | |
| Chaliasos et al. | Well-typed programs can go wrong: A study of typing-related bugs in jvm compilers | |
| Silva et al. | Flacoco: Fault localization for java based on industry-grade coverage | |
| Di Grazia et al. | The evolution of type annotations in python: an empirical study | |
| US10839124B1 (en) | Interactive compilation of software to a hardware language to satisfy formal verification constraints | |
| CN111190641B (zh) | 基于API分析的Java第三方库版本统一推荐方法 | |
| Liu et al. | Towards understanding bugs in python interpreters | |
| US8930765B2 (en) | Systems and methods for feedback driven regression testing | |
| CN115934157B (zh) | 软件依赖范围自动推断方法、装置、计算机设备和存储器 | |
| CN117215558A (zh) | 安卓的基于可视化的软件开发方法、装置、设备及介质 | |
| Mukelabai et al. | Semi-automated test-case propagation in fork ecosystems | |
| Mendonça et al. | Feature-oriented test case selection and prioritization during the evolution of highly-configurable systems | |
| He et al. | The characteristics and impact of uncompilable code changes on software quality evolution | |
| CN115016970A (zh) | 自动化分析开源项目补丁的方法及应用 | |
| Mak et al. | Automatic build repair for test cases using incompatible Java versions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |