CN107402879A - 确定应用之间调用关系的方法及装置 - Google Patents

Abstract

本申请实施例公开了一种确定应用之间调用关系的方法及装置，以解决现有技术较难对大量应用之间的调用关系进行确定的问题。所述方法包括：将待测应用分到各个分组；对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则；根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

Description

确定应用之间调用关系的方法及装置

技术领域

本申请涉及应用测试技术，特别涉及一种确定应用之间调用关系的方法及装置。

背景技术

目前，在终端(如：手机)上安装的应用(Application，APP)之间可以通过各种方式(如：消息)进行相互调用，为此，业内存在确定各应用间的调用关系的需求。

现有技术中，可以通过如下方式确定应用A和应用B之间是否存在调用关系：将应用A和应用B安装于同一个终端上，在所述终端上开启应用A的进程并关闭除上述应用A之外的所有应用(包括应用B)的进程，此后，可以通过监测该终端的进程，若监测到应用B的进程开启，则确定存在应用A调用应用B的调用关系，否则，确定不存在应用A调用应用B的调用关系。也就是说，现有技术可以通过将一定数量的应用安装于同一个终端上，并逐一在该终端上开启某应用的进程并关闭除该应用之外的其他应用的进程，最终，通过监测该终端的进程变化，来确定各应用间是否存在调用关系。

上述现有技术中，由于终端的硬件能力有限，同一终端上可以安装的应用的数量有限，因而较难实现对大量应用之间的调用关系的确定。

发明内容

本申请实施例的目的是提供一种确定应用之间调用关系的方法及装置，以解决现有技术较难对大量应用之间的调用关系进行确定的问题。

为解决上述技术问题，本申请各实施例提供的确定应用之间调用关系的方法及装置是这样实现的：

一种确定应用之间调用关系的方法，包括：

将待测应用分到各个分组；

对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则；

根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

一种确定应用之间调用关系的装置，包括：

分组单元，用于将待测应用分到各个分组；

第一确定单元，用于对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则；

第二确定单元，用于根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

由以上本申请各实施例提供的技术方案可见，本申请实施例通过将待测应用分到各个分组中，对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则，最终，根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。可见，上述过程可以通过对大量待测应用进行分组，并利用同一分组的待测应用之间的调用规则来确定不同分组的待测应用之间存在的调用关系，从而实现了对大量待测应用之间存在的调用关系的确定。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请示例性的硬件架构图；

图2为本申请一实施例提供的确定应用之间调用关系的方法的流程图；

图3为本申请一实施例中确定属于同一分组的应用间调用关系的示意图；

图4为本申请一实施例中确定属于不同分组的应用间调用关系的示意图；

图5为本申请一实施例提供的测试控制装置的结构示意图；

图6为本申请一实施例提供的确定应用之间调用关系的装置的模块示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

随着智能手机功能的不断增加，手机上安装的用于实现不同功能的应用(Application，APP)也变得越来越多。在用户对这些APP使用的过程中，可能会通过该APP(调用方APP)调用其他APP(被调用方APP)，比如，该APP的某些功能可能会需要通过调用其他APP来协助实现。

所述应用之间的调用，一般可以是指某一应用通过向操作系统发送特定的消息，以使得操作系统根据接收到的所述消息，启动或者唤醒其他的应用。比如，用户通过点击应用A的图标以触发操作系统启动应用A，在应用A启动时，应用A会向操作系统发送用于启动应用B的消息，以使得操作系统根据该消息启动应用B。

例如，当用户期望通过“微博APP”拍摄照片并将拍摄的照片以微博的形式发出时，仅通过微博APP无法拍摄照片，因而此时需要微博APP调用相机APP来拍摄照片。还比如，用户在浏览器上搜索到一部视频，用户期望观看该视频，此时浏览器会调用手机上安装的视频播放APP，以通过该视频播放APP播放该视频。

需要说明的是，一方面，考虑到应用之间的调用往往会耗费智能终端的大量的处理资源，另一方面，考虑到某些应用之间发生的调用可能是不必要的，因此可以对不必要的调用进行禁止或阻隔以避免处理资源浪费。本申请旨在确定各应用之间的调用关系及相应的调用规则，在某些具体应用中，本申请可用来校验对应用之间的相互调用进行禁止或阻隔的效果。

为解决现有技术存在的较难对大量应用之间的调用关系进行确定的问题，本申请实施例提供一种确定应用之间调用关系的方案。

图1为本申请示例性的硬件架构图。示例性地，该架构可以包括测试控制装置10(如：个人电脑或服务器)及若干与该测试控制装置10通信的终端20a、20b(如：手机)，其中，所述测试控制装置上可以安装相应的测试软件。上述测试控制装置10可以从互联网30上下载待确定调用关系的若干应用的安装文件，并将这些应用的安装文件安装于所述终端20a、20b上。

图2为本申请一实施例提供的确定应用之间调用关系的方法的流程，所述方法的执行主体可以是上述测试控制装置，该方法包括如下步骤：

步骤S101：将若干待测应用分到各个分组。

本申请实施例中，假设需要对n个待测应用之间的调用关系进行确定，且由于n的值较大(如：n＝500)，导致这n个待测应用无法同时安装于同一终端上。鉴于此，可以预先安装一定的规则将上述n个待测应用分到各个分组中，使得每个分组中包含的待测应用可以被安装于同一个终端上的，如：将500个待测应用分到20个分组，每个分组包含25个待测应用。

关于待测应用，一般可以为互联网上可以被下载的任意一个应用(包括免费应用或收费应用)。本申请实施例中，将若干待测应用分到各个分组之前，所述方法还可以包括如下步骤：根据预设排名区间，将处于所述预设排名区间内的应用确定为待测应用。上述预设排名可以是指应用在互联网上的热度排名，或人为定义的其他方式的排名，所述热度排名可以包括：按照被下载次数从大到小的排名、按照被用户评论数从大到小的排名、按照使用应用的用户数从大到小的排名等。基于互联网上对应用的排名情况，可以设定某个预设排名区间，并将处于该预设排名区间内的应用确定为待测应用。相应地，所述预设排名区间可以为：与应用的下载量排名对应的区间、或与使用应用的用户数排名对应的区间、或与应用的评论数排名对应的区间等。例如：设定的预设排名区间是：[50，1000]，则最终将排名处于50到1000之间的应用确定为待测应用，并确定上述各个待测应用之间存在的调用关系。通过利用互联网上对应用的排名情况，来确定需要确定调用关系的待测应用的范围，一方面，可以有选择性地针对特定范围的大量应用之间的调用关系进行确定；另一方面，由于用户只需输入上述预设排名区间，无需输入大量与待测应用对应的标识(如：应用名称)，从而可以提高确定应用间调用关系的效率。

本申请实施例中，上述步骤S101可以包括但不限于如下方式：

①将若干待测应用随机分到各个分组。例如，待测应用的总数是1000，欲分到50个分组，则可以将上述1000个待测应用以随机划分的方式分到上述50个分组中，每个分组20个待测应用。

②按照各待测应用的热度排序，将若干待测应用分到各个分组。例如，待测应用为互联网上热度排序在50～1050的1000个应用，且欲分到50个分组，则分组1可包含：热度排序在50～70的20个应用，分组2可包含：热度排序在70～90的20个应用，分组2可包含：热度排序在90～110的20个应用，以此类推。

③将采用相同的SDK(Software Development Kit，软件开发工具包)进行开发的待测应用分到同一分组。例如，将采用SDK1开发的100个待测应用分到分组1～分组5，将采用SDK2开发的40个待测应用分到分组6～分组7，等等。一般采用相同SDK开发的待测应用之间具有相互调用关系的可能性较高，故，将采用相同SDK开发的待测应用分到同一分组，使得测试过程更加准确和高效。

值得一提的是，上述分组的个数及每个分组包含的待测应用数量均不受限制，可以根据实际需要进行调整。另外，在分组过程中可能会出现这样一种情况：待测应用无法被均分到各个分组中。例如：待测应用总共999个，若分组个数是50个，则无法均分。此时，可以通过将已分到某一分组中的待测应用补到另一分组中，来解决无法均分的问题。在上述例子中，第50个分组只能分到19个待测应用，此时可以将已分到前49个分组中的任意一个分组(如：第3个分组)中的某个待测应用补全到该第50个分组中。也就是说，在分到各个分组的待测应用的数量不相等时，可以容许将同一待测应用分到不同的两个分组中。通过上述分配规则，可以在任何情况下，使得每个分组中包含的待测应用的数量都是相等的，从而在测试过程中，因为每个终端上安装的应用数量都是一致的，则可以采用基本相同的控制代码来实现测试，上述控制代码可以是在测试控制装置上安装的软件代码，如：用以将某一个待测应用的进程开启，将其余19个待测应用的进程关闭的软件代码。可见，通过确保每个分组中的待测应用的数量相等，可以避免修改控制代码，使得测试效率更高。

本申请实施例中，在分组规则的定义中可以包括：分组个数、分组方式、在无法均分时是否允许进行补全、补全的规则(随机补全或按照热度排名进行补全)等，从而上述测试控制装置可以按照上述分组规则的定义进行待测应用进行分组。上述分组规则的定义的示例如下：

本申请实施例中，通常，为便于确定同一分组中的待测应用之间存在的调用关系，需要将属于同一分组的待测应用被安装于同一终端上。

在该步骤S101中，还可以包括下载待测应用的安装文件的步骤。本申请实施例中，上述测试控制装置(如PC)可以从互联网上下载待测应用的安装文件。举例来说，若待测应用为互联网上的某种排名50到1000的应用，则上述测试控制装置可以通过下载引擎调用下载范围的定义，来获取上述待测应用的安装文件，上述下载范围的定义可以包括：预设排名区间、URL获取文件以及存储目录。上述下载范围的定义可以通过JSON字符串进行描述，示例如下：

上述URL获取文件：“top_1000.csv”用以存储区间[50,1000]内的待测应用的下载地址。

在下载到待测应用的安装文件之后，便可以将这些安装文件推送到指定终端上进行安装，以完成对待测应用间存在的调用关系的确定。一般地，根据终端数量，对待测应用进行安装的过程可以大致分为如下两种情况：

1、终端的数量足够(即终端数量大于或等于分组的数量)，则可以将在同一时间，将各个分组包含的待测应用安装于各个终端上。例如，分组数量为50，终端数量为100，则可以从100个终端中任意选取50个，将上述50个分组包含的待测应用分别安装到选取的50个终端上。

2、终端的数量不足(即终端数量小于分组的数量)，则可以先将一部分的分组包含的待测应用安装于各个终端上，待上述一部分分组包含的待测应用测试完成之后(即下述步骤S103完成之后)，再将上述终端上的应用卸载，并将另一部分的分组包含的待测应用安装于上述各个终端上。例如，分组数量为50，终端数量为10，则可以先将分组1～10的待测应用安装于上述10个终端上进行测试，在上述分组1～10的待测应用间调用关系测试完成之后，再将上述10个终端上已安装的待测应用卸载，并将分组11～20的待测应用安装于上述10个终端上进行测试，依次类推，直至将所有分组的待测应用全部测试完成。

值得说明的是，在一种实施例中，可以先对待测应用进行分组，再获取各个分组中的待测应用的安装文件，最后根据分组的情况来完成待测应用的安装过程。在另一种实施例中，也可以先获取待测应用的安装文件，然后进行待测应用的分组，最后根据分组的情况来完成待测应用的安装过程。在又一实施例中，也可以省略上述待测应用的安装过程，假设已存在多个分别安装有一定数量的应用的终端，则可以在对待测应用进行分组之后，根据分组的情况，从已存在的终端中，相应挑选一个或多个与分组情况相匹配的终端，来完成测试。也就是说，关于将同一分组中的待测应用安装到同一终端上，可以不是本申请实施例所必需的步骤。

需述及的是，在本申请另一可行的实施例中，上述同一分组中的待测应用可以被安装于不同的终端上。例如，在确定第一分组中的20个应用之间的调用所采用的调用规则之前，可以将上述第一分组中的任意10个应用安装于终端20a上，将上述第一分组中的另外10个应用安装于终端20b上，并通过对上述终端20a、20b的进程监测，来确定上述第一分组中的20个应用之间的调用所采用的调用规则。

步骤S102：对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则。

本申请一实施例中，上述步骤S102中，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则的同时，还需确定与所述调用规则对应的调用关系。

本申请实施例中，为完成对应用间的调用关系和调用规则的确定，在上述步骤S101之后，上述步骤S102之前，所述方法还包括如下步骤：

步骤i：向终端发送用以将第二待测应用的进程开启、将第三待测应用的进程关闭的控制命令。

其中，所述第二待测应用和所述第三待测应用属于同一分组。需要说明的是，上述第三待测应用可以指的是一个或多个待测应用。例如，某终端上安装有APP1～APP20，若将APP1的进程开启，将APP2～APP20的进程关闭，则此过程中，APP1便是上述第二待测应用，APP2～APP20便是上述第三待测应用。

相应地，上述步骤S102可以具体包括：

步骤j：监测所述第三待测应用的进程是否开启；

步骤k：若监测到所述第三待测应用的进程开启，则确定存在所述第二待测应用调用所述第三待测应用的调用关系，并确定所述第二待测应用调用所述第三待测应用时采用的调用规则。

图3为本申请一示例性实施例中确定属于同一分组的应用间调用关系的示意图。如图3所示，举例而言，在终端20a上安装的待测应用21为APP1～APP20，则可以上述控制命令，将APP1(第二待测应用)的进程开启并将APP2～APP20(第三待测应用)的进程关闭，并通过监测在后续一段时长内，上述APP2～APP20的进程是否开启，来确定APP1(第二待测应用)与APP2～APP20(第三待测应用)是否存在调用关系。例如，监测到APP3(第三待测应用)的进程开启，则表明存在APP1(第二待测应用)通过某种调用规则来调用APP3(第三待测应用)的调用关系。接下来，还可以将将APP2的进程开启并将APP1、APP3～APP20的进程关闭，确定APP2与APP1、APP3～APP20之间存在的调用关系，等等。

本申请实施例中，上述步骤S102可以具体包括如下步骤：

首先，在存在第二待测应用调用第三待测应用的调用关系时，查找日志文件，获得所述第二待测应用调用所述第三待测应用时采用的调用消息；其中，所述第二待测应用和所述第三待测应用属于同一分组。

然后，将所述调用消息中包含的第一特征确定为所述调用规则。

如上所述，若两个待测应用之间存在调用关系，则调用方式可以包括消息方式或IPC(Inter-Process Communication，进程间通信)方式。其中，上述消息方式是指一个待测应用通过向操作系统发送相应的调用消息，来实现对另一个待测应用的调用。所述调用消息具体可以包括但不仅限于下述消息中的至少一种：

①一个待测应用向操作系统发出的用于调用另一个待测应用的广播消息；

②一个应用向操作系统发出的用于调用另一个待测应用的意图Intent消息；

③一个应用向操作系统发出的用于调用另一个待测应用的延迟意图PendingIntent消息。

由于作为调用者的待测应用每次向操作系统发送的上述消息(无论最终是否成功完成调用)，均会被操作系统记录并保存在系统日志(即上述日志文件)中，因而可以通过对系统日志的查询，获得作为调用者的待测应用发出的用于调用其他待测应用的调用消息，并将该调用消息中包括的第一特征确定为调用规则。

上述第一特征，一般是指表示“该调用消息能够实现‘调用其他待测应用’这一功能”的特征。比如，该第一特征可以是所述调用消息中包含的指定字符串，若除作为调用者的待测应用外的至少一个待测应用(被调用者)接收到该指定字符串，会启动或者被唤醒。例如，若APP1可以调用APP2，则APP1发送的调用消息中包含的第一特征可以是：“com.abc.startService”。本申请实施例中，上述第一特征，可以作为与被调用的待测应用对应的标识(如：被调用的待测应用的包名)，即，因为该标识的存在，使得操作系统可以根据该标识唯一确定到所需调用的待测应用。

一般地，APP1调用APP2的过程(发送调用消息)可以包括两种情况：

情况一(称为非隐式调用)，因用户对APP1的某种操作，而触发对APP2的调用过程；

情况二(称为隐式调用)，由APP1在后台静默地发送调用消息来实现对APP2的调用。

本申请实施例中，针对“非隐式调用”和“隐式调用”，可以分别设定相应的测试策略。具体地，在向终端发送所述控制命令(上述步骤i)之后，在监测所述第三待测应用的进程是否开启(上述步骤j)之前，所述方法还至少包括如下步骤之一：

步骤a：向终端发送与所述第二待测应用对应的Monkey操作命令，以确定与上述“非隐式调用”对应的调用关系。

上述操作命令可以是Monkey操作命令，Monkey作为手机操作系统(如：安卓)中的一个命令行工具，可以运行在模拟器里或上述终端中。Monkey可以根据实际需求向操作系统发送各种Monkey事件(如：模拟用户的按键输入、触摸屏输入、手势输入等)，来实现对上述应用之间的调用关系的测试。上述发送操作命令的过程可以持续一预设的时长，如：2分钟。由于Monkey是本领域所熟知的技术，故本文不再予以详述。

步骤b：将终端静置预设时长，以确定与上述“隐式调用”对应的调用关系。

在上述步骤a或b之后，可以通过监测终端上进程的变化，来确定某分组中的待测应用之间是否存在调用关系。当然，在可选的实施例中，可以在向所述终端发送与所述第一应用对应的操作命令后，再将所述终端静置预设时长。抑或，在将所述终端静置预设时长后，再向所述终端发送与所述第一应用对应的操作命令。

通过上述步骤S102，可以确定每个分组中的各个待测应用间存在的调用关系，以及与调用关系相对应的调用规则，并形成相应的结果数据，例如上述图3所示：

APP1调用APP3，调用规则：x；

APP4调用APP2，调用规则：y；

APP8调用APP5，调用规则：z。

步骤S103：根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

本申请一实施例中，上述步骤S103中，可根据所述调用规则及与所述调用规则对应的调用关系，确定属于不同分组的待测应用之间存在的调用关系。

在步骤S103中，可以利用上述步骤S102得到的结果数据，来进行聚合分析，以根据结果数据中的调用规则，来确定属于不同分组的待测应用之间的调用关系。通过这样的方式，就避免了将大量待测应用进行穷举式的分组，所带来的测试效率低下的问题(例如，在一次分组之后，分组1包含APP1～APP20，分组2包含APP21～APP40，为得到APP1和APP40之间是否存在调用关系，则一般还需要进行第二次分组，以将上述APP1和APP40分到同一个分组)。

本申请一实施例中，上述步骤S103可以具体包括：确定第一分组中的第一待测应用与第二分组中的第二待测应用之间存在调用关系，其中所述第一待测应用发起调用时所使用的调用规则与所述第二待测应用被调用时所使用的调用规则一致。

具体地，上述步骤S103可以具体包括但不限于下述过程：

若第一待测应用发起调用时所采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第一待测应用调用第三待测应用的调用关系；所述第二待测应用和所述第三待测应用属于同一分组，所述第一待测应用与所述第三待测应用属于不同分组；或，

若第一待测应用被其他待测应用调用时采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第二待测应用调用所述第一待测应用的调用关系。

图4为本申请一示例性实施例中确定属于不同分组的应用间调用关系的示意图。如图4所示，继续举例说明，假设分组1中包含的待测应用21是：APP1～APP20，分组2中包含的待测应用22是：APP21～APP40。通过将上述待测应用21：APP1～APP20安装于终端20a上，将上述待测应用22：APP21～APP40安装于终端20b上，根据上述步骤S103介绍的过程，可以确定APP1～APP20之间存在的调用关系和相应的调用规则，例如：

APP1调用APP3，调用规则：x；

APP4调用APP2，调用规则：y；

APP8调用APP5，调用规则：z。

……

以及APP21～APP40之间存在的调用关系和相应的调用规则。例如：

APP22调用APP23，调用规则：m；

APP34调用APP21，调用规则：x；

APP28采用了调用规则：z，未成功调用任何应用。

……

上述调用规则x、y、z、m例如是：com.abc.startService、com.fdfr.startService等。

在上述分组1中，若APP1(第二待测应用)调用APP3(第三待测应用)，调用规则是：x；在上述分组2中，若APP34(第一待测应用)调用APP21，调用规则也是：x。由于上述调用规则一致，则判定APP1(第二待测应用)也可以通过上述调用规则来调用APP21，判定APP34(第一待测应用)也可以通过上述调用规则来调用APP3(第三待测应用)。再例如：在上述分组1中，若APP8(第二待测应用)调用APP5(第三待测应用)，调用规则是：z，在上述分组2中，在APP28(第一待测应用)启动的过程中，虽然没有任何应用被调用，但是通过查询日志文件，发现APP28(第一待测应用)向操作系统发送过的调用消息中包含上述调用规则：z，则可以认为该APP28(第一待测应用)可以通过上述调用规则：z来调用APP5(第三待测应用)。

值得提及的是，在上述例子提供的上述分组1和上述分组2中，可以根据采用的上述调用规则是否一致来判断属于分组1的第一、第三待测应用与属于分组2内的第一待测应用之间是否具有调用关系。当然，在可行的实施例中，若第二待测应用采用的调用规则与第一待测应用采用的调用规则属于相类似或相匹配的规则，也可以认定上述第二待测应用和上述第一待测应用均可以对第三待测应用进行调用。需要说明的是，上述相类似或相匹配的规则是指，调用规则虽然不完全一致，但是操作系统可以认定该不完全一致的规则具备相同的调用功能。

另外，关于如何利用调用规则对属于不同分组的待测应用间的调用关系的确定，并不限于上述已列举的情况。例如，根据调用规则的相似度(如相似度大于90％)，来确定不同分组的待测应用间是否存在调用关系(如：若调用规则的相似度大于90％，则认定具备相同的调用功能)。

值得说明的是，在某些情况中，上述调用规则可以包含下述信息：调用方的待测应用的标识信息、被调用的待测应用的标识信息以及发起调用时所采用的规则信息。例如，上述调用规则是：{APP1，APP2，com.abc.startService}。这样，可以无需确定属于同一分组的待测应用之间的调用关系，根据属于同一分组的待测应用之间的至少一次调用所采用的调用规则，将采用相同调用规则进行调用的所有调用方的待测应用和被调用的待测应用，分到一个存在调用关系的应用集合中。例如，在上述分组1中，若APP3和APP20之间发生至少一次调用时所采用的调用规则是：com.abc.startService；在上述分组2中，若APP31和APP35之间发生至少一次调用时所采用的调用规则也是：com.abc.startService。则确定的存在调用关系的应用集合是：{APP3、APP20、APP31、APP35}。

在上述各实施例提供的方法中，本申请实施例通过将待测应用分到各个分组中，对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则，最终，根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。可见，上述过程可以通过对大量待测应用进行分组，并利用同一分组的待测应用之间的调用规则来确定不同分组的待测应用之间存在的调用关系，从而实现了对大量待测应用之间存在的调用关系的确定。

值得提及的是，本申请实施例提供的上述方法的应用场景可以包括：

场景一，用于根据确定到的各应用间的调用关系和调用规则，来确定与所述调用规则对应的应用调用关系的阻隔方式。例如，检测到APP1和APP2之间通过消息的方式进行调用，则确定阻隔方式为禁止APP1发送上述消息，等等。

场景二，用于检测操作系统中对应用间调用关系的阻隔效果。

为优化操作系统(如：减小电量的消耗或加快系统的响应速度)，在检测到APP1和APP2之间存在相互调用关系时，可以通过阻隔机制不允许上述APP1和APP2进行相互调用。这样，为检验上述阻隔机制是否生效或成功，则可以通过上述方法来确定，若发现APP1和APP2仍然存在相互调用的行为，则确定上述阻隔机制没有生效或成功，否则，确定上述阻隔机制生效或成功。

场景三，用于检测到应用之间进行调用所采用的调用规则的变化。例如，APP1和APP2之间原先通过调用规则X来调用，通过上述方法，发现APP1和APP2之间不再通过调用规则X来调用，而是通过调用规则Y来调用。

需要说明的是，以上各实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤S101和步骤S102的执行主体可以为设备1，步骤S103的执行主体可以为设备2；又比如，步骤S101的执行主体可以为设备1，步骤S102和步骤S103的执行主体可以为设备2；等等。另外，各步骤之间的先后次序也可以进行变化，如：可以在获取到各待测应用的安装文件之后，再对各待测应用分到各个分组。另外，本文所提及的“第一”、“第二”、“第三”等，主要是起到对同一类对象的区别作用，并不代表对象之间的先后次序。

图5为本申请一实施例提供的测试控制装置的示意结构图。请参考图5，在硬件层面，该测试控制装置可以包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述确定应用之间调用关系的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等。其中，该确定应用之间调用关系的装置中各个单元的功能与上述方法中各个步骤的功能均类似，故可以参照上述方法实施例中的内容。

图6为本申请一实施例提供的确定应用之间调用关系的装置的模块示意图。本申请实施例中，上述确定应用之间调用关系的装置可以包括：分组单元101、第一确定单元102、第二确定单元103；其中：

分组单元101，用于将待测应用分到各个分组；

第一确定单元102，用于对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则；

第二确定单元103，用于根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

在上述各实施例提供的装置中，本申请实施例通过将待测应用分到各个分组中，对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则，最终，根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。可见，上述过程可以通过对大量待测应用进行分组，并利用同一分组的待测应用之间的调用规则来确定不同分组的待测应用之间存在的调用关系，从而实现了对大量待测应用之间存在的调用关系的确定。

在本申请可选的实施例中，所述第二确定单元103具体用于：

确定第一分组中的第一待测应用与第二分组中的第二待测应用之间存在调用关系，其中所述第一待测应用发起调用时所使用的调用规则与所述第二待测应用被调用时所使用的调用规则一致。

在本申请可选的实施例中，所述第一确定单元102具体用于：

确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则及与所述调用规则对应的调用关系；

所述第二确定单元103具体用于：若第一待测应用发起调用时所采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第一待测应用调用第三待测应用的调用关系；所述第二待测应用和所述第三待测应用属于同一分组，所述第一待测应用与所述第三待测应用属于不同分组；或，

若第一待测应用被其他待测应用调用时采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第二待测应用调用所述第一待测应用的调用关系。

在本申请可选的实施例中，所述分组单元101具体用于：

将待测应用分到各个分组，其中属于同一分组的待测应用被安装于同一终端上。

在本申请可选的实施例中，所述装置还包括：

命令发送单元，用于向终端发送用以将第二待测应用的进程开启、将第三待测应用的进程关闭的控制命令。其中，所述第二待测应用和所述第三待测应用属于同一分组。

相应地，所述第一确定单元102具体用于：

监测所述第三待测应用的进程是否开启；

若监测到所述第三待测应用的进程开启，则确定存在所述第二待测应用调用所述第三待测应用的调用关系，并确定所述第二待测应用调用所述第三待测应用时采用的调用规则。

在本申请可选的实施例中，所述装置还包括：

Monkey命令发送单元，用于向所述终端发送与所述第二待测应用对应的Monkey操作命令；或，

所述装置还用于将所述终端静置预设时长。

在本申请可选的实施例中，所述第一确定单元102具体包括：

消息获取单元，用于在存在第二待测应用调用第三待测应用的调用关系时，查找日志文件，获得所述第二待测应用调用所述第三待测应用时采用的调用消息；所述第二待测应用和所述第三待测应用属于同一分组；

规则确定单元，用于将所述调用消息中包含的第一特征确定为所述调用规则。

在本申请可选的实施例中，所述调用消息包括下述至少一种：

待测应用向操作系统发出的用于调用其他待测应用的广播消息；

待测应用向操作系统发出的用于调用其他应用的意图Intent消息；

待测应用向操作系统发出的用于调用其他应用的延迟意图PendingIntent消息。

在本申请可选的实施例中，所述分组单元101具体用于：

将若干待测应用随机分到各个分组；或，

按照各待测应用的热度排序，将若干待测应用分到各个分组；或，

将采用相同的软件开发工具包SDK进行开发的待测应用分到同一分组。

在本申请可选的实施例中，所述装置还包括：

均分单元，用于在分到各个分组的待测应用的数量不相等时，将同一待测应用分到不同的两个分组中。

在本申请可选的实施例中，所述装置还包括：

待测应用确定单元，用于根据预设排名区间，将处于所述预设排名区间内的应用确定为待测应用。其中，所述预设排名区间为：与应用的下载量排名对应的区间、或与使用应用的用户数排名对应的区间、或与应用的评论数排名对应的区间等。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (22)

1.一种确定应用之间调用关系的方法，其特征在于，包括：

将待测应用分到各个分组；

对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则；

根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

2.如权利要求1所述的方法，其特征在于，确定属于不同分组的待测应用之间存在的调用关系，包括：

确定第一分组中的第一待测应用与第二分组中的第二待测应用之间存在调用关系，其中所述第一待测应用发起调用时所使用的调用规则与所述第二待测应用被调用时所使用的调用规则一致。

3.如权利要求1或2所述的方法，其特征在于，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则，包括：

确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则及与所述调用规则对应的调用关系；

则，确定属于不同分组的待测应用之间存在的调用关系，具体包括：

若第一待测应用发起调用时所采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第一待测应用调用第三待测应用的调用关系；其中所述第二待测应用和所述第三待测应用属于同一分组，所述第一待测应用与所述第二待测应用属于不同分组；或，

若第一待测应用被其他待测应用调用时采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第二待测应用调用所述第一待测应用的调用关系。

4.如权利要求1所述的方法，其特征在于，将待测应用分到各个分组，具体包括：

将待测应用分到各个分组，其中属于同一分组的待测应用被安装于同一终端上。

5.如权利要求4所述的方法，其特征在于，在将待测应用分到各个分组之后，在确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则之前，所述方法还包括：

向终端发送用以将第二待测应用的进程开启、将第三待测应用的进程关闭的控制命令；所述第二待测应用和所述第三待测应用属于同一分组；

确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则，具体包括：

监测所述第三待测应用的进程是否开启；

若监测到所述第三待测应用的进程开启，则确定存在所述第二待测应用调用所述第三待测应用的调用关系，并确定所述第二待测应用调用所述第三待测应用时采用的调用规则。

6.如权利要求5所述的方法，其特征在于，在向终端发送所述控制命令之后，在监测所述第三待测应用的进程是否开启之前，所述方法还包括：

向终端发送与所述第二待测应用对应的Monkey操作命令；和/或，

将终端静置预设时长。

7.如权利要求1所述的方法，其特征在于，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则，具体包括：

在存在第二待测应用调用第三待测应用的调用关系时，查找日志文件，获得所述第二待测应用调用所述第三待测应用时采用的调用消息；所述第二待测应用和所述第三待测应用属于同一分组；

将所述调用消息中包含的第一特征确定为所述调用规则。

8.如权利要求7所述的方法，其特征在于，所述调用消息包括下述至少一种：

待测应用向操作系统发出的用于调用其他待测应用的广播消息；

待测应用向操作系统发出的用于调用其他应用的意图Intent消息；

待测应用向操作系统发出的用于调用其他应用的延迟意图PendingIntent消息。

9.如权利要求1所述的方法，其特征在于，将待测应用分到各个分组，具体包括：

将待测应用随机分到各个分组；或，

按照各待测应用的热度排序，将待测应用分到各个分组；或，

将采用相同的软件开发工具包SDK进行开发的待测应用分到同一分组。

10.如权利要求1所述的方法，其特征在于，在将待测应用分到各个分组之后，在确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则之前，所述方法还包括：

在分到各个分组的待测应用的数量不相等时，将同一待测应用分到不同的两个分组中。

11.如权利要求1所述的方法，其特征在于，将待测应用分到各个分组之前，所述方法还包括：

根据预设排名区间，将处于所述预设排名区间内的应用确定为待测应用；所述预设排名区间包括：与应用的下载量排名对应的区间、或与使用应用的用户数排名对应的区间、或与应用的评论数排名对应的区间。

12.一种确定应用之间调用关系的装置，其特征在于，包括：

分组单元，用于将待测应用分到各个分组；

第一确定单元，用于对于每一个分组，确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则；

第二确定单元，用于根据所述调用规则，确定属于不同分组的待测应用之间存在的调用关系。

13.如权利要求12所述的装置，其特征在于，所述第二确定单元具体用于：

确定第一分组中的第一待测应用与第二分组中的第二待测应用之间存在调用关系，其中所述第一待测应用发起调用时所使用的调用规则与所述第二待测应用被调用时所使用的调用规则一致。

14.如权利要求12或13所述的装置，其特征在于，所述第一确定单元具体用于：

确定属于同一分组的待测应用之间的至少一次调用所采用的调用规则及与所述调用规则对应的调用关系；

所述第二确定单元具体用于：

若第一待测应用发起调用时所采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第一待测应用调用第三待测应用的调用关系；其中所述第二待测应用和所述第三待测应用属于同一分组，所述第一待测应用与所述第二待测应用属于不同分组；或，

若第一待测应用被其他待测应用调用时采用的调用规则与第二待测应用调用第三待测应用时采用的调用规则一致，则确定存在所述第二待测应用调用所述第一待测应用的调用关系。

15.如权利要求12所述的装置，其特征在于，所述分组单元具体用于：

将待测应用分到各个分组，其中属于同一分组的待测应用被安装于同一终端上。

16.如权利要求15所述的装置，其特征在于，所述装置还包括：

命令发送单元，用于向终端发送用以将第二待测应用的进程开启、将第三待测应用的进程关闭的控制命令；所述第二待测应用和所述第三待测应用属于同一分组；

所述第一确定单元具体用于：

监测所述第三待测应用的进程是否开启；

若监测到所述第三待测应用的进程开启，则确定存在所述第二待测应用调用所述第三待测应用的调用关系，并确定所述第二待测应用调用所述第三待测应用时采用的调用规则。

17.如权利要求16所述的装置，其特征在于，所述装置还包括：

Monkey命令发送单元，用于向终端发送与所述第二待测应用对应的Monkey操作命令；和/或，

所述装置用于将终端静置预设时长。

18.如权利要求12所述的装置，其特征在于，所述第一确定单元具体包括：

消息获取单元，用于在存在第二待测应用调用第三待测应用的调用关系时，查找日志文件，获得所述第二待测应用调用所述第三待测应用时采用的调用消息；所述第二待测应用和所述第三待测应用属于同一分组；

规则确定单元，用于将所述调用消息中包含的第一特征确定为所述调用规则。

19.如权利要求18所述的装置，其特征在于，所述调用消息包括下述至少一种：

待测应用向操作系统发出的用于调用其他待测应用的广播消息；

待测应用向操作系统发出的用于调用其他应用的意图Intent消息；

待测应用向操作系统发出的用于调用其他应用的延迟意图PendingIntent消息。

20.如权利要求12所述的装置，其特征在于，所述分组单元具体用于：

将待测应用随机分到各个分组；或，

按照各待测应用的热度排序，将待测应用分到各个分组；或，

将采用相同的软件开发工具包SDK进行开发的待测应用分到同一分组。

21.如权利要求12所述的装置，其特征在于，所述装置还包括：

均分单元，用于在分到各个分组的待测应用的数量不相等时，将同一待测应用分到不同的两个分组中。

22.如权利要求12所述的装置，其特征在于，所述装置还包括：

待测应用确定单元，用于根据预设排名区间，将处于所述预设排名区间内的应用确定为待测应用；所述预设排名区间包括：与应用的下载量排名对应的区间、或与使用应用的用户数排名对应的区间、或与应用的评论数排名对应的区间。