一种Java依赖库版本升级自动化风险评估的方法

一种java依赖库版本升级自动化风险评估的方法
技术领域
1.本发明涉及软件依赖管理领域，尤其涉及一种java软件依赖库版本升级自动化风险评估的方法。


背景技术：

2.java是世界上诸多开发者使用的程序开发语言。随着开源运动的兴起，在java世界里形成了非常丰富的外部开源依赖库。同时在企业内部随着技术团队的发展，沉淀了大量的企业内部自研依赖库。这些外部开源依赖库以及内部自研依赖库降低了企业研发成本，加快了产品交付周期，给企业软件产品研发带来了极大的便利。依赖库带来便利的同时也带来了一些问题。无论是外部开源依赖库还是内部自研依赖库，随着时间的发展往往进行功能的更新，缺陷的修复，形成同一个依赖库的多个版本。通常情况下依赖库的使用方不必跟随依赖库版本的升级而升级，但有些特殊情况下，例如依赖库某些版本存在重大安全隐患或严重功能缺陷等情况下，依赖库的使用方必须升级到特定版本以解决当前使用版本中存在的问题。在依赖库升级的过程中，研发人员需要花费大量的时间研究测试引入新版本依赖库可能带来的影响。通过自动化的分析新旧两个版本依赖库之间的类方法差异以及依赖库使用方当前使用到的类方法，可以帮助软件开发者花费更少的时间判断新版本依赖库可能带来的影响。


技术实现要素：

3.本发明要克服现有技术的依赖库升级过程中研发人工评估新版本依赖库影响的不足，提供一种java软件依赖库版本升级自动化风险评估的方法。
4.为解决上述技术问题，本发明的一种java软件依赖库版本升级自动化风险评估的方法，包括如下步骤：
5.步骤1：从java依赖仓库中获取依赖库当前版本以及待升级版本java源代码
6.步骤2：对依赖库新旧版本源代码解析，获取依赖库中所包含的类方法列表，具体方法如下：
7.步骤2.1:获取依赖库信息，具体信息包括依赖库标识，以及依赖库版本。
8.步骤2.2:基于依赖库信息查询是否存在所指定的依赖库解析数据，如存在则进入步骤3，否则进入下一步骤。
9.步骤2.3:对依赖库源代码进行解析，得到依赖库所有的包，类，方法以及方法签名等信息。
10.步骤2.4:将依赖库解析结果保存数据库。
11.步骤3：基于步骤2得到的依赖库类方法列表，对比新旧两个版本，识别旧版本中类方法变更信息，例如删除的类方法，废弃的类方法等，具体方法如下：
12.步骤3.1:获取待对比依赖库新旧版本信息。
13.步骤3.2:查询是否存在该依赖库新旧两个版本的变更信息，如存在则进入步骤4，
否则进入下一步骤。
14.步骤3.3:获取依赖库旧版本所有方法，依次遍历所有方法与依赖库新版本解析结果进行对比，判断该方法是否在变更，并将变更信息保存数据库。
15.步骤4：对使用依赖库的应用源代码解析，获取应用源代码中实际使用的依赖库类方法，具体方法如下：
16.步骤4.1:获取使用依赖库的应用源代码。
17.步骤4.2:查询是否存在该应用方法调用链路的解析，如存在则进入步骤5，否则进入下一步。
18.步骤4.3:对该应用源代码进行源代码解析，获取该应用所有使用到的包，类，方法以及方法签名信息，并保存数据库。
19.步骤5：对比步骤3和步骤4中旧版本依赖库中变更的类方法和应用中实际使用的依赖库类方法，如发现应用中实际使用的依赖库方法发生了变化，则记录一条风险，具体方法如下：
20.步骤5.1:获取应用信息，依赖库新旧版本信息。
21.步骤5.2:查询是否存在依赖库版本升级风险信息，如存在则进入步骤6，否则进入下一步骤。
22.步骤5.3:获取应用使用的依赖库所有方法信息，依次遍历所有依赖方法，并与依赖库变更信息作对比，如果应用使用了变更的方法，则记录一条风险信息。
23.步骤6：分析完成后将风险评估结果推送给对应的研发人员
24.优选地，步骤1具体包括：所有依赖库存放在maven仓库中，系统基于依赖库的标识信息，从maven仓库中拉取依赖库新旧两个版本的源代码，将源代码保存到本地。
25.优选地，步骤2.1所述的依赖库的标识信息包括groupid，artifactid和version等信息。步骤2.2具体包括：使用groupid，artifactid以及version作为查询条件，查询依赖库解析数据库，判断该依赖库版本是否已经在其他过程中被解析过
26.优选地，步骤3.2具体包括：使用旧依赖库信息：oldgroupid，oldartifactid和oldversion以及新依赖库信息：newgroupid，newartifactid和newversion作为组合条件查询数据，判断是否存在两个版本依赖库的变更分析结果。如果存在变更结果，则无需再次进行分析，可直接进入步骤4，否则需要分析新旧两个版本的依赖库变更信息，进入下一步骤。
27.步骤3.3中利用oldgroupid，oldartifactid和oldversion查询到旧版本依赖库中所有的方法信息，建立待分析方法列表。利用newgroupid，newartifactid和newversion查询到新版本依赖库中所有的方法信息，建立对比方法列表。进一步依次的遍历待分析方法列表，并与新版本对比方法列表做对比分析，判断该方法是否存在于有变更。具体判断标准如下：在分析方法列表中是否存在与待分析方法所属的包名，类名，返回信息以及参数信息完全相同的方法，如果不存在则记录一条变更方法变更信息表示该方法已经在新版本中不存在，并且将该信息保存到数据库中。如果存在则继续分析下一个待分析方法直到所有待分析方法分析完成。
28.优选地，步骤4.1接拉取应用在git仓库中的master分支信息作为应用源代码分析的基础。
29.步骤4.2具体包括：利用应用名称，应用git仓库地址以及旧版本依赖库信息查询
应用方法调用链路解析数据库，判断是否存在该应用与该依赖库的调用链路解析，如果存在则直接进入步骤5。否则进入下一步骤进行应用调用链路解析。
30.步骤4.3具体包括：使用javaparser对应用源代码进行解析，得到该应用的抽象语法树。基于得到的抽象语法树进一步分析，获取应用方法调用链路分析信息，包括应用名，包名，类名，方法名，依赖的依赖库信息，包括依赖库信息groupid，artifactid，version和依赖方法信息包括了该方法所属的包名，类名，返回结果类型，输入的参数等信息，并将该信息保存到数据库中。
31.优选地，步骤5.2具体包括：基于应用名，应用地址仓库，旧依赖库信息，新依赖库信息查询依赖库版本升级风险数据库，判断是否存在版本升级风险信息，如存在则直接进入步骤6。否则进入下一步进行升级风险分析。
32.步骤5.3具体包括：首先基于应用名称，git仓库地址信息以及旧版本依赖库信息，查询应用所使用的旧版本依赖库中方法信息，建立应用依赖方法列表。遍历所有的依赖方法，对所有的依赖方法执行风险判断，具体判断方式如下：从应用依赖方法列表中选择一个待分析的方法，使用该方法信息，包括groupid，artifactid，version和依赖方法信息包括了该方法所属的包名，类名，返回结果类型，输入的参数等信息，并结合新版本依赖库信息包括groupid，artifactid，version等，查询依赖库变更数据库，如果找到对应的变更信息则记录一条风险信息，包括应用名称，git仓库地址，老版本依赖库，新版本数据库，升级存在的风险方法等。如果没有找到对应的变更信息则继续选择应用依赖方法列表中的下一条进行分析，直到所有的方法分析完成。
33.优选地，步骤6具体包括：从版本升级风险数据库中获取该应用从旧版本升级到新版本所有的风险信息，并通过企业内部消息系统将风险评估结果推送到负责该应用的研发人员，信息包括应用名称，git仓库地址，老版本依赖库，新版本数据库，升级存在的风险方法等，供研发人员判断是否升级到新版本依赖库以及如何升级到新版本依赖库。
34.本发明的工作原理是：提出一种java软件依赖库升级自动化风险评估方法。该方法采用java静态代码分析技术，通过对依赖库源代码静态分析提取出依赖库提供的java包、类、方法等信息，并以此为基础做不同版本依赖库间差异对比分析，同时通过静态代码分析技术对应用源代码进行分析，提取出该应用对旧版本依赖库所提供方法的使用信息，并在此基础上结合依赖库版本差异信息，分析出依赖库版本升级到目标版本依赖库所存在的风险信息。
35.本发明的优点是：采用上述方案所产生的有益效果在于本发明提供的方法不仅可以标识出依赖库新旧两个版本之间的所提供的包、类、方法差异，同时基于对当前应用代码所使用的旧版本依赖库方法分析，识别出依赖库版本升级到新版本时潜在风险项。当研发人员需要使用依赖库新版本特性，或者由于旧版本依赖库存在重大缺陷或安全漏洞需要将依赖库从旧版本升级到新版本时，可以使用本发明所提供的方法，就可以得到依赖库版本升级风险评估信息，减少了开发人员评估依赖库版本升级影响所花费的时间，降低了版本升级所带来的风险，最终提升了开发人员效率以及产品的稳定性。
附图说明
36.图1是本发明的java软件依赖库版本升级自动化风险评估方法的流程图；
37.图2是依赖库源代码类方法解析的流程图；
38.图3是旧版本类方法变更分析的流程图；
39.图4是应用源代码使用依赖库分析的流程图；
40.图5是升级风险分析的流程图。
具体实施方式
41.下面结合附图，对本发明的具体实施方式作进一步详细描述。以下用于说明本发明，但不用来限制本发明的范围。
42.如图1所示，本实施例中java软件依赖库版本升级自动化风险评估方法如下所述：
43.步骤1：从java依赖仓库中获取依赖库当前版本以及待升级版本java源代码。
44.本实施例中，所有依赖库存放在maven仓库中，系统基于依赖库的标识信息：groupid，artifactid和version等信息，从maven仓库中拉取依赖库新旧两个版本的源代码，将源代码保存到本地。
45.步骤2：对依赖库新旧版本源代码解析，获取依赖库中所包含的类方法列表，具体步骤如图2所示。
46.步骤2.1:获取依赖库信息，具体信息包括依赖库的标识信息，以及依赖库版本。
47.本实施例中依赖库信息包括：groupid，artifactid和version等信息，可以唯一确定一个依赖库。
48.步骤2.2:基于依赖库信息查询是否存在所指定的依赖库解析数据，如存在则进入步骤3，否则进入下一步骤。
49.本实施例中：使用groupid，artifactid以及version作为查询条件，查询依赖库解析数据库，判断该依赖库版本是否已经在其他过程中被解析过。因为groupid，artifactid以及version可以唯一的确定一个依赖库，如果在依赖库解析数据库中存在该依赖库的解析结果，则系统无需再次对该依赖库进行解析，可以直接使用依赖库解析结果。如果不存在解析结果信息，那么进入下一步对依赖库进行进行解析。
50.步骤2.3:对依赖库源代码进行解析，得到依赖库所有的包，类，方法以及方法签名等信息。
51.本实施例中基于javaparser对依赖库源代码进行解析，得到该依赖库的抽象语法树。基于得到的抽象语法树，从中提取该依赖库的所有方法信息，包括了该方法所属的包名，类名，返回结果类型，输入的参数信息(包括输入参数类型，顺序等)
52.步骤2.4:将依赖库解析结果保存数据库。
53.本实施例中将步骤2.3中解析的结果信息(groupid，artifactid，version，pacakge，method，return，param等)存储在数据库中。
54.步骤3：基于步骤2得到的依赖库类方法列表，对比新旧两个版本，识别旧版本中类方法变更信息，例如删除的类方法，废弃的类方法等，如图3所示：
55.步骤3.1:获取待对比的新依赖库信息、旧依赖库信息。
56.本实施例中新依赖库信息、旧依赖库信息包括：groupid，artifactid和version等信息。
57.步骤3.2:查询是否存在该依赖库新旧两个版本的变更信息，如存在则进入步骤4，
否则进入下一步骤。
58.本实施例中使用旧依赖库信息：oldgroupid，oldartifactid和oldversion以及新依赖库信息：newgroupid，newartifactid和newversion作为组合条件查询数据，判断是否存在两个版本依赖库的变更分析结果。如果存在变更结果，则无需再次进行分析，可直接进入步骤4，否则需要分析新旧两个版本的依赖库变更信息，进入下一步骤。
59.步骤3.3:获取依赖库旧版本所有方法，依次遍历所有方法与依赖库新版本解析结果进行对比，判断该方法是否在变更，并将变更信息保存数据库。
60.本实施例中利用oldgroupid，oldartifactid和oldversion查询到旧版本依赖库中所有的方法信息，建立待分析方法列表。利用newgroupid，newartifactid和newversion查询到新版本依赖库中所有的方法信息，建立对比方法列表。进一步依次的遍历待分析方法列表，并与新版本对比方法列表做对比分析，判断该方法是否存在于有变更。具体判断标准如下：在分析方法列表中是否存在与待分析方法所属的包名，类名，返回信息以及参数信息完全相同的方法，如果不存在则记录一条变更方法变更信息表示该方法已经在新版本中不存在，并且将该信息保存到数据库中。如果存在则继续分析下一个待分析方法直到所有待分析方法分析完成。
61.步骤4：对使用依赖库的应用源代码解析，获取应用源代码中实际使用的依赖库类方法，如图4所示。
62.步骤4.1:获取使用依赖库的应用源代码。
63.本实施例中，应用源代码存在git仓库中，并且存在多个分支，本实施例中直接拉取应用在git仓库中的master分支信息作为应用源代码分析的基础。
64.步骤4.2:查询是否存在该应用方法调用链路的解析，如存在则进入步骤5，否则进入下一步。
65.本实施例中利用应用名称，应用git仓库地址以及旧版本依赖库信息查询应用方法调用链路解析数据库，判断是否存在该应用与该依赖库的调用链路解析，如果存在则直接进入步骤5。否则进入下一步骤进行应用调用链路解析。
66.步骤4.3:对该应用源代码进行源代码解析，获取该应用所有使用到的包，类，方法以及方法签名信息，并保存数据库。
67.本实施例中使用javaparser对应用源代码进行解析，得到该应用的抽象语法树。基于得到的抽象语法树进一步分析，获取应用方法调用链路分析信息，包括应用名，包名，类名，方法名，依赖的依赖库信息，包括依赖库信息groupid，artifactid，version和依赖方法信息包括了该方法所属的包名，类名，返回结果类型，输入的参数等信息，并将该信息保存到数据库中。
68.步骤5：对比步骤3和步骤4中旧版本依赖库中变更的类方法和应用中实际使用的依赖库类方法，如发现应用中实际使用的依赖库方法发生了变化，则记录一条风险，如图5所示：
69.步骤5.1:获取应用信息，依赖库新旧版本信息。
70.本实施例中应用信息包括应用名和git仓库地址信息，依赖库信息包括groupid，artifactid，version等
71.步骤5.2:查询是否存在依赖库版本升级风险信息，如存在则进入步骤6，否则进入
下一步骤。
72.本实施例中基于应用名，应用地址仓库，旧依赖库信息，新依赖库信息查询依赖库版本升级风险数据库，判断是否存在版本升级风险信息，如存在则直接进入步骤6。否则进入下一步进行升级风险分析。
73.步骤5.3:获取应用使用的依赖库所有方法信息，依次遍历所有依赖方法，并与依赖库变更信息作对比，如果应用使用了变更的方法，则记录一条风险信息。
74.本实施例中首先基于应用名称，git仓库地址信息以及旧版本依赖库信息，查询应用所使用的旧版本依赖库中方法信息，建立应用依赖方法列表。遍历所有的依赖方法，对所有的依赖方法执行风险判断，具体判断方式如下：从应用依赖方法列表中选择一个待分析的方法，使用该方法信息，包括groupid，artifactid，version和依赖方法信息包括了该方法所属的包名，类名，返回结果类型，输入的参数等信息，并结合新版本依赖库信息包括groupid，artifactid，version等，查询依赖库变更数据库，如果找到对应的变更信息则记录一条风险信息，包括应用名称，git仓库地址，老版本依赖库，新版本数据库，升级存在的风险方法等。如果没有找到对应的变更信息则继续选择应用依赖方法列表中的下一条进行分析，直到所有的方法分析完成。
75.步骤6：分析完成后将风险评估结果推送给对应的研发人员本实施例中从版本升级风险数据库中获取该应用从旧版本升级到新版本所有的风险信息，并通过企业内部消息系统将风险评估结果推送到负责该应用的研发人员，信息包括应用名称，git仓库地址，老版本依赖库，新版本数据库，升级存在的风险方法等，供研发人员判断是否升级到新版本依赖库以及如何升级到新版本依赖库。
76.本说明书实施例所述的内容仅仅是对发明构思的实现形式的列举，本发明的保护范围不应当被视为仅限于实施例所陈述的具体形式，本发明的保护范围也及于本领域技术人员根据本发明构思所能够想到的等同技术手段。