一种应用程序的测试方法、装置、设备及存储介质与流程

本公开涉及数据处理技术领域，尤其涉及一种应用程序的测试方法、装置、设备及存储介质。

背景技术：

如今，为确保加载在移动终端上的应用程序可正常运行，针对应用程序的自动化测试越来越普及。目前主要是通过手机等测试设备对应用程序进行测试。

由于在应用程序测试的过程中，测试设备容易出现异常而影响测试流程；因此，传统的针对移动终端中应用的功能测试，主要基于设备冗余的思想，即同时利用多台测试设备对同一款应用程序进行测试。但是，通过设备冗余的方式实现应用程序测试，显然占用了过多的测试设备，无疑是对测试资源的浪费。

技术实现要素：

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种应用程序的测试方法、装置、设备及存储介质。

本公开提供了一种应用程序的测试方法，所述方法包括：响应于携带测试服务端标识的应用程序测试请求，确定所述测试服务端标识对应的目标测试服务端；其中，所述目标测试服务端运行于目标容器中；获取所述目标容器的配置文件中的第一设备标识，并利用所述目标测试服务端，驱动所述第一设备标识对应的第一测试设备，对目标应用程序进行测试；当检测到所述第一测试设备发生异常时，从所述目标容器对应的可用测试设备标识中，获取第二设备标识，并将所述配置文件中的所述第一设备标识更新为所述第二设备标识；利用所述目标测试服务器，驱动所述第二设备标识对应的第二测试设备，对所述目标应用程序进行测试。

可选的，所述获取第二设备标识之后，且在所述将所述配置文件中的所述第一设备标识更新为所述第二设备标识之前，还包括：针对所述第二设备标识对应的第二测试设备，执行所述目标应用程序的前置脚本；其中，前置脚本用于实现所述目标应用程序的前置阶段操作，所述前置阶段操作包括安装所述目标应用程序、初始化资源和登录账户中的任意一项或多项操作。

可选的，所述从所述目标容器对应的可用测试设备标识中，获取第二设备标识之前，还包括：当监听到部署所述目标容器的测试主机上的通用串行总线设备插入消息时，获取当前插入设备的设备标识，并将所述设备标识确定为所述目标容器对应的可用测试设备标识；或者，当监听到部署所述目标容器的测试主机上的通用串行总线设备拔出消息时，获取当前拔出设备的设备标识，并将所述设备标识从所述目标容器对应的可用测试设备标识中删除。

可选的，所述当检测到所述第一测试设备发生异常时，从所述目标容器对应的可用测试设备标识中，获取第二设备标识，包括：当检测到所述第一测试设备发生异常时，从所述目标容器对应的可用测试设备标识中，获取与所述第一测试设备具有相同的预设属性的设备的标识，作为第二设备标识。

可选的，所述方法还包括：利用所述目标测试服务端，向所述第一测试设备发送心跳连接，并基于所述心跳连接结果，确定所述第一测试设备是否发生异常。

可选的，所述目标容器与所述目标测试服务端具有一一对应关系。

可选的，所述服务端标识包括互联网协议地址和端口号；所述响应于携带测试服务端标识的应用程序测试请求，确定所述测试服务端标识对应的目标测试服务端，包括：响应于携带互联网协议地址和端口号的应用程序测试请求，确定所述互联网协议地址对应的测试主机；确定所述测试主机中与所述端口号对应的目标测试服务端；其中，所述目标测试服务端运行于部署在所述测试主机上的目标容器中。

本公开还提供了一种应用程序的测试装置，所述装置包括：服务端确定模块，用于响应于携带测试服务端标识的应用程序测试请求，确定所述测试服务端标识对应的目标测试服务端；其中，所述目标测试服务端运行于目标容器中；第一设备标识获取模块，用于获取所述目标容器的配置文件中的第一设备标识，并利用所述目标测试服务端，驱动所述第一设备标识对应的第一测试设备，对目标应用程序进行测试；第二设备标识获取模块，用于当检测到所述第一测试设备发生异常时，从所述目标容器对应的可用测试设备标识中，获取第二设备标识，并将所述配置文件中的所述第一设备标识更新为所述第二设备标识；程序测试模块，用于利用所述目标测试服务器，驱动所述第二设备标识对应的第二测试设备，对所述目标应用程序进行测试。

本公开还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备实现上述应用程序的测试方法。

本公开还提供了一种设备，包括：存储器，处理器，及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现上述应用程序的测试方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例提供了一种应用程序的测试方法、装置、设备及存储介质，该方法包括：首先响应于携带测试服务端标识的应用程序测试请求，确定测试服务端标识对应的目标测试服务端，该目标测试服务端运行于目标容器中；然后获取目标容器的配置文件中的第一设备标识，并利用目标测试服务端，驱动第一设备标识对应的第一测试设备，对目标应用程序进行测试。而后，当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取第二设备标识，并将配置文件中的第一设备标识更新为第二设备标识；利用目标测试服务器，驱动第二设备标识对应的第二测试设备，对目标应用程序进行测试。在上述测试方式中，目标测试服务端运行于目标容器中，而且，容器的配置文件通常用于保存挂载在该容器的可用设备的设备标识；因此，在基于测试服务端标识确定目标测试服务端后，可以基于配置文件中的设备标识，确定由该目标测试服务端驱动的测试设备，进而完成对目标应用程序的测试。显然，本公开提供的上述测试方式，在同一个时间点只占用一台测试设备，无需同时占用多台测试设备，减少了测试资源的浪费。

进一步，考虑到容器的配置文件是可修改的，因此在第一测试设备出现异常的情况下，可以通过更新目标容器的配置文件中设备标识的方式，将第一测试设备更换为可用的第二测试设备，然后利用第二测试设备对目标应用程序进行测试；因此，本公开提供的应用程序测试方法，在减少测试资源浪费的基础上，还能够有效改善因测试过程中断而影响应用程序测试流程这一问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1a为本公开实施例所述测试平台示意图；

图1b为本公开实施例所述应用程序的测试方法的流程图；

图2为本公开实施例所述测试设备更新方法的流程图；

图3为本公开实施例所述应用程序的测试装置的结构框图；

图4为本公开实施例所述一种设备的结构框图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

在针对移动终端中应用程序的自动化测试的过程中，发明人研究发现，由于测试设备长时间运行等原因，容易导致测试设备出现异常，例如卡死、弹出应用程序无响应(applicationnotresponding；anr)对话框、运行过程关机等。一旦测试设备出现异常，则会导致应用程序测试过程中断，影响应用程序测试流程。

为此，目前主要通过两种方式来进行测试：

一种方式是基于设备冗余的思想，即同时利用多台测试设备对同一款应用程序进行测试，并且只要存在一台测试设备能够成功完成测试过程，则说明针对该应用程序测试成功。但是，通过设备冗余的方式实现应用程序测试，显然占用了过多的测试设备，无疑是对测试资源的浪费。

另一种方式是基于任务分发思路，预先将测试任务拆分成多个子任务，通过调度，每个测试设备只执行一个子任务，当所有子任务成功执行完成时确定应用程序测试成功。但是，当执行某个子任务的设备出现异常时，无法恢复测试，还需要用户知道是哪台设备出现异常了，以重新调度新的测试设备重新执行子任务。

基于此，为改善以上问题至少之一，本公开实施例提供了一种应用程序的测试方法、装置、设备及存储介质，为便于理解，以下对本公开实施例进行详细介绍。

实施例一：

本公开实施例提供一种应用程序的测试方法，示例性地，本方法可以被实现为测试平台上，参照图1a，测试平台可以至少部署有测试主机、容器、测试服务端和测试设备。

在实际应用中，容器可以部署在测试主机上，且一台测试主机上部署至少一个容器；测试服务端可以运行于容器中，容器可以挂载多台测试设备。

参考图1b所示的应用程序的测试方法的流程图，该方法可以包括如下步骤：

步骤s102，响应于携带测试服务端标识的应用程序测试请求，确定测试服务端标识对应的目标测试服务端；其中，目标测试服务端运行于目标容器中。

在执行应用程序测试的应用场景中，当只有一台测试主机时，测试服务端标识可以为测试服务端(adb-server)的端口号，基于此，可以响应于携带端口号的应用程序测试请求，确定该台测试主机中与端口号对应的目标测试服务端。当有多台测试主机时，参照图1a中的实线部分，测试服务端标识可以包括ip(互联网协议)地址和端口号，基于此，可以首先响应于携带ip地址和端口号的应用程序测试请求，确定ip地址对应的测试主机；然后再确定测试主机中与端口号对应的目标测试服务端。

步骤s104，获取目标容器的配置文件中的第一设备标识，并利用目标测试服务端，驱动第一设备标识对应的第一测试设备，对目标应用程序进行测试。

在实际应用中，容器(docker)里的资源分配和管理依赖配置文件，配置文件是用户预先对容器对应的可用设备进行配置而生成的文件。从而，配置文件中可以包括挂载于目标容器的可用设备的参数，该参数包括设备标识。设备标识为表示测试设备的唯一且不变的标识，以手机作为测试设备为例，设备标识可以包括手机的主属性值和从属性值，且主属性值用于表示手机类型，从属性值用于区分同一手机类型下的不同手机。

在确定测试服务端标识对应的目标测试服务端时，即可确定运行目标测试服务端目标容器，进而通过读取目标容器的配置文件，获取配置文件中保存的第一设备标识；然后利用目标测试服务端，驱动第一设备标识对应的第一测试设备(如图1a中的测试设备1)，对目标应用程序进行测试。

步骤s106，当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取第二设备标识，并将配置文件中的第一设备标识更新为第二设备标识。

考虑到在应用程序的测试过程中，有可能出现第一测试设备异常，并由此导致应用程序测试过程中断，影响应用程序测试流程。基于此，本实施例可以对第一测试设备进行检测，并当检测第一测试设备发生异常时，及时更换为第二测试设备，保证测试流程持续、稳定的进行。在本实施例中，目标容器对应的可用测试设备标识可能有多个，可以从中指定一个作为第二设备标识，并将配置文件中的第一设备标识更新为该选取出的第二设备标识。

步骤s108，利用目标测试服务端，驱动第二设备标识对应的第二测试设备(如图1a中的测试设备2)，对目标应用程序进行测试。

在本实施例中，第一设备标识对应的第一测试设备可以包括至少一台测试设备；目标测试服务端是一个始终在后台运行的服务进程，它基于应用程序测试请求驱动第一测试设备对目标应用程序进行测试。

本公开实施例提供的应用程序的测试方法，首先响应于携带测试服务端标识的应用程序测试请求，确定测试服务端标识对应的目标测试服务端，该目标测试服务端运行于目标容器中；然后获取目标容器的配置文件中的第一设备标识，并利用目标测试服务端，驱动第一设备标识对应的第一测试设备，对目标应用程序进行测试。而后，当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取第二设备标识，并将配置文件中的第一设备标识更新为第二设备标识，以及利用目标测试服务器，驱动第二设备标识对应的第二测试设备，对目标应用程序进行测试。

在上述测试方式中，目标测试服务端运行于目标容器中，而且，容器的配置文件通常用于保存挂载在该容器的可用设备的设备标识；因此，在基于测试服务端标识确定目标测试服务端后，可以基于配置文件中的设备标识，确定由该目标测试服务端驱动的测试设备，进而完成对目标应用程序的测试。显然，本公开提供的上述测试方式，在同一个时间点只占用一台测试设备，无需同时占用多台测试设备，减少了测试资源的浪费。进一步，考虑到容器的配置文件是可修改的，因此在第一测试设备出现异常的情况下，可以通过更新配置文件中设备标识的方式，将第一测试设备更换为第二测试设备，然后利用第二测试设备对目标应用程序进行测试；因此，本公开提供的应用程序测试方法，在减少测试资源浪费的基础上，还能够有效改善因测试过程中断而影响应用程序测试流程这一问题。

为了更好地理解本公开实施例提供的应用程序的测试方法，接下来针对上述各步骤的实现方式展开详细描述。

针对上述步骤s102，应用程序测试请求可以是用户通过客户端(adb-devices)发起的，该客户端可以是根据ip地址和端口号创建得到的，例如参照如下代码：client＝adbclient(host＝host,port＝port)。

客户端向测试平台传输应用程序测试请求；测试平台根据应用程序测试请求及其携带的端口号和ip地址，确定目标测试服务端。

在具体实现时，可以通过如下代码：adb-a-p$portservernodaemon&，将目标测试服务端实现对外服务；在客户端上，通过adb(androiddebugbridge，安卓调试桥)工具使用adb-h$pc1_ip-p$portshell，令目标测试服务端处理客户端的应用程序测试请求，驱动第一测试设备对目标应用程序进行测试。上述客户端所利用的adb工具的版本，与目标测试服务端所使用adb工具的版本相同。

进而确定目标测试服务端所在目标容器上挂载的第一测试设备，利用目标测试服务端驱动第一测试设备对目标应用程序进行测试。

客户端与目标测试服务端交互，向目标测试服务端传输应用程序测试请求。在现有技术中，测试服务端对接的测试设备有多个。由于测试服务端对接的测试设备越多，测试服务端掉线的概率就越高；基于此，在本实施例中，将每个测试服务端运行在一个隔离的容器中，也即目标容器与目标测试服务端具有一一对应关系，并且，每个测试服务端对接较少数量的测试设备，比如仅对接一台测试设备。

以每个测试服务端对接一台测试设备为例，每个测试服务端对接的一台测试设备是通过容器实现的，可以理解为，在任意时刻，每个容器中只绑定一台与目标测试服务端对接的可用测试设备。基于此，本实施例提供一种将测试设备绑定至容器的可能实现方式，参照如下步骤(1)和(2)所示。

(1)参照如下代码，将全部usb(universalserialbus，通用串行总线)上连接的测试设备均挂载于目标容器中：

dockerrun--rm-d-v/dev/bus/usb:/dev/bus/usb--nethost--nameadb$port_numhub.byted.org/toutiao.stf.adb:latestadb-a-p$port_numservernodaemon。

目标容器中挂载的多个测试设备中，将只有第一测试设备用于目标应用程序的测试，其他测试设备作为备用，在第一测试设备出现异常的情况下，从其他测试设备中选取更换的可用测试设备。

(2)将第一设备标识配置于目标容器的配置文件中；其中，第一设备标识是挂载于目标容器下的可用测试设备标识中的一个或多个。

在一种实施例中，首先对多个测试设备进行活性检测，获取可用测试设备和每个可用测试设备的标识，也即获取目标容器对应的可用测试设备标识；然后在上述可用测试设备标识中指定第一设备标识，将第一设备标识配置于容器的配置文件中。至此，即可实现将第一设备标识对应的第一测试设备绑定至目标容器上。

具体的，当测试设备为手机时，设备标识可以包括主属性值(major)和从属性值(minor)，手机的major一般为189，表示手机类型，minor用于区分不同手机。根据获取的手机的major和minor，在容器的配置文件中进行如下代码所示的配置：

1#device.allow

2c189:*rwm#ifconfiglikethis,willallowallsmartphoneloadindocker

3c189:25rwm#ifconfiglikethis,willonlyallowonephonewithmior25loadindocker

即可在容器中绑定由major和minor确定的手机。

针对上述实施例中的可用测试设备标识，可以预先通过写入操作和/或删除操作的方式获取，具体可参照如下方式：

当监听到部署目标容器的测试主机上的usb设备插入消息时，获取当前插入设备的设备标识，并将设备标识确定为目标容器对应的可用测试设备标识；或者，当监听到部署目标容器的测试主机上的usb设备拔出消息时，获取当前拔出设备的设备标识，并将设备标识从目标容器对应的可用测试设备标识中删除。

在具体实现时，当监听到部署目标容器的测试主机上的usb设备插入消息或者usb设备拔出消息时，得到测试设备的装载路径(mountpath)，再由装载路径获取手机的major和minor。

而后，可以在目标容器对应的可用测试设备标识中随机指定一个设备标识，将其作为第一设备标识并配置于目标容器的配置文件中。可以理解的是，对于更新后的第二设备标识，也可以采用同样的方式，从目标容器对应的可用测试设备标识中获取并配置于目标容器的配置文件中。

考虑到在应用程序的测试过程中，可以对第一测试设备进行检测，以在第一测试设备发生异常时，及时更换第二测试设备，保证测试流程持续、稳定的进行。基于此，本实施例提供一种测试设备的检测方法，参照如下所示：

利用目标测试服务端，向第一测试设备发送心跳连接，并基于心跳连接结果，确定第一测试设备是否发生异常。

在本实施例中，目标测试服务端按照预设周期(如30秒)向第一测试设备发送adb-p$portshellpwd作为心跳连接；如果第一测试设备能够正常响应，说明第一测试设备未发生异常；如果第一测试设备不能正常响应，说明第一测试设备发生异常，需要更换为其它可用的测试设备并绑定至目标容器中。

当检测到第一测试设备发生异常时，参照图2，本实施例提供一种将第一测试设备更新为第二测试设备的方法，可以包括如下步骤：

步骤s202，当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取第二设备标识。

在实际应用中，用户可能对测试设备的属性有个性化需求，比如，只针对某种类型手机进行的应用程序的测试，用户需要更换前后的手机类型(也即主属性值)相同；在此情况下，当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取与第一测试设备具有相同的预设属性的设备的标识，作为第二设备标识。

具体的，首先获取用户对测试设备的预设属性；预设属性比如手机类型或手机品牌。然后根据预先建立的映射关系，在目标容器对应的可用测试设备标识中，确定与第一测试设备具有相同的预设属性的设备的第二设备标识。其中，映射关系用于表示测试设备的设备标识与预设属性之间的对应关系；以手机为例，映射关系可以是当手机通过usb插入到容器中时，建立的手机的从属性值与手机类型之间的映射关系。

获取第二设备标识之后，执行如下步骤s204。

步骤s204，针对第二设备标识对应的第二测试设备，执行目标应用程序的前置脚本；其中，前置脚本用于实现目标应用程序的前置阶段操作，前置阶段操作可以至少包括：安装目标应用程序、初始化资源和登录账户中的任意一项或多项操作；且前置脚本在更新第二测试设备之前执行。

在本实施例中，可以设定前置脚本的超时时间(如30分钟)，并在达到超时时长后，再将第一测试设备更换为第二测试设备，以保障更换第二测试设备后的前置操作全部完成。

步骤s206，将配置文件中的第一设备标识更新为第二设备标识。此后利用目标测试服务器，驱动第二设备标识对应的第二测试设备，对目标应用程序进行测试。

在本实施例提供的测试设备的更换方式中，由于更换后的第二第二设备标识属于目标容器对应的可用测试设备标识，因此，第二设备标识对应的第二测试设备必然可用于测试。

在上述实施例中，测试设备的检测是在目标测试服务端与测试设备之间进行的，测试设备的更换是在目标容器上实现的，以上过程均没有暴露于用户面前；因此对用户而言，不需要关心正在进行测试的测试设备是哪台设备，也不需要关心挂载于容器的多台测试设备是否出现关机、掉线、假死、离线等异常。测试平台通过向用户提供ip地址和端口号，在接收用户发起的携带ip地址和端口号的应用程序测试请求后，可以快速确定目标测试服务端和可用测试设备(可用测试设备，即第一测试设备或更新后的第二测试设备)，并利用目标测试服务端直接驱动该确定的可用测试设备，对目标应用程序进行测试。

综上，上述实施例提供的应用程序的测试方法，基于携带测试服务端标识的应用程序测试请求，能够直接确定目标测试服务端，并利用目标测试服务端驱动第一测试设备对目标应用程序进行测试。显然，本公开提供的上述测试方式，无需同时占用多台测试设备，减少了测试资源的浪费。接下来在应用程序的测试过程中，考虑到容器的配置文件是可修改的，因此当第一测试设备出现异常时，可以通过修改目标容器的配置文件中设备标识的方式，将第一测试设备更换为可用的第二测试设备，然后利用第二测试设备对目标应用程序进行测试；因此，本公开提供的应用程序测试方法，在减少测试资源浪费的基础上，还能够有效改善因测试过程中断而影响应用程序测试流程这一问题。

实施例二：

本实施例提供一种应用程序的测试装置，用于实现上述实施例一中的应用程序的测试方法。参照图3，该装置包括：

服务端确定模块302，用于响应于携带测试服务端标识的应用程序测试请求，确定测试服务端标识对应的目标测试服务端；其中，目标测试服务端运行于目标容器中；

第一设备标识获取模块304，用于获取目标容器的配置文件中的第一设备标识，并利用目标测试服务端，驱动第一设备标识对应的第一测试设备，对目标应用程序进行测试；

第二设备标识获取模块306，用于当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取第二设备标识，并将配置文件中的第一设备标识更新为第二设备标识；

程序测试模块308，用于利用目标测试服务器，驱动第二设备标识对应的第二测试设备，对目标应用程序进行测试。

本公开实施例提供的应用程序的测试装置，基于测试服务端标识能够确定目标测试服务端，并利用目标测试服务端直接驱动可用的测试设备对目标应用程序进行测试。在该测试方式中，在同一个时间点只占用一台测试设备，无需同时占用多台测试设备，减少了测试资源的浪费。进一步，考虑到容器的配置文件是可修改的，因此在第一测试设备出现异常的情况下，可以通过更新目标容器的配置文件中设备标识的方式，将第一测试设备更换为可用的第二测试设备，然后利用第二测试设备对目标应用程序进行测试；因此，本公开提供的应用程序测试方法，在减少测试资源浪费的基础上，还能够有效改善因测试过程中断而影响应用程序测试流程这一问题。

在一种实施例中，第二设备标识获取模块306还用于：针对第二设备标识对应的第二测试设备，执行目标应用程序的前置脚本；其中，前置脚本用于实现目标应用程序的前置阶段操作，前置阶段操作包括安装目标应用程序、初始化资源和登录账户中的任意一项或多项操作。

在一种实施例中，上述装置还包括监听模块(图中未示出)，其用于：当监听到部署目标容器的测试主机上的通用串行总线设备插入消息时，获取当前插入设备的设备标识，并将设备标识确定为目标容器对应的可用测试设备标识；或者，当监听到部署目标容器的测试主机上的通用串行总线设备拔出消息时，获取当前拔出设备的设备标识，并将设备标识从目标容器对应的可用测试设备标识中删除。

在一种实施例中，上述第二设备标识获取模块306还用于：当检测到第一测试设备发生异常时，从目标容器对应的可用测试设备标识中，获取与第一测试设备具有相同的预设属性的设备的标识，作为第二设备标识。

在一种实施例中，上述装置还包括异常检测模块(图中未示出)，其用于：利用目标测试服务端，向第一测试设备发送心跳连接，并基于心跳连接结果，确定第一测试设备是否发生异常。

在一种实施例中，上述服务端标识包括互联网协议地址和端口号；上述服务端确定模块302还用于：响应于携带互联网协议地址和端口号的应用程序测试请求，确定互联网协议地址对应的测试主机；确定测试主机中与端口号对应的目标测试服务端；其中，目标测试服务端运行于部署在测试主机上的目标容器中。

本实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例一相同，为简要描述，本实施例部分未提及之处，可参考前述方法实施例一中相应内容。

基于前述实施例，本实施例给出了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当指令在终端设备上运行时，使得终端设备实现上述实施例提供的应用程序的测试方法。

本实施例还给出了一种设备，包括：存储器，处理器，及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时，实现上述实施例提供的应用程序的测试方法。参见图4所示，该设备可以包括：

处理器401、存储器402、输入装置403和输出装置404。图集打包设备中的处理器401的数量可以一个或多个，图4中以一个处理器为例。在本发明的一些实施例中，处理器401、存储器402、输入装置403和输出装置404可通过总线或其它方式连接，其中，图4中以通过总线连接为例。

存储器402可用于存储软件程序以及模块，处理器401通过运行存储在存储器402的软件程序以及模块，从而执行图集打包设备的各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。输入装置403可用于接收输入的数字或字符信息，以及产生与图集打包设备的用户设置以及功能控制有关的信号输入。

具体在本实施例中，处理器401会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现上述图集打包设备的各种功能。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。