一种应用故障的测试方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种应用故障的测试方法、装置、电子设备及存储介质。

背景技术

随着安卓系统的不断发展，业内需要对安卓系统进行系统测试，具体为通过自动化测试上位机进行系统测试，而测试过程中涉及到对应用发生故障现象的监控。

目前，主要通过ADB logcat抓取安卓系统的系统日志，然后进行关键字筛选，确定是否发生Crash或ANR问题。

但是，此方法的问题是抓取的系统日志产生的数据量巨大，测试方式相对比较复杂，且自动化测试的运行时间一般较长，从而使得测试效率较低。

发明内容

有鉴于此，本申请的目的在于提供一种应用故障的测试方法、装置、电子设备及存储介质，上位机通过生成并发送监控脚本至目标设备，以使目标设备通过监测工具运行监控脚本并得到运行结果，并在判断运行结果中存在目标故障时获取对应的故障信息以在界面上进行显示，避免了巨大的数据量的产生，降低了对目标设备中应用故障的测试的复杂度，且测试的时间较短，从而提高了测试效率。

第一方面，本申请实施例提供了一种应用故障的测试方法，应用于上位机，所述测试方法包括：

生成针对目标设备的监控脚本，并将所述监控脚本发送至所述目标设备，以使所述目标设备通过预先安装好的监测工具在系统后台静默运行所述监控脚本，并得到所述监控脚本的运行结果，将通过所述监测工具将所述运行结果发送至所述上位机；

接收到所述运行结果，并判断所述运行结果中是否存在目标故障对应的关键字；

若是，则确定所述目标设备发生该关键字对应的目标故障，根据所述运行结果获取对应的故障信息，并将所述故障信息在界面上进行显示。

在一种可能的实施方式中，所述生成针对目标设备的监控脚本，包括：

展示配置控件，并基于所述目标设备的监控需求在所述配置控件中确定针对所述目标设备的监控参数；

基于配置好的配置控件生成针对所述目标设备的监控脚本。

在一种可能的实施方式中，所述测试方法还包括：

检测所述目标设备是否安装有所述监测工具；

若否，则将所述监测工具的安装包发送至所述目标设备，以使所述目标设备安装上所述监测工具。

在一种可能的实施方式中，在所述目标设备通过预先安装好的监测工具在系统后台静默运行所述监控脚本之前，所述测试方法还包括：

获取目标指令；

基于所述目标指令调用所述预先安装好的监测工具。

在一种可能的实施方式中，在所述目标设备通过预先安装好的监测工具在系统后台静默运行所述监控脚本之后，在所述得到所述监控脚本的运行结果之前，所述测试方法还包括：

基于所述目标设备中的目标模块确定对应的目标测试；其中，所述目标测试的类型包括自动化测试和人工测试；不同的目标模块对应不同的目标测试的类型；

所述目标设备运行所述监控脚本以对进行所述目标测试的所述目标设备进行监控。

在一种可能的实施方式中，所述根据所述运行结果获取对应的故障信息，包括：

基于所述运行结果提取出发生目标故障的应用对应的应用信息；

基于所述关键字和所述应用信息确定对应的故障信息。

在一种可能的实施方式中，所述测试方法还包括：

基于预设的应用程序接口发送所述故障信息至目标群体。

第二方面，本申请实施例还提供了一种应用故障的测试装置，应用于上位机，所述测试装置包括：

监控模块，用于生成针对目标设备的监控脚本，并将所述监控脚本发送至所述目标设备，以使所述目标设备通过预先安装好的监测工具在系统后台静默运行所述监控脚本，并得到所述监控脚本的运行结果，将通过所述监测工具将所述运行结果发送至所述上位机；

判断模块，用于接收到所述运行结果，并判断所述运行结果中是否存在目标故障对应的关键字；

第一获取模块，用于若是，则确定所述目标设备发生该关键字对应的目标故障，根据所述运行结果获取对应的故障信息，并将所述故障信息在界面上进行显示。

在一种可能的实施方式中，所述监控模块，具体用于：

展示配置控件，并基于所述目标设备的监控需求在所述配置控件中确定针对所述目标设备的监控参数；

基于配置好的配置控件生成针对所述目标设备的监控脚本。

在一种可能的实施方式中，所述应用故障的测试装置，还包括：

检测模块，用于检测所述目标设备是否安装有所述监测工具；

安装模块，用于若否，则将所述监测工具的安装包发送至所述目标设备，以使所述目标设备安装上所述监测工具。

在一种可能的实施方式中，所述应用故障的测试装置，还包括：

第二获取模块，用于在所述目标设备通过预先安装好的监测工具在系统后台静默运行所述监控脚本之前，获取目标指令；

调用模块，用于基于所述目标指令调用所述预先安装好的监测工具。

在一种可能的实施方式中，所述应用故障的测试装置，还包括：

确定模块，用于在所述目标设备通过预先安装好的监测工具在系统后台静默运行所述监控脚本之后，在所述得到所述监控脚本的运行结果之前，基于所述目标设备中的目标模块确定对应的目标测试；其中，所述目标测试的类型包括自动化测试和人工测试；不同的目标模块对应不同的目标测试的类型；

运行模块，用于所述目标设备运行所述监控脚本以对进行所述目标测试的所述目标设备进行监控。

在一种可能的实施方式中，所述第一获取模块，具体用于：

基于所述运行结果提取出发生目标故障的应用对应的应用信息；

基于所述关键字和所述应用信息确定对应的故障信息。

在一种可能的实施方式中，所述应用故障的测试装置，还包括：

发送模块，用于基于预设的应用程序接口发送所述故障信息至目标群体。

第三方面，本申请实施例提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面任一项所述的应用故障的测试方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行第一方面任一项所述的应用故障的测试方法的步骤。

本申请实施例提供的一种应用故障的测试方法、装置、电子设备及存储介质，生成针对目标设备的监控脚本，并将监控脚本发送至目标设备，以使目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本，并得到监控脚本的运行结果，将通过监测工具将运行结果发送至上位机；接收到运行结果，并判断运行结果中是否存在目标故障对应的关键字；若是，则确定目标设备发生该关键字对应的目标故障，根据运行结果获取对应的故障信息，并将故障信息在界面上进行显示。本申请，上位机通过生成并发送监控脚本至目标设备，以使目标设备通过监测工具运行监控脚本并得到运行结果，并在判断运行结果中存在目标故障时获取对应的故障信息以在界面上进行显示，避免了巨大的数据量的产生，降低了对目标设备中应用故障的测试的复杂度，且测试的时间较短，从而提高了测试效率。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是根据本申请一个实施例的应用故障的测试方法的流程图；

图2是上位机确定监控参数的示意图；

图3是上位机显示故障信息的示意图；

图4是根据本申请另一个实施例的应用故障的测试方法的流程图；

图5是根据本申请另一个实施例的应用故障的测试方法的流程图；

图6是根据本申请另一个实施例的应用故障的测试方法的流程图；

图7是根据本申请另一个实施例的应用故障的测试方法的流程图；

图8是根据本申请另一个实施例的应用故障的测试方法的流程图；

图9是上位机和待测设备进行应用故障测试的示意图；

图10是根据本申请一个实施例的应用故障的测试装置的结构示意图；

图11是根据本申请一个实施例的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

考虑到随着安卓(Android)系统的不断发展，业内需要对安卓系统进行系统测试，具体为通过自动化测试上位机进行系统测试，往往通过ADB(Android Debug Bridge，命令行工具)连接的方式进行，而测试过程中涉及到对应用发生故障现象的监控，例如，安卓系统中常见的两种故障：Crash(系统服务崩溃)、ANR(应用无响应)。本领域人员可以理解的是，Monkey服务是安卓系统自带的一种自动化测试方法，它会随机的模拟发送各种按键、点击、滑动等用户事件来实现压力测试，业内一般都用Monkey服务进行随机的压力测试，Monkey服务有一个机制，就是在遇到应用Crash或ANR时会输出相应的信息。

目前，自动化测试上位机进行系统测试时，主要通过ADB logcat(安卓开发中常用的命令)抓取安卓系统的系统日志，然后进行关键字筛选，确定是否发生Crash或ANR问题。但是，此方法的问题是抓取的系统日志产生的数据量巨大，测试方式相对比较复杂，且自动化测试的运行时间一般较长，从而使得测试效率较低。

针对该问题，本申请提供了一种应用故障的测试方法、装置、电子设备及存储介质，上位机通过生成并发送监控脚本至目标设备，以使目标设备通过监测工具运行监控脚本并得到运行结果，并在判断运行结果中存在目标故障时获取对应的故障信息以在界面上进行显示，避免了巨大的数据量的产生，降低了对目标设备中应用故障的测试的复杂度，且测试的时间较短，从而提高了测试效率。

需要说明的是，本申请可以应用于各种操作系统，例如，安卓、IOS等，本申请对目标设备的测试即对搭载操作系统的目标设备的测试，这里以安卓系统为例进行描述，即对安卓系统的目标设备进行测试，但不构成对操作系统的限定，具体可根据实际情况进行设置。

图1是根据本申请一个实施例的应用故障的测试方法的流程图，应用于上位机，如图1所示，本申请实施例的应用故障的测试方法具体可包括：

S101，生成针对目标设备的监控脚本，并将监控脚本发送至目标设备，以使目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本，并得到监控脚本的运行结果，将通过监测工具将运行结果发送至上位机。

本申请实施例中，目标设备即待进行应用故障测试的设备，例如，车载中控娱乐系统(In-Vehicle Infotainment，IVI)，监控脚本即对目标设备进行监控的脚本，监测工具即目标设备上安装的用来监测的工具，例如，安卓系统的Monkey服务，上位机生成针对目标设备的监控脚本并发送至目标设备，目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本并得到监控脚本的运行结果，接着通过监测工具将运行结果发送至上位机，以供上位机进行后续处理。

需要说明的是，上位机为预先创建的用于对目标设备进行自动化测试的程序，上位机可以提供界面化的窗口供人员使用。可选地，上位机可以根据Python语言构建，例如，如图2所示。

还需要说明的是，在上位机生成针对目标设备的监控脚本并发送至目标设备之前，上位机需要通过预设的命令行工具ADB连接目标设备，在上位机和目标设备建立连接关系后，测试才能正常进行。

可以理解的是，目标设备通过监测工具在系统后台静默运行监控脚本，保证了不会影响到目标设备的界面显示及其他的功能实现。

S102，接收到运行结果，并判断运行结果中是否存在目标故障对应的关键字。

本申请实施例中，目标故障即目标设备发生的故障，不同的目标故障对应不同的关键字，例如，安卓系统常见的两种故障，Crash和ANR问题，Crash问题对应的关键字为“\CRASH”，ANR问题对应的关键字为“anr traces:”，上位机在接收到目标设备发来的运行结果后，进一步判断运行结果中是否存在目标故障对应的关键字即进行关键字筛选，以便后续通过判断结果进行对应的处理。

S103，若是，则确定目标设备发生该关键字对应的目标故障，根据运行结果获取对应的故障信息，并将故障信息在界面上进行显示。

本申请实施例中，上位机在对运行结果进行关键字筛选时，若判断得出断运行结果中存在目标故障对应的关键字即筛选出了关键字，则确定目标设备发生了该关键字对应的目标故障，并对运行结果进行进一步提取，即提取出对应的故障信息，并将故障信息在上位机的界面上进行显示。例如，上位机在运行结果中筛选出了关键字“\CRASH”，则表示该目标设备发生了Crash问题，并对运行结果提取出Crash问题对应的故障信息并显示在上位机的界面上提供测试人员进行查看或者处理，例如，如图3所示，右侧框中的信息即为故障信息。

本申请实施例提供的应用故障的测试方法，生成针对目标设备的监控脚本，并将监控脚本发送至目标设备，以使目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本，并得到监控脚本的运行结果，将通过监测工具将运行结果发送至上位机；接收到运行结果，并判断运行结果中是否存在目标故障对应的关键字；若是，则确定目标设备发生该关键字对应的目标故障，根据运行结果获取对应的故障信息，并将故障信息在界面上进行显示。本申请的应用故障的测试方法，上位机通过生成并发送监控脚本至目标设备，以使目标设备通过监测工具运行监控脚本并得到运行结果，并在判断运行结果中存在目标故障时获取对应的故障信息以在界面上进行显示，避免了巨大的数据量的产生，降低了对目标设备中应用故障的测试的复杂度，且测试的时间较短，从而提高了测试效率。

进一步的，如图4所示，上述实施例中的步骤S101中的“生成针对目标设备的监控脚本”，具体可包括以下步骤：

S401，展示配置控件，并基于目标设备的监控需求在配置控件中确定针对目标设备的监控参数。

本申请实施例中，配置控件即上位机界面上展示的用于参数配置的控件，上位机展示配置控件，并基于目标设备的监控需求在配置控件中确定针对目标设备的监控参数以对配置控件进行配置，例如，如图2所示，设置单次检查间隔和设置监控总时长等配置控件，在这些配置控件上可以确定对应的监控参数即单次检查间隔和监控总时长。

可选的，上位机响应于测试人员对配置控件的输入操作，可以确定针对目标设备的监控参数。例如，如图2所示，测试人员在设置单次检查间隔的配置控件中输入“5”，表示单次检查间隔为5秒，在设置监控总时长的配置控件中输入“12”，表示监控总时长为12小时，根据事件总次数(count)＝设置的监控总时长*3600/设置的单次检查间隔的公式，由此可以得出监控的总次数count＝12*3600/5＝8640次，表示需要每5秒监控一次，共计监控8640次，此外，在“出现问题后停止自动化测试”和“出现问题发送通知”的配置控件中选择确定，以此完成了对配置控件的配置。

S402，基于配置好的配置控件生成针对目标设备的监控脚本。

本申请实施例中，监控脚本符合目标设备的监测工具的格式要求，例如，符合monkey服务的格式要求，基于步骤S401配置好的配置控件自动生成针对目标设备的监控脚本，即根据配置控件生成对应的监控脚本。例如，如图2所示，根据设置的单次检查间隔、监控总时长以及出现问题后停止自动化测试、发送通知的配置，生成对应的监控脚本，该脚本表示监测工具会根据设定每隔5秒检查一次目标设备中是否有应用发生Crash或者ANR问题，可以监控8640次停止，如果出现问题则停止自动化测试并发送通知。

进一步的，如图5所示，本申请实施例的应用故障的测试方法还可包括以下步骤：

S501，检测目标设备是否安装有监测工具。

需要说明的是，考虑到目标设备有未预先安装监测工具的可能，所以需要对目标设备是否安装有监测工具进行检测。

本申请实施例中，上位机对目标设备是否安装有监测工具进行检测，并根据检测结果进行相应的处理，例如，上位机检查车载中控娱乐系统中是否预装有monkey服务。

S502，若否，则将监测工具的安装包发送至目标设备，以使目标设备安装上监测工具。

本申请实施例中，若检测目标设备未安装有监测工具，则将监测工具的安装包发送至目标设备，以使目标设备安装上监测工具。例如，如果上位机检查车载中控娱乐系统中未预装有monkey服务，则将monkey服务相应的服务组件安装至车载中控娱乐系统。

进一步的，如图6所示，在上述实施例中的步骤S101中的“目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本”之前，本申请实施例的应用故障的测试方法还可包括以下步骤：

S601，获取目标指令。

本申请实施例中，目标指令即用来调用监测工具的指令，例如，ADB指令，对目标指令进行获取，以进行后续处理。

S602，基于目标指令调用预先安装好的监测工具。

本申请实施例中，根据步骤S601获取的目标指令对目标设备上预先安装好的监测工具进行调用。例如，上位机根据ADB指令调用目标设备的monkey服务。

需要说明的是，在目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本之前，上位机需要先使用目标指令来调用目标设备上的监测工具，这样才能保证监控脚本的正常运行。

进一步的，如图7所示，在上述实施例中的步骤S101中的“目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本”之前，“得到监控脚本的运行结果”之后，本申请实施例的应用故障的测试方法还可包括以下步骤：

S701，基于目标设备中的目标模块确定对应的目标测试。

本申请实施例中，目标模块即目标设备中的模块，例如，音乐模块、设置模块等，目标测试的类型包括自动化测试和人工测试，不同的目标模块对应不同的目标测试的类型，例如，对于音乐模块，可以进行自动化测试，对弈设置模块，可以进行人工测试。

需要说明的是，在监控开始后即监测工具运行监控脚本后，可以对目标设备进行测试，例如，自动化测试或者人工测试。

S702，目标设备运行监控脚本以对进行目标测试的目标设备进行监控。

本申请实施例中，目标设备运行监控脚本后，对进行目标测试的目标设备进行监控，以后续得到监控脚本的运行结果。

进一步的，如图8所示，上述实施例中的步骤S103中的“根据运行结果获取对应的故障信息”，具体还可包括以下步骤：

S801，基于运行结果提取出发生目标故障的应用对应的应用信息。

本申请实施例中，应用信息即发生目标故障的应用的信息，例如，应用包名等，上位机在对运行结果进行关键字筛选时，若判断得出断运行结果中存在目标故障对应的关键字即筛选出了关键字，则基于监控脚本的运行结果提取出发生目标故障的应用对应的应用信息。例如，在判断出目标设备发生Crash问题时，上位机对监测工具发送的运行结果提取出发生Crash问题这个故障的应用的信息，例如，发生Crash问题的应用的包名。S802，基于关键字和应用信息确定对应的故障信息。

本申请实施例中，基于上述实施例中筛选出的关键字和步骤S801提取出的发生目标故障的应用对应的应用信息，可以确定对应的故障信息。例如，如图3所示，故障信息包括问题类型、出现问题的应用包名(Package)、错误信息等。

进一步的，本申请实施例的应用故障的测试方法还可包括以下步骤：

基于预设的应用程序接口发送故障信息至目标群体。

本申请实施例中，可以基于预设的应用程序接口发送故障信息至目标群体。需要说明的是，应用程序接口(API)可以是互联网平台的开放应用程序接口，例如，钉钉的开放API，上位机基于钉钉的开放API，可以实现在部门的群组中自动化发送故障信息并@对应人员，以提醒对应人员及时处理。

为清楚地说明本申请实施例的应用故障的测试方法，下面结合图9进行具体示例描述。

如图9所示，上位机通过ADB与Android设备(待测设备)即目标设备连接，上位机的界面上展示配置控件以设置监控参数，在设置好监控参数后自动生成监控脚本，并调用Android设备的monkey服务运行监控脚本以进行监控，接着对Android设备进行自动化测试或者人工手动测试，monkey服务将监控到的信息即运行结果输出至上位机，上位机对该信息进行关键之筛选，进行问题定点，来确定发生问题的应用等，最后上位机显示问题错误信息并通过钉钉的API自动发送消息至测试人员。

图10是根据本申请一个实施例的应用故障的测试装置的流程图，应用于上位机，如图10所示，本申请实施例的应用故障的测试装置1000，具体可包括：

监控模块1001，用于生成针对目标设备的监控脚本，并将监控脚本发送至目标设备，以使目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本，并得到监控脚本的运行结果，将通过监测工具将运行结果发送至上位机。

判断模块1002，用于接收到运行结果，并判断运行结果中是否存在目标故障对应的关键字。

第一获取模块1003，用于若是，则确定目标设备发生该关键字对应的目标故障，根据运行结果获取对应的故障信息，并将故障信息在界面上进行显示。

在一种可能的实施方式中，监控模块1001，具体用于：

展示配置控件，并基于目标设备的监控需求在配置控件中确定针对目标设备的监控参数；

基于配置好的配置控件生成针对目标设备的监控脚本。

在一种可能的实施方式中，应用故障的测试装置1000，还包括：

检测模块，用于检测目标设备是否安装有监测工具；

安装模块，用于若否，则将监测工具的安装包发送至目标设备，以使目标设备安装上监测工具。

在一种可能的实施方式中，应用故障的测试装置1000，还包括：

第二获取模块，用于在目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本之前，获取目标指令；

调用模块，用于基于目标指令调用预先安装好的监测工具。

在一种可能的实施方式中，应用故障的测试装置1000，还包括：

确定模块，用于在目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本之后，在得到监控脚本的运行结果之前，基于目标设备中的目标模块确定对应的目标测试；其中，目标测试的类型包括自动化测试和人工测试；不同的目标模块对应不同的目标测试的类型；

运行模块，用于目标设备运行监控脚本以对进行目标测试的目标设备进行监控。

在一种可能的实施方式中，第一获取模块1003，具体用于：

基于运行结果提取出发生目标故障的应用对应的应用信息；

基于关键字和应用信息确定对应的故障信息。

在一种可能的实施方式中，应用故障的测试装置1000，还包括：

发送模块，用于基于预设的应用程序接口发送故障信息至目标群体。

本申请实施例提供的应用故障的测试装置，生成针对目标设备的监控脚本，并将监控脚本发送至目标设备，以使目标设备通过预先安装好的监测工具在系统后台静默运行监控脚本，并得到监控脚本的运行结果，将通过监测工具将运行结果发送至上位机；接收到运行结果，并判断运行结果中是否存在目标故障对应的关键字；若是，则确定目标设备发生该关键字对应的目标故障，根据运行结果获取对应的故障信息，并将故障信息在界面上进行显示。本申请的应用故障的测试装置，上位机通过生成并发送监控脚本至目标设备，以使目标设备通过监测工具运行监控脚本并得到运行结果，并在判断运行结果中存在目标故障时获取对应的故障信息以在界面上进行显示，避免了巨大的数据量的产生，降低了对目标设备中应用故障的测试的复杂度，且测试的时间较短，从而提高了测试效率。

如图11所示，本申请实施例提供的一种电子设备1100，包括：处理器1101、存储器1102和总线，所述存储器1102存储有所述处理器1101可执行的机器可读指令，当电子设备运行时，所述处理器1101与所述存储器1102之间通过总线通信，所述处理器1101执行所述机器可读指令，以执行如上述应用故障的测试方法的步骤。

具体地，上述存储器1102和处理器1101能够为通用的存储器和处理器，这里不做具体限定，当处理器1101运行存储器1102存储的计算机程序时，能够执行上述应用故障的测试方法。

对应于上述应用故障的测试方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述应用故障的测试方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述部署方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。