CN114528071A - 一种应用检测方法、装置、设备和存储介质 - Google Patents

Abstract

本发明公开了一种应用检测方法、装置、设备和存储介质。其中，该方法包括：响应于目标应用的运行检测指令，调用本地虚拟容器，根据所述目标应用的源代码和配置文件，生成所述目标应用的打包文件；调用所述本地虚拟容器，安装所述打包文件，并运行所述目标应用；调用运行检测工具，对所述目标应用的运行过程进行检测。通过本发明的技术方案，能够节约应用检测过程中的人工成本，提高应用检测效率和应用检测的准确性。

Description

一种应用检测方法、装置、设备和存储介质

技术领域

本发明实施例涉及计算机领域，尤其涉及一种应用检测方法、装置、设备和存储介质。

背景技术

现阶段的应用检测方法需要开发人员在提交代码后，由应用检测工具配合人工操作执行应用检测。随着开发人员提交代码次数的增加，代码规模会逐渐扩大，逐渐扩大的代码规模需要越来越多的开发人员共同维护，导致人工成本增加，且人工维护无法保证应用检测软件运行的稳定性。因此，如何在节约人工成本的同时提高应用检测的稳定性，是需要解决的问题。

发明内容

本发明实施例提供一种应用检测方法、装置、设备和存储介质，以提高应用检测的检测效率和准确性。

第一方面，本发明实施例提供了一种应用检测方法，包括：

响应于目标应用的运行检测指令，调用本地虚拟容器，根据所述目标应用的源代码和配置文件，生成所述目标应用的打包文件；

调用所述本地虚拟容器，安装所述打包文件，并运行所述目标应用；

调用运行检测工具，对所述目标应用的运行过程进行检测。

第二方面，本发明实施例还提供了一种应用检测装置，包括：

打包文件生成模块，用于响应于目标应用的运行检测指令，调用本地虚拟容器，根据所述目标应用的源代码和配置文件，生成所述目标应用的打包文件；

目标应用运行模块，用于调用所述本地虚拟容器，安装所述打包文件，并运行所述目标应用；

目标应用检测模块，用于调用运行检测工具，对所述目标应用的运行过程进行检测。

第三方面，本发明实施例还提供了一种电子设备，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明任意实施例所述的应用检测方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本发明任意实施例所述的应用检测方法。

本发明实施例提供的技术方案，通过为目标应用建立运行检测指令，调用本地虚拟容器，根据目标应用生成目标应用的打包文件，并将目标应用的打包文件安装在调用虚拟容器的应用检测任务中，通过运行应用检测工具，在目标应用运行的过程中对目标程序进行检测，以检测目标应用是否存在故障。上述方案，解决了在应用检测过程中人工参与程度过高，随着应用规模的扩大，人工成本的投入会越来越高且人工对应用检测耗时过长，且人工对应用进行检测时存在检测误差，导致检测结果不精确的问题。本方案通过调用本地虚拟容器，通过构建运行检测指令和运行检测工具，将目标应用打包后安装在运行检测任务中，为目标应用提供应用检测环境，可以节约应用检测过程中的人工成本，提高了应用检测效率和应用检测的准确性。

附图说明

图1为本发明实施例一提供的一种应用检测方法的流程图；

图2为本发明实施例二提供的一种应用检测方法的流程图；

图3为本发明实施例三提供的一种应用检测方法的流程图；

图4为本发明实施例四提供的一种应用检测方法的架构图；

图5为本发明实施例五提供的一种应用检测装置的结构示意图；

图6为本发明实施例六提供的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1为本发明实施例一提供的一种应用检测方法的流程图，本实施例可适用于如何对应用的运行过程进行检测的情况。该方法可以由本发明实施例提供的应用检测装置来执行，该装置可以采用软件和/或硬件的方式来实现。该装置可配置承载于应用检测功能的电子设备中；可选的，该装置具体可承载于该电子设备中的GitLab中。

其中，Gitlab是一款仓库管理系统的开源项目，其使用Git作为代码管理工具，并在此基础上搭建起来的Web服务，Gitlab支持持续集成功能。一个软件或应用，其源代码存储在Gitlab的Git存储库中，用户可以向Git存储库提交代码，Gitlab可以根据用户提交的代码创建一组脚本来自动构建和测试应用程序，这种方法可以通过GitLab-CI(Gitlab-Continuous Integration，持续集成)实现。用户每一次向Git存储库提交代码，代码仓库都可以根据用户提交的代码自动的构建代码的运行检测软件，并基于构建的运行检测软件对代码进行运行检测。

可选的，本实施例所提供的应用检测方法具体包括：

S110、响应于目标应用的运行检测指令，调用本地虚拟容器，根据目标应用的源代码和配置文件，生成目标应用的打包文件。

其中，运行检测指令是由用户向代码仓库提交代码后所触发产生的，代码仓库可以是Gitlab。目标应用是指需要检测是否存在运行错误的应用，运行错误包括目标应用的内存泄露，目标应用的内存泄露通常是由于目标应用的源代码存在代码缺陷导致的。本地虚拟容器是指用于对目标应用进行运行检测的电子设备上的虚拟环境，虚拟环境可以是基于Linuxel7的Docker虚拟环境。配置文件可以配置目标应用的相关指令和数据等的文件。

具体的，通过代码仓库开启持续集成工具，并为持续集成工具安装和配置流水线运行环境。其中，持续集成工具可以是GitLab-CI。当用户向代码仓库提交目标应用的源代码后，代码仓库根据目标应用的源代码在流水线运行环境中添加构建任务。其中构建任务包括对目标应用的源代码编译环境的构建指令、第三方依赖包的安装部署指令和打包环境构建指令等。

根据目标应用的打包环境的构建指令，代码仓库调用本地虚拟容器，将流水线运行环境构建为虚拟环境，以在虚拟环境中对目标应用进行打包。例如，根据目标应用的源代码打包环境的构建指令，在流水线任务中添加打包任务，对目标应用的相关文件进行打包工作，打包工作可以由软件包管理器执行，软件包管理器可以是RPM(Red-Hat PackageManager红帽软件包管理器)。其中，目标应用的相关文件包括目标应用的源代码和配置文件。按照生成打包文件的逻辑，根据目标应用的源代码和配置文件，生成打包文件。生成打包文件的逻辑可以根据实际需求进行预设。

S120、调用本地虚拟容器，安装打包文件，并运行目标应用。

其中，打包文件安装在流水线运行环境中的执行目标应用检测任务的软件上。

具体的，在生成目标应用的打包文件之后，根据目标应用的第三方依赖包的安装部署指令，代码仓库调用本地虚拟容器，在持续集成工具构建的流水线运行环境中添加故障检测任务，用于检测目标应用的应用数据是否发生数据异常。例如，数据异常可以是目标应用出现了软件泄露，导致应用数据缺失的异常现象。故障检测任务取用根据目标应用的源代码和配置文件生成的打包文件，并通过安装指令执行打包文件的安装操作，为后续应用检测指令提供运行环境。完成打包文件的安装操作后，运行目标应用。

S130、调用运行检测工具，对目标应用的运行过程进行检测。

其中，运行检测工具是指在目标应用运行过程中检测目标应用是否存在故障的工具，运行检测工具可以安装在故障检测任务中，通过故障检测指令实现。故障检测指令可以是valgrind指令。

具体的，在本地虚拟容器中调用运行检测工具，在目标应用的运行过程中，通过调用运行检测工具对目标应用的运行过程进行检测，获得目标应用的检测结果，并根据检测结果确定目标应用是否存在故障。例如，检测结果可以是目标应用的运行结果，若根据目标应用运行结果确定目标应用在运行过程中出现了报错现象或目标应用在运行过程中存在内存未被释放的情况，则目标应用存在故障；若根据目标应用运行结果确定目标应用在运行过程中运行正常，则目标应用不存在故障。

本实施例提供的技术方案，通过为目标应用建立运行检测指令，调用本地虚拟容器，生成目标应用的打包文件，并将目标应用的打包文件安装在调用虚拟容器的应用检测任务中，通过运行应用检测工具，在目标应用运行的过程中对目标程序进行检测，以检测目标应用是否存在故障。上述方案，解决了在应用检测过程中人工参与程度过高，随着应用规模的扩大，人工成本的投入会越来越高且人工对应用检测耗时过长，且人工对应用进行检测时存在检测误差，导致检测结果不精确的问题。本方案通过调用本地虚拟容器，通过构建运行检测指令和运行检测工具，将目标应用打包后安装在运行检测任务中，为目标应用提供应用检测环境，可以节约应用检测过程中的人工成本，提高了应用检测效率和应用检测的准确性。

实施例二

图2为本发明实施例二提供的一种应用检测方法的流程图，本实施例在上述实施例的基础上进行了优化，给出了一种根据目标应用的编译文件和配置文件生成目标应用的打包文件的可选实施例。具体的，如图2所示，本实施例提供的应用检测方法可以包括：

S210、响应于目标应用的运行检测指令，调用本地虚拟容器对目标应用的源代码进行编译，生成目标应用的编译文件。

其中，编译文件是指根据预先设置的编辑指令，对目标应用的源代码进行编译生成的可执行文件。

具体的，当用户向代码仓库提交目标应用的源代码后，代码仓库根据目标应用的源代码编译环境的构建指令，在流水线运行环境中添加编译任务，调用本地虚拟容器，以使本地虚拟容器构建目标应用的编译环境，并在编译环境下，对目标应用的源代码进行编译。编译任务包括目标应用源代码的编译指令，整合构建任务包括的指令与编译任务包括的指令，生成编译文件。

S220、调用本地虚拟容器，根据目标应用的编译文件和配置文件，生成目标应用的打包文件。

其中，配置文件包括目标应用的软件配置相关文件和运行依赖。其中，运行依赖可以是目标应用的动态代码仓库和静态代码仓库。

具体的，代码仓库根据打包环境构建指令，在流水线任务中添加打包任务，并调用本地虚拟容器，按照生成打包文件的逻辑，对目标应用的编译文件和配置文件进行打包工作，生成目标应用的打包文件。

S230、调用本地虚拟容器，安装打包文件，并运行目标应用。

S240、调用运行检测工具，对目标应用的运行过程进行检测。

可选的，在对目标应用的运行过程进行检测时，可以通过在运行检测任务中运行测试数据以使运行检测工具可以进入工作状态，具体的，可以通过如下子步骤实现：

S2401、调用本地虚拟容器，控制目标应用对测试数据进行处理。

其中，测试数据是指用于对目标应用进行检测所需的数据。

具体的，在将目标应用的打包文件安装在流水线运行环境中的执行目标应用检测任务的软件上后，代码仓库调用本地虚拟容器，并将测试数据输入目标应用，使目标应用可以在执行目标应用检测任务的软件上运行测试数据，对测试数据进行处理。

S2402、调用运行检测工具，对目标应用处理测试数据的运行过程进行检测。

具体的，可以通过测试数据，使执行目标应用检测任务的软件启动并运行在虚拟环境中，同时将执行目标应用检测任务的软件接入故障检测指令的沙箱环境中。将测试数据输入安装在流水线运行环境中的目标应用中，代码仓库调用运行检测工具，在目标应用运行测试数据的过程中，对目标应用的运行过程进行检测，并根据测试数据在目标应用上的运行结果生成目标应用的检测报告，根据目标应用的检测报告，确定目标应用是否存在故障。例如，若通过目标应用的检测报告确定测试数据在目标应用上运行的过程中存在运行错误，则目标应用存在故障。

通过测试数据在目标应用上的运行结果判断目标应用是否存在故障，可以通过运行测试数据使执行目标应用检测任务的软件启动并进入工作状态，可以在安装目标应用的打包文件后，按照检测需求，在需要对目标应用进行检测时输入测试数据，使对目标应用的检测更加灵活；同时，可以通过检测报告上测试数据的测试结果，更加直观的确定目标应用是否存在故障。

本实施例提供的技术方案，根据目标应用的源代码生成目标应用的编译文件，并根据目标应用的编译文件和配置文件，生成目标应用的打包文件。上述方案，解决了仅通过目标应用的源代码生成打包文件时，仅考虑目标应用本身对目标应用运行的影响，而未考虑目标应用运行环境和配置文件等外部因素对目标应用运行的影响，使得对目标应用的检测存在一定误差的问题。本方案进一步提高了对目标应用检测的准确性。

实施例三

图3为本发明实施例三提供的一种应用检测方法的流程图，本实施例在上述实施例的基础上进行了优化，给出了将目标应用的项目信息和版本信息与目标应用的检测报告绑定存储的优选实施例。具体的，如图3所示，本实施例提供的应用检测方法可以包括：

S310、响应于目标应用的运行检测指令，调用本地虚拟容器，根据目标应用的源代码和配置文件，生成目标应用的打包文件。

S320、调用本地虚拟容器，安装打包文件，并运行目标应用。

S330、调用运行检测工具，对目标应用的运行过程进行检测。

S340、生成目标应用的运行检测报告。

其中，运行检测报告可以记录目标应用在运行过程中的运行情况，例如目标应用在运行过程中内存的释放情况。

具体的，在本地虚拟容器中调用运行检测工具，在目标应用的运行过程中，通过运行检测工具对检测数据在目标应用中的运行过程进行检测，获得目标应用的检测结果，并根据检测结果生成目标应用的检测报告，检测报告中记录了目标应用在运行过程中内存的释放情况，根据目标应用的检测报告确定目标应用是否存在故障。例如，若目标应用在运行过程中存在没有被释放的内存，则目标应用存在故障，可以根据未能释放的内存在目标应用程序中的位置对目标应用的故障进行定位。

可选的，生成目标应用的运行检测报告时，可以根据当前时间与检测开始时间之间的时长确定是否生成目标应用的运行检测报告，具体的，可以通过如下子步骤实现：

S3401、在当前时间与检测开始时间之间的时长满足设定时长的情况下，确定目标应用是否完成对测试数据的处理。

其中，检测开始时间是指测试数据输入安装在流水线运行环境中的目标应用中的时间，设定时长是指由用户预先设置的，保证测试数据可以在这一时长之内在目标应用中完整运行的时间长度。

具体的，可以预先设置一个时钟设备，用于记录检测开始时间，并实时记录当前时间，将当前时间与检测开始时间做差，得到计时信息，计时信息为当前时间与检测开始时间之间的时长。预先设置一个设定时长，将当前时间与检测开始时间之间的时长与设定时长进行比较。若当前时间与检测开始时间之间的时长小于设定时长，则确定目标应用未完成对测试数据的处理；若当前时间与检测开始时间之间的时长大于或等于设定时长，则确定目标应用已经完成对测试数据的处理。

示例性的，可以通过代码仓库在运行检测工具中增加一个检测逻辑，检测逻辑的内容是通过目标应用运行测试数据时，通过计时信息来确定测试数据是否运行到目标应用的终点，若通过计时信息确定测试数据运行到目标应用的终点，运行检测工具可以给本地虚拟容器发送一个SIGKILL信号，本地虚拟容器在接收到SIGKILL信号后终止运行目标应用，同时终止运行检测工具对目标应用的检测，运行检测工具中的故障检测指令会捕获到SIGKILL信号并输出目标应用的检测报告。例如，可以在目标应用开始运行时进行计时，计时60秒后开始运行检测逻辑，输出目标应用的检测报告。

S3402、若目标应用完成对测试数据的处理，则生成目标应用的运行检测报告。

具体的，若当前时间与检测开始时间之间的时长大于或等于设定时长，则根据测试数据在目标应用中的运行结果生成目标应用的运行检测报告。

优选的，在生成目标应用的运行检测报告的同时或之后，控制运行检测工具停止对目标应用的检测。

具体的，通过代码仓库在运行检测工具中添加停止检测的相关指令，在运行检测工具对检测数据在目标应用中的运行过程进行检测，并根据检测结果生成目标应用的运行检测报告的同时或之后，运行检测工具执行停止检测的相关指令，停止对目标应用的检测，并进一步的根据测试数据在目标应用中的运行结果生成目标应用的运行检测报告。

通过当前时间与检测开始时间之间的时长确定是否生成目标应用的运行检测报告，可以合理规划目标应用的运行时间和目标应用的运行检测报告生成时间，防止在检测完成之后目标应用继续运行导致的资源浪费问题。

S350、根据目标应用的项目信息和版本信息，生成运行检测报告的标识信息。

其中，目标应用的项目信息是指目标应用所属项目的项目属性；版本信息包括目标应用的版本号；运行检测报告的标识信息是指可以用于识别检测报告身份的标识。

具体的，提取目标应用的项目信息和版本信息，按照预设的标识生成指令，生成检测报告的标识信息。其中，标识信息可以是SHA值。可选的，还可以采用设定的哈希算法，对目标应用的项目信息和版本信息进行哈希运算，并将哈希值作为标识信息。

S360、将运行检测报告和标识信息进行绑定存储。

具体的，在目标应用的检测报告后，对目标应用的检测报告进行存储、分类和归档。在对目标应用的检测报告进行存储、分类和归档时，可以将运行检测报告和运行检测报告的标识信息进行绑定存储，以使项目维护人员在对目标应用进行分析、追踪和修复时，可以通过标识信息确定运行检测报告的项目信息和版本信息，方便项目维护人员对运行检测报告进行追踪。

示例性的，将检测报告通过FTP协议送到统一服务器进行存储，并根据目标应用的标识对目标应用的检测报告进行命名后归档，在归档时，可以在服务器内按“组/项目/版本/标识信息/”的形式进行归档。其中，组可以是目标应用所属的项目组别，可以根据目标应用的性质按照实际需求预先对目标应用进行分组。

本实施例提供的技术方案，在对目标应用进行检测后，生成目标应用的检测报告，并为运行检测报告生成标识信息，按照运行检测报告的标识信息为运行检测报告进行归档。上述方案，解决了无法对目标应用的检测结果进行记录，并且无法在后续过程中对目标应用的检测结果进行查询的问题。方便项目维护人员在后续需要对目标应用的检测结果进行追踪和分析维护时，可以通过运行检测报告的标识信息从服务器中提取出目标应用的运行检测报告。

实施例四

图4为本发明实施例四提供的一种应用检测方法的架构图，本实施例在上述实施例的基础上，提供了一种优选实例，具体由代码仓库和本地虚拟容器配合执行。本实施例中的代码仓库为Gitlab代码仓库，在应用检测的过程中，采用的持续集成工具为GitLab-CI，本地虚拟容器提供的虚拟环境是基于Linuxel7的Docker虚拟环境，即Docker VM。具体的，结合图4所示，应用检测具体过程如下：

开发人员将目标应用的代码输入到Gitlab仓中，并对Gitlab仓进行repo整改。目标应用如果涉及到多个Gitlab仓，在下载更新或固定tag时，必须逐个进入处理，处理繁琐且容易出现问题。所以针对这类情况，引入repo对Gitlab进行封装，将多个Gitlab仓进行集中管理。

进一步的，在Gitlab仓中添加持续集成工具CI，并为Gitlab-CI安装配置流水线任务运行环境，即基于Linuxel7的Docker VM。在Docker VM的环境下构建流水线运行环境，以便在流水线上进行Jobs build，即添加自定义的流水线任务，并编辑编译流水线任务相关代码。添加的流水线任务主要包括：Job-pack：打包任务；Job-memchk：故障检测任务；Job-store：检测报告存储任务。

在Docker VM上进行Jobs build时，执行Prepare env指令，即准备执行外部命令，本实施例中的外部命令为目标应用检测相关命令。通过make指令提取目标应用的编译文件和配置文件，即bin/config。Gitlab-CI调用Docker VM，通过Job-pack对目标应用的编译文件和配置文件进行RPM pack，即对目标应用的的编译文件和配置文件进行打包工作，生成目标应用的打包文件，即RPM打包文件。Gitlab-CI调用Docker VM，通过Job-memchk任务中的Install指令执行RPM打包文件安装工作，RPM打包文件装在Job-memchk任务的软件上，再通过通过Job-memchk任务中的valgrind指令执行目标应用的故障检测任务，并根据目标应用的检测结果生成report文件作为目标应用的运行检测报告。Gitlab-CI调用Docker VM，通过Job-store任务中的upload指令执行将目标应用的运行检测报告通过FTP协议送到统一服务器进行存储，并根据目标应用的标识对目标应用的检测报告进行命名后归档，在归档时，可以在FTP服务器内按“/FTP-HOME/Group/Repo/SHA/”的形式进行归档。

本实施例提供的技术方案，通过Gitlab仓建立目标应用故障检测的流水任务，并基于持续集成工具GitLab-CI实现自动化的目标应用的故障检测。解决了通过人工对目标应用进行故障检测时，目标应用检测效率低，且人工成本高的问题，提高了目标应用的检测效率，降低了人工成本。

实施例五

图5为本发明实施例五提供的一种应用检测装置的结构示意图，本实施例可适用于对目标应用进行检测的情况，如图5所示，该应用检测装置包括：打包文件生成模块510、目标应用运行模块520和目标应用运行模块530。

其中，打包文件生成模块510，用于响应于目标应用的运行检测指令，调用本地虚拟容器，根据目标应用的源代码和配置文件，生成目标应用的打包文件；

目标应用运行模块520，用于调用本地虚拟容器，安装打包文件，并运行目标应用；

目标应用检测模块530，用于调用运行检测工具，对目标应用的运行过程进行检测。

本实施例提供的技术方案，通过为目标应用建立运行检测指令，调用本地虚拟容器，根据目标应用生成目标应用的打包文件，并将目标应用的打包文件安装在调用虚拟容器的应用检测任务中，通过运行应用检测工具，在目标应用运行的过程中对目标程序进行检测，以检测目标应用是否存在故障。上述方案，解决了在应用检测过程中人工参与程度过高，随着应用规模的扩大，人工成本的投入会越来越高且人工对应用检测耗时过长，且人工对应用进行检测时存在检测误差，导致检测结果不精确的问题。本方案通过调用本地虚拟容器，通过构建运行检测指令和运行检测工具，将目标应用打包后安装在运行检测任务中，为目标应用提供应用检测环境，可以节约应用检测过程中的人工成本，提高了应用检测效率和应用检测的准确性。

其中，打包文件生成模块510，还包括：

编译文件生成单元，用于调用本地虚拟容器对所述目标应用的源代码进行编译，生成目标应用的编译文件；

文件打包单元，用于调用本地虚拟容器，根据目标应用的编译文件和配置文件，生成目标应用的打包文件。

其中，上述目标应用运行模块520还具体用于：

调用本地虚拟容器，控制目标应用对测试数据进行处理；

调用运行检测工具，对目标应用处理所述测试数据的运行过程进行检测。

进一步的，本实施例提供的应用检测装置，还包括：

运行检测报告生成模块，用于生成目标应用的运行检测报告；

标识信息生成模块，用于根据目标应用的项目信息和版本信息，生成运行检测报告的标识信息；

运行检测报告存储模块，用于将运行检测报告和标识信息进行绑定存储。

示例性的，上述运行检测报告生成模块还具体用于：

在当前时间与检测开始时间之间的时长满足设定时长的情况下，确定目标应用是否完成对测试数据的处理；

若目标应用完成对测试数据的处理，则生成目标应用的运行检测报告。

进一步的，上述运行检测报告生成模块还具体用于：

在生成目标应用的运行检测报告的同时或之后，控制运行检测工具停止对目标应用的检测。

本实施例提供的应用检测装置可适用于上述任意实施例提供的应用检测方法，具备相应的功能和有益效果。

实施例六

图6为本发明实施例六提供的一种电子设备的结构示意图，如图6所示，该电子设备包括处理器60、存储器61、输入装置62和输出装置63；电子设备中处理器60的数量可以是一个或多个，图6中以一个处理器60为例；电子设备中的处理器60、存储器61、输入装置62和输出装置63可以通过总线或其他方式连接，图6中以通过总线连接为例。

存储器61作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的应用检测方法对应的程序指令/模块。处理器60通过运行存储在存储器61中的软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现上述的应用检测方法。

存储器61可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器61可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器61可进一步包括相对于处理器60远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置62可用于接收输入的目标应用的相关数据，以及产生与电子设备的用户设置以及功能控制有关的应用检测相关参数输入。输出装置63可包括显示屏等显示设备。

本实施例提供的电子设备可适用于上述任意实施例提供的应用检测方法，具备相应的功能和有益效果。

实施例七

本发明实施例七还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种应用检测方法，该方法包括：

响应于目标应用的运行检测指令，调用本地虚拟容器，根据目标应用的源代码和配置文件，生成目标应用的打包文件；调用本地虚拟容器，安装打包文件，并运行目标应用；调用运行检测工具，对目标应用的运行过程进行检测。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (10)

1.一种应用检测方法，其特征在于，包括：

响应于目标应用的运行检测指令，调用本地虚拟容器，根据所述目标应用的源代码和配置文件，生成所述目标应用的打包文件；

调用所述本地虚拟容器，安装所述打包文件，并运行所述目标应用；

调用运行检测工具，对所述目标应用的运行过程进行检测。

2.根据权利要求1所述的方法，其特征在于，所述调用本地虚拟容器，根据所述目标应用的源代码和配置文件，生成所述目标应用的打包文件，包括：

调用本地虚拟容器对所述目标应用的源代码进行编译，生成所述目标应用的编译文件；

调用所述本地虚拟容器，根据所述目标应用的编译文件和配置文件，生成所述目标应用的打包文件。

3.根据权利要求1所述的方法，其中，所述调用运行检测工具，对所述目标应用的运行过程进行检测，包括：

调用所述本地虚拟容器，控制所述目标应用对测试数据进行处理；

调用运行检测工具，对所述目标应用处理所述测试数据的运行过程进行检测。

4.根据权利要求1所述的方法，其特征在于，还包括：

生成所述目标应用的运行检测报告；

根据所述目标应用的项目信息和版本信息，生成所述运行检测报告的标识信息；

将所述运行检测报告和所述标识信息进行绑定存储。

5.根据权利要求4所述的方法，其特征在于，所述生成所述目标应用的运行检测报告，包括：

在当前时间与检测开始时间之间的时长满足设定时长的情况下，确定所述目标应用是否完成对测试数据的处理；

若是，则生成所述目标应用的运行检测报告。

6.根据权利要求5所述的方法，其特征在于，还包括：

在生成所述目标应用的运行检测报告的同时或之后，控制所述运行检测工具停止对所述目标应用的检测。

7.一种应用检测装置，其特征在于，包括：

打包文件生成模块，用于响应于目标应用的运行检测指令，调用本地虚拟容器，根据所述目标应用的源代码和配置文件，生成所述目标应用的打包文件；

目标应用运行模块，用于调用所述本地虚拟容器，安装所述打包文件，并运行所述目标应用；

目标应用检测模块，用于调用运行检测工具，对所述目标应用的运行过程进行检测。

8.根据权利要求7所述的装置，其特征在于，所述打包文件生成模块，包括：

编译文件生成单元，用于调用本地虚拟容器对所述目标应用的源代码进行编译，生成所述目标应用的编译文件；

文件打包单元，用于调用所述本地虚拟容器，根据所述目标应用的编译文件和配置文件，生成所述目标应用的打包文件。

9.一种电子设备，其特征在于，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-6中任一所述的应用检测方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-6中任一所述的应用检测方法。

Images