一种Java代码检测方法及装置与流程

本申请涉及软件开发技术领域，尤其涉及一种Java代码检测方法及装置。

背景技术：

在软件开发过程中，对于编写好的Java代码通常可以使用代码混淆工具(如proguard工具)对代码进行混淆。

混淆后的Java代码相对于混淆前的Java代码可以具有减少代码量、增加代码被破译的难度等优点。

然而，使用代码混淆工具后，经常会发送混淆后的Java代码功能与混淆前的Java代码功能不一致，甚至混淆后代码功能不可用的情况。

现有技术中，针对混淆后代码功能不一致的情况，通常会对混淆后的代码进行测试。测试过程中需要用到测试用例。由于导致混淆后代码功能不一致的原因多种多样，一般一个测试用例只能发现一种原因，所以需要编写尽可能多的测试用例。然而，编写测试用例需要很高的成本，基于成本考虑无法无限制地增加测试用例，因此基于测试用例的测试无法覆盖所有混淆后代码功能不一致的情况，导致存在不能及时发现混淆后java代码功能不一致的问题。

技术实现要素：

本申请提供的一种Java代码检测方法及装置，以解决现有技术中存在不能及时发现混淆后Java代码功能不一致的问题。

根据本申请实施例提供的一种Java代码检测方法，所述方法包括：

接收待检测的源代码；

分析源代码的函数调用关系，得出所述源代码的所有子结构代码；

获取所述源代码以及每一个子结构代码调用的jar包集合；

判断所获取的各个jar包集合是否存在冲突jar包；

在所述获取的各个jar包集合存在冲突jar包的情况下，输出Java代码存在混淆后功能不一致的检测结果。

可选的，所述获取所述源代码以及每一个子结构代码调用的jar包集合，具体包括：

读取所述源代码的配置文件中记录的所述源代码调用的jar包；

读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包；

将所述源代码调用的jar包以及所述每一个子结构代码调用的jar包，存入对应的jar包集合。

可选的，所述读取所述源代码的配置文件中记录的所述源代码调用的jar包，具体包括：

读取所述源代码的配置文件中记录的所述源代码调用的jar包的名称以及版本号；

所述读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包，具体包括：

读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包的名称以及版本号。

可选的，所述配置文件包括pom文件或者build.gradle文件。

可选的，所述判断所获取的各个jar包集合是否存在冲突jar包，具体包括：

获取所获取的各个jar包集合中jar包的名称以及版本号；

判断是否存在相同名称、不同版本号的jar包；

相应地，所述在所述获取的各个jar包集合存在冲突jar包的情况下，输出Java代码存在混淆后功能不一致的检测结果，具体包括：

在存在相同名称、不同版本号的jar包的情况下，将其加入到冲突jar包集合；

输出所述冲突jar包集合以及Java代码存在混淆后功能不一致的检测结果。

根据本申请实施例提供的一种Java代码检测装置，所述装置包括：

接收单元，接收待检测的源代码；

分析单元，分析源代码的函数调用关系，得出所述源代码的所有子结构代码；

获取单元，获取所述源代码以及每一个子结构代码调用的jar包集合；

判断单元，判断所获取的各个jar包集合是否存在冲突jar包；

输出单元，在所述获取的各个jar包集合存在冲突jar包的情况下，输出Java代码存在混淆后功能不一致的检测结果。

可选的，所述获取单元，具体包括：

第一读取子单元，读取所述源代码的配置文件中记录的所述源代码调用的jar包；

第二读取子单元，读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包；

存储子单元，将所述源代码调用的jar包以及所述每一个子结构代码调用的jar包，存入对应的jar包集合。

可选的，所述第一读取子单元，具体包括：

读取所述源代码的配置文件中记录的所述源代码调用的jar包的名称以及版本号；

所述第二读取子单元，具体包括：

读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包的名称以及版本号。

可选的，所述配置文件包括pom文件或者build.gradle文件。

可选的，所述判断单元，具体包括：

获取子单元，获取所获取的各个jar包集合中jar包的名称以及版本号；

判断子单元，判断是否存在相同名称、不同版本号的jar包；

相应地，所述输出单元，具体包括：

存储子单元，在存在相同名称、不同版本号的jar包的情况下，将其加入到冲突jar包集合；

输出子单元，输出所述冲突jar包集合以及Java代码存在混淆后功能不一致的检测结果。

本申请实施例中，java代码混淆后不一致的原因是由于调用相同jar包的版本号存在不一致；所以通过分析源代码的所有子结构代码，从而获取所述源代码和所有子结构代码调用的jar包集合；在所述获取的各个jar包集合存在冲突jar包的情况下，可以得出Java代码存在混淆后功能不一致的检测结果。如此，无需通过编写测试用例，仅通过扫描混淆前的源代码既可以提前发现使用混淆工具后出现的功能不一致的情况。

附图说明

图1是本申请提供的代码结构的示意图；

图2是本申请一实施例提供的Java代码检测方法的流程图；

图3是图2中步骤130的具体步骤的流程图；

图4是本申请提供的Java代码检测装置所在设备的一种硬件结构图；

图5是本申请一实施例提供的Java代码检测装置的模块示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例可以应用在对Java代码进行测试的测试客户端。所述测试客户端可以是软件上的测试程序。

所述测试客户端也可以是指软硬结合的客户端，例如安装了测试程序的设备。

如今随着应用功能的越来越多，越来越全，满足了用户需求的同时，对于编程人员来说，则意味着越来越多的代码，为了方便区分不同的代码所实现的功能，如今普遍采用的是分层架构也称为多层架构(例如三层架构)的方式来编写代码。分层架构可以将大量代码按照不同功能进行区分，不同层的代码各司其职，不会相互影响；便于后期进行维护、扩展功能。

如此，对于一个完整的Java代码来说，其是由多个实现不同功能的子结构代码组成的。所述子结构代码一般会被封装为一个函数例如addA()；不同子结构代码之间可以通过调用函数来传递数据。对于函数在业内还可以称之为类、方法等。

如前所述，代码混淆工具可以对Java代码进行混淆，并且混淆后的Java代码可以具备减少代码量、优化代码结构、增加代码被破译的难度等优点。

举例说明，如图1所示的一个购物应用的代码结构示意图，该应用的可以具有6大功能：

登录功能、显示商品列表功能、外卖点餐功能、购物车功能、订单功能以及支付功能。

对应的，该购物应用的Java代码可以分为如下5个子结构代码：

1、用于实现登录功能的登录子结构代码，封装为函数Login()；

2、用于实现显示商品列表功能的商品子结构代码，封装为函数Shop()；

3、用于实现购物车功能的购物车子结构代码，封装为函数ShoppingCart()；

4、用于实现订单功能的订单子结构代码，封装为函数Order()；

5、用于实现支付功能的支付子结构代码，封装为函数Pay()。

在用户使用该购物应用直到完成支付的整个过程如下：

用户打开应用，首先调用函数Login()，用于登录用户账户。具体地，需要输入账户名和密码，所述账户名、密码可以是用户手动输入的，也可以是直接获取保存在本地的账户名、密码。

在登录成功后，则调用函数Shop()，来显示商品列表；用户浏览商品可以将想要购买的商品加入购物车；

用户点击购物车，则调用函数ShoppingCart()，显示购物车内添加的商品；

用户点击提交订单，则调用函数Order()，生成待支付的订单；

用户点击支付，则调用函数Pay()，用于供用户进行支付操作。

如此，在支付成功后，一次购物过程完成。

代码混淆工具在混淆代码时，可以通过分析Java代码中函数调用关系，对于没有被调用的函数，通常意味着该函数对应的子结构代码实现的功能并没有被用到。例如老功能被新功能取代后，则老功能对应的子结构代码封装的函数就不会被调用了，可以将没有被调用的代码删除，从而实现减少代码量。在图1中，还存在有一个函数Food()，所述Food()为用于实现外卖点餐的功能，由于以前该功能推出后，用户反映不好，所以后来又取消了该功能，所以该函数Food()没有被调用。假设该购物应用的Java代码经过代码混淆工具进行代码混淆后，会将函数Food()的子结构代码去除，从而减少代码量。

代码混淆工具在混淆代码时，还可以混淆函数名和变量名，从而起到增加代码被破译的难度。例如，将图1中用于实现支付功能的函数Pay()和用于登录功能的函数Login()的函数名互换；则代码混淆后，用于实现支付功能的函数名变为Login()，用于实现登录功能的函数名变为Pay()，这样对于想要破译代码的人来说，阅读代码的难度就会增加很多，从而增加了代码被破译的难度。

然而，使用代码混淆工具后，经常会发送混淆后的Java代码功能与混淆前的Java代码功能不一致，甚至混淆后代码功能不可用的情况。

在Java中，可以允许用户使用别人已经编写好的函数，这些外部的函数就是以jar(Java ARchive)包的形式导入的。在调用jar包后，就可以使用该jar包所提供的函数。

一般的，导致混淆后代码功能不一致的原因是由于不同代码调用了相同名称，但版本号不同的jar包，而不同版本号可能实现的功能不完全相同。

代码混淆工具主要是根据不同代码调用的jar包做代码分析，进而进行代码混淆，而代码混淆工具无法识别相同名词版本号不同的情况下，这样就容易发生混淆后代码功能不一致的情况。例如，存在两个子结构代码分别调用名称相同、版本号不同(存在功能差异)的两个jar包，对应代码混淆工具来说，这两个jar包是相同的，从而会删除其中一个jar包，将原本的两个子结构代码同时调用剩下的一个jar包，如此会导致其中一个子结构代码的功能发送改变。

如前所述，针对混淆后代码功能不一致的情况，通常会对混淆后的代码进行测试。测试过程中需要用到测试用例。由于相同名称、版本号不同的jar包多种多样，因此导致混淆后代码功能不一致的情况也多种多样。一般的，一个测试用例只能覆盖一种情况，所以需要编写尽可能多的测试用例。然而，编写测试用例需要很高的成本，基于成本考虑无法无限制地增加测试用例，因此基于测试用例的测试无法覆盖所有混淆后代码功能不一致的情况，导致存在不能及时发现混淆后java代码功能不一致的问题。

为了解决上述问题，请参见图2，为本申请一实施例提供的Java代码检测方法的流程图，所述方法包括以下步骤：

步骤110：接收待检测的源代码。

本实施例中，所述源代码可以是未经过代码混淆的Java代码。

步骤120：分析源代码的函数调用关系，得出所述源代码的所有子结构代码。

本实施例中，测试客户端在接收到待测试的源代码后，可以分析所述源代码的函数调用关系，从而得出所述源代码的子结构代码。

一般的，分析函数调用关系都是从最后一层开始分析的。依旧如图1所示，通过分析源代码中的函数调用关系：

函数Pay()调用了函数Order()；

而函数Order()调用了函数ShoppingCart()；

函数ShoppingCart()调用了函数Shop()；

函数Shop()调用了函数Login()。

因此，存在有5个子结构代码，分别为：

函数Pay()对应的子结构代码；以下简称为A代码；

函数Order()对应的子结构代码；以下简称为B代码；

函数ShoppingCart()对应的子结构代码；以下简称为C代码；

函数Shop()对应的子结构代码；以下简称为D代码；

函数Login()对应的子结构代码；以下简称为E代码。

步骤130：获取所述源代码以及每一个子结构代码调用的jar包集合。

本实施例中，测试客户端在根据源代码的函数调用关系，得出所述源代码的所有子结构代码之后，可以获取所述源代码以及每一个子结构代码调用的jar包集合。

具体地，所述步骤130，如图3所示可以包括如下步骤：

步骤131：读取所述源代码的配置文件中记录的所述源代码调用的jar包；

具体地，读取所述源代码的配置文件中记录的所述源代码调用的jar包的名称以及版本号。

步骤132：读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包；

具体地，读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包的名称以及版本号。

步骤133：将所述源代码调用的jar包以及所述每一个子结构代码调用的jar包，存入对应的jar包集合。

在Java开发中，通常可以将需要调用的jar包统一配置到配置文件中。

在实际应用中，为了方便管理不同的配置文件，通常需要应用例如maven工具、gradle工具等服务于Java的项目构建工具。

使用不同的工具生成的配置文件一般存在差异，使用maven工具生成的配置文件为pom文件；使用gradle工具生成的配置文件为build.gradle文件。

以下以pom文件为例介绍获取代码调用的jar包的过程：

如上所示为pom文件中配置的一个jar包。在pom文件中，jar包名称对应的字段为“groupId”以及“artifactId”；jar包版本号对应的字段为“version”。因此，该jar包的名称为：group.a-artifact.b；

该jar包的版本号为：1.0。

依然沿用上一步骤中的例子：

假设读取源代码的配置文件中记录的所述源代码调用的jar包为：

名称：group.1-artifact.1；版本号：1.0；

名称：group.2-artifact.2；版本号：1.0；

名称：group.3-artifact.3；版本号：1.0；

名称：group.4-artifact.4；版本号：1.0；

名称：group.5-artifact.5；版本号：1.0；

读取A代码的配置文件中记录的所述源代码调用的jar包为：

名称：group.1-artifact.1；版本号：1.0；

读取B代码的配置文件中记录的所述源代码调用的jar包为：

名称：group.2-artifact.2；版本号：2.0；

读取C代码的配置文件中记录的所述源代码调用的jar包为：

名称：group.3-artifact.3；版本号：1.0；

读取D代码的配置文件中记录的所述源代码调用的jar包为：

名称：group.4-artifact.4；版本号：2.0；

读取E代码的配置文件中记录的所述源代码调用的jar包为：

名称：group.5-artifact.5；版本号：1.0；

步骤140：判断所获取的各个jar包集合是否存在冲突jar包。

本实施例中，所述冲突可以是指不同jar包集合中存在相同名称、不同版本号的jar包。

如此，所述步骤130，具体可以包括：

获取所获取的各个jar包集合中jar包的名称以及版本号；

判断是否存在相同名称、不同版本号的jar包。

沿用上一步骤中的例子，即：

源代码调用的jar包集合为Y{名称：group.1-artifact.1；版本号：1.0；

名称：group.2-artifact.2；版本号：1.0；

名称：group.3-artifact.3；版本号：1.0；

名称：group.4-artifact.4；版本号：1.0；

名称：group.5-artifact.5；版本号：1.0}

A代码调用的jar包集合为X1{名称：group.1-artifact.1；版本号：1.0}

B代码调用的jar包集合为X2{名称：group.2-artifact.2；版本号：2.0}

C代码调用的jar包集合为X3{名称：group.3-artifact.3；版本号：1.0}

D代码调用的jar包集合为X4{名称：group.4-artifact.4；版本号：2.0}

E代码调用的jar包集合为X5{名称：group.5-artifact.5；版本号：1.0}

判断jar包集合Y和jar包集合X1，由于存在名称group.1-artifact.1相同的jar包，并且版本号1.0也相同，因此这两个jar包集合不存在冲突jar包。

判断jar包集合Y和jar包集合X2，由于存在名称group.2-artifact.2相同的jar包，并且版本号不同(一个是1.0一个是2.0)，因此这两个jar包集合存在冲突jar包。

判断jar包集合Y和jar包集合X3，由于存在名称group.3-artifact.3相同的jar包，并且版本号1.0也相同，因此这两个jar包集合不存在冲突jar包。

判断jar包集合Y和jar包集合X4，由于存在名称group.4-artifact.4相同的jar包，并且版本号不同(一个是1.0一个是2.0)，因此这两个jar包集合存在冲突jar包。

判断jar包集合Y和jar包集合X5，由于存在名称group.5-artifact.5相同的jar包，并且版本号1.0也相同，因此这两个jar包集合不存在冲突jar包。

在jar包集合X1到X5之间，由于没有存在名称相同的jar包，因此都不存在冲突jar包。

步骤150：在所述获取的各个jar包集合存在冲突jar包的情况下，输出Java代码存在混淆后功能不一致的检测结果。

本实施例中，继续沿用上一步骤中的例子，由于jar包集合Y和jar包集合X2存在冲突jar包，以及jar包集合Y和jar包集合X4存在冲突jar包；因此，可以输出Java代码存在混淆后功能不一致的检测结果。

在另一个实施例中，所述步骤140，具体可以包括如下步骤：

在存在相同名称、不同版本号的jar包的情况下，将其加入到冲突jar包集合；

输出所述冲突jar包集合以及Java代码存在混淆后功能不一致的检测结果。

本实施例中，可以将jar包集合Y和jar包集合X2存在的冲突jar包：

名称：group.1-artifact.1；版本号：1.0和名称：group.1-artifact.1；版本号：2.0；

以及jar包集合Y和jar包集合X4存在的冲突jar包：

名称：group.4-artifact.4；版本号：1.0和名称：group.4-artifact.4；版本号：2.0；

写入到冲突jar包集合中{名称：group.1-artifact.1；版本号：1.0；

名称：group.1-artifact.1；版本号：2.0；

名称：group.4-artifact.4；版本号：1.0；

名称：group.4-artifact.4；版本号：2.0}

最后，输出该冲突jar包集合，以及Java代码存在混淆后功能不一致的检测结果。

通过本实施例，java代码混淆后不一致的原因是由于调用相同jar包的版本号存在不一致；所以通过分析源代码的所有子结构代码，从而获取所述源代码和所有子结构代码调用的jar包集合；在所述获取的各个jar包集合存在冲突jar包的情况下，可以得出Java代码存在混淆后功能不一致的检测结果。如此，无需通过编写测试用例，仅通过扫描混淆前的源代码既可以发现使用混淆工具后出现的功能不一致的情况。

与前述Java代码检测方法实施例相对应，本申请还提供了一种Java代码检测装置的实施例。

本申请Java代码检测装置的实施例可以应用在测试客户端。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请Java代码检测装置所在设备的一种硬件结构图，除了图4所示的处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该Java代码检测实际功能，还可以包括其他硬件，对此不再赘述。

参见图5，为本申请一实施例提供的Java代码检测装置的模块图，所述装置包括：接收单元310、分析单元320、获取单元330、判断单元340以及输出单元350。

其中，接收单元310，接收待检测的源代码；

分析单元320，分析源代码的函数调用关系，得出所述源代码的所有子结构代码；

获取单元330，获取所述源代码以及每一个子结构代码调用的jar包集合；

判断单元340，判断所获取的各个jar包集合是否存在冲突jar包；

输出单元350，在所述获取的各个jar包集合存在冲突jar包的情况下，输出Java代码存在混淆后功能不一致的检测结果。

在一个可选的实施方式中：

所述获取单元330，具体包括：

第一读取子单元，读取所述源代码的配置文件中记录的所述源代码调用的jar包；

第二读取子单元，读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包；

存储子单元，将所述源代码调用的jar包以及所述每一个子结构代码调用的jar包，存入对应的jar包集合。

在一个可选的实施方式中：

所述第一读取子单元，具体包括：

读取所述源代码的配置文件中记录的所述源代码调用的jar包的名称以及版本号；

所述第二读取子单元，具体包括：

读取所述子结构代码的配置文件中记录的所述子结构代码调用的jar包的名称以及版本号。

在一个可选的实施方式中：

所述配置文件包括pom文件或者build.gradle文件。

在一个可选的实施方式中：

所述判断单元340，具体包括：

获取子单元，获取所获取的各个jar包集合中jar包的名称以及版本号；

判断子单元，判断是否存在相同名称、不同版本号的jar包；

相应地，所述输出单元350，具体包括：

存储子单元，在存在相同名称、不同版本号的jar包的情况下，将其加入到冲突jar包集合；

输出子单元，输出所述冲突jar包集合以及Java代码存在混淆后功能不一致的检测结果。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。