CN106294108A - 应用程序测试方法及装置 - Google Patents

Abstract

本发明公开了一种应用程序测试方法及装置，属于计算机技术领域。所述方法应用于运行有互相独立的测试应用程序和被测应用程序的设备中；该方法包括：通过测试应用程序获取由设备的操作系统记录的错误记录信息；根据错误记录信息检测被测应用程序是否发生目标类型的错误；若被测应用程序发生目标类型的错误，则通过测试应用程序获取与目标类型的错误对应的场景信息。本发明解决了相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题；既无需在被测应用程序中集成测试应用程序，也无需修改被测应用程序的配置文件，充分避免了对被测应用程序产生上述不利影响。

Description

应用程序测试方法及装置

技术领域

本发明涉及计算机技术领域，特别涉及一种应用程序测试方法及装置。

背景技术

为了对应用程序在运行过程中可能发生的错误进行检测，一些程序开发商或者测试平台采用在应用程序中集成SDK(Software Development Kit，软件开发工具包)的方式，该集成于应用程序中的SDK用于实现错误检测和上报功能。

以对被测应用程序在运行过程中可能发生的Crash(崩溃)类型的错误进行检测为例，在相关技术中，技术人员预先开发用于实现Crash类型的错误检测和上报功能的SDK，然后将该SDK集成到被测应用程序中，并修改被测应用程序的配置文件以确保该SDK能够正常运行。在被测应用程序被用户下载安装并使用之后，集成于被测应用程序中的SDK会检测该被测应用程序是否发生Crash类型的错误，并将相应的检测结果和测试数据上报给测试服务器。

然而，上述技术至少存在如下问题：第一，在被测应用程序中集成SDK将会导致被测应用程序的文件过大，对用户下载产生不利影响；第二，修改被测应用程序的配置文件会给被测应用程序带来一些安全风险。

发明内容

为了解决相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题，本发明实施例提供了一种应用程序测试方法及装置。所述技术方案如下：

第一方面，提供了一种应用程序测试方法，应用于运行有测试应用程序和被测应用程序的设备中，该测试应用程序和被测应用程序之间互相独立，该方法包括：

通过测试应用程序获取由设备的操作系统记录的错误记录信息；

根据错误记录信息检测被测应用程序是否发生目标类型的错误；

若被测应用程序发生目标类型的错误，则通过测试应用程序获取与目标类型的错误对应的场景信息，该场景信息用于指示发生目标类型的错误时的设备状况和错误情况。

第二方面，提供了一种应用程序测试装置，应用于运行有测试应用程序和被测应用程序的设备中，该测试应用程序和被测应用程序之间互相独立，该装置包括：

信息获取模块，用于通过测试应用程序获取由设备的操作系统记录的错误记录信息；

错误检测模块，用于根据错误记录信息检测被测应用程序是否发生目标类型的错误；

场景信息获取模块，用于当被测应用程序发生目标类型的错误时，通过测试应用程序获取与目标类型的错误对应的场景信息，该场景信息用于指示发生目标类型的错误时的设备状况和错误情况。

本发明实施例提供的技术方案带来的有益效果包括：

通过独立的测试应用程序对被测应用程序进行错误检测；解决了相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题；既无需在被测应用程序中集成测试应用程序，也无需修改被测应用程序的配置文件，达到了充分避免对被测应用程序产生不利影响的技术效果。

附图说明

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

图1是本发明实施例所涉及的一种实施环境的示意图；

图2是本发明一个实施例提供的应用程序测试方法的流程图；

图3是本发明另一实施例提供的应用程序测试方法的流程图；

图4是本发明另一实施例所涉及的一种时段分布的示意图；

图5是本发明另一实施例所涉及的一种检测过程的流程图；

图6是本发明一个实施例提供的应用程序测试装置的框图；

图7是本发明另一实施例提供的应用程序测试装置的框图；

图8是本发明一个实施例提供的终端的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

请参考图1，其示出了本发明实施例所涉及的一种实施环境的示意图。该实施环境可以包括至少一个终端120和测试平台140。其中：

终端120中运行有测试应用程序和被测应用程序，测试应用程序用于对被测应用程序进行错误检测。在本发明实施例中，测试应用程序主要对被测应用程序进行Crash类型的错误检测和/或ANR(Application Not Responding，应用程序无响应)类型的错误检测。测试应用程序和被测应用程序之间互相独立。也即，测试应用程序并未集成于被测应用程序中。测试应用程序可以是一个独立的插件或者一个独立的应用程序。终端120可以是手机、平板电脑、电子书阅读器、多媒体播放器、膝上型便携计算机、台式计算机、可穿戴智能设备、智能家居设备等等。

终端120可通过无线网络或者有线网络与测试平台140相连。

测试平台140可以是被测应用程序的开发商提供的测试平台，也可以是用于提供测试外包服务的第三方服务商提供的测试平台。测试平台140中可部署有至少一台用于收集测试结果的数据分析设备。例如，该数据分析设备可以是计算机或者服务器。在终端120与测试平台140之间的网络连接正常的情况下，终端120可将相关的测试结果上报给测试平台140，以便于技术人员对测试结果进行分析和处理，找出错误发生的原因。

另外，在一种可能的应用场景中，终端120可以是基于Android(安卓)操作系统的终端。相应地，被测应用程序是Android应用程序。

请参考图2，其示出了本发明一个实施例提供的应用程序测试方法的流程图。该应用程序测试方法应用于运行有测试应用程序和被测应用程序的设备中。例如，该设备可以是图1所示实施环境中的终端120。测试应用程序和被测应用程序之间互相独立。该应用程序测试方法可以包括如下几个步骤：

步骤202，通过测试应用程序获取由设备的操作系统记录的错误记录信息。

步骤204，根据错误记录信息检测被测应用程序是否发生目标类型的错误。

步骤206，若被测应用程序发生目标类型的错误，则通过测试应用程序获取与目标类型的错误对应的场景信息，该场景信息用于指示发生目标类型的错误时的设备状况和错误情况。

综上所述，本实施例提供的应用程序测试方法，通过独立的测试应用程序对被测应用程序进行错误检测；解决了相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题；既无需在被测应用程序中集成测试应用程序，也无需修改被测应用程序的配置文件，达到了充分避免对被测应用程序产生不利影响的技术效果。

请参考图3，其示出了本发明另一实施例提供的应用程序测试方法的流程图。该应用程序测试方法应用于运行有测试应用程序和被测应用程序的设备中。例如，该设备可以是图1所示实施环境中的终端120。测试应用程序和被测应用程序之间互相独立。该应用程序测试方法可以包括如下几个步骤：

步骤301，通过测试应用程序获取由设备的操作系统记录的错误记录信息。

在设备运行的过程中，设备的操作系统会记录系统服务的状态信息和系统日志信息。其中，系统服务的状态信息中包含设备中运行的各个应用程序的运行状态信息。例如，该运行状态信息中包括发生Crash类型的错误的应用程序的进程名以及相应的错误发生时间等信息。系统日志信息中包含用于记录各个应用程序是否发生ANR错误的ANR日志信息。例如，该ANR日志信息中包括发生ANR类型的错误的应用程序的进程名以及相应的错误发生时间等信息。

在本实施例中，测试应用程序利用设备的操作系统记录的上述系统服务的状态信息和/或系统日志信息，对被测应用程序进行错误检测。

在一种可能的实施方式中，以Android操作系统为例，测试应用程序可采用调用Android操作系统提供的dumpsys activity命令的方式获取系统服务的状态信息。

步骤302，根据错误记录信息检测被测应用程序是否发生目标类型的错误。

测试应用程序获取到错误记录信息之后，也即获取到系统服务的状态信息和/或系统日志信息之后，测试应用程序根据该错误记录信息对被测应用程序进行错误检测。

具体来讲，在本实施例中，分如下两种情况对被测应用程序进行错误检测。

第一，当错误记录信息包括系统服务的状态信息时，目标类型的错误包括Crash类型的错误。也即，测试应用程序根据系统服务的状态信息检测被测应用程序是否发生Crash类型的错误。在上文已经介绍，系统服务的状态信息中记录有发生Crash类型的错误的应用程序的进程名以及相应的错误发生时间等信息，因此测试应用程序可根据被测应用程序的进程名检测该被测应用程序是否发生Crash类型的错误。

第二，当错误记录信息包括系统日志信息时，目标类型的错误包括ANR类型的错误。也即，测试应用程序根据系统日志信息检测被测应用程序是否发生ANR类型的错误。在上文已经介绍，系统日志信息的ANR日志信息中记录有发生ANR类型的错误的应用程序的进程名以及相应的错误发生时间等信息，因此测试应用程序可根据被测应用程序的进程名检测该被测应用程序是否发生ANR类型的错误。

步骤303，若被测应用程序发生目标类型的错误，则通过测试应用程序获取与目标类型的错误对应的场景信息。

其中，场景信息用于指示发生目标类型的错误时的设备状况和错误情况。场景信息可以包括诸如错误类型、错误发生时间之类的错误情况信息，以及诸如设备的机型信息、网络连接状况信息、存储卡使用状况信息、内存使用状况信息、CPU(Central Processing Unit，中央处理器)使用状况信息、屏幕截图信息、操作系统信息、屏幕分辨率信息之类的设备状况信息。在实际应用中，可根据实际测试需求预先设定所需获取的场景信息，本实施例对此不作具体限定。当目标类型的错误包括Crash类型的错误时，测试应用程序可从系统服务的状态信息中相应的获取错误情况信息；当目标类型的错误包括ANR类型的错误时，测试应用程序可从系统日志信息中获取相应的错误情况信息。另外，设备状况信息可采用调用相关命令或接口的方式进行获取。

测试应用程序在获取所需的场景信息之后，需要向相应的测试平台进行上报。在本实施例中，以测试应用程序向数据分析设备上报场景信息为例。该数据分析设备可以是部署于测试平台中的计算机或者服务器。可选地，测试应用程序在向数据分析设备上报测试数据之前，执行如下步骤304。

步骤304，判断当前网络状况是否满足数据上报条件。

测试应用程序判断当前网络状况是否满足数据上报条件。测试应用程序可通过检测当前与数据分析设备间的网络连接是否正常以及检测当前网速是否满足数据传输需求，来判断当前网络状况是否满足数据上报条件。在一种可能的实施方式中，测试应用程序可首先检测当前与数据分析设备间的网络连接是否正常，并在检测结果为正常的情况下继续检测当前网速是否达到预设阈值，若当前网速达到预设阈值，则确认当前网络状况满足数据上报条件。

若当前网络状况满足数据上报条件，则测试应用程序执行下述步骤304；否则，测试应用程序执行下述步骤306。

步骤305，向数据分析设备自动发送场景信息。

在当前网络状况满足数据上报条件的情况下，测试应用程序向数据分析设备自动发送场景信息。相应地，数据分析设备接收并保存场景信息，以便于对场景信息进行分析和处理，以确定出错误发生的原因。

步骤306，将场景信息保存至本地。

在当前网络状况不满足数据上报条件的情况下，测试应用程序将场景信息保存至本地，也即将场景信息保存至设备的存储器中。待后续网络状况满足数据上报条件的情况下，测试应用程序再将该场景数据自动发送给数据分析设备。例如，测试应用程序可每隔预定时间间隔检测当前网络状况是否满足数据上报条件，并在检测出满足数据上报条件的情况下主动向数据分析设备发送之前未发送的场景信息。当然，在其它可能的实施方式中，也可由人工将未上报的场景信息上传至数据分析设备。

综上所述，本实施例提供的应用程序测试方法，通过独立的测试应用程序对被测应用程序进行错误检测；解决了相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题；既无需在被测应用程序中集成测试应用程序，也无需修改被测应用程序的配置文件，达到了充分避免对被测应用程序产生不利影响的技术效果。

另外，本实施例提供的应用程序测试方法，还通过判断当前网络状况是否满足数据上报条件，并在当前网络状况不满足数据上报条件的情况下将场景信息保存至本地，对于一些无网络或弱网络的特殊测试场景，可以避免测试结果的丢失。

另外，在灵活性方面，由于测试应用程序独立于被测应用程序，因此测试应用程序可以支持对设备中安装的任意应用程序进行错误检测，更为灵活方便地切换被测目标。

另外，本实施例提供的应用程序测试方法，不仅实现了Crash类型的错误检测，还实现了ANR类型的错误检测，扩展了错误检测范围，提高了测试效果。

需要补充说明的一点是，在一种可能的实施方式中，对被测应用程序进行检测的过程包括依次进行的n轮检测流程，n为正整数。其中，每一轮检测流程包括：睡眠时段以及位于睡眠时段之后的检测时段。结合参考图4，其示出了上述检测过程所涉及的一种时段分布的示意图。如图4所示，每一轮检测流程包括睡眠时段41(图中以无填充线框表示)以及位于睡眠时段41之后的检测时段42(图中以有填充线框表示)。各个睡眠时段41的时长是预先配置为。可选地，配置各个睡眠时段41的时长相等(如2s、5s等)，以确保错误检测的及时性。各个检测时段42的时长是由实际检测过程中所消耗的时间而确定的，因此各个检测时段42的时长是动态变化的。

在每一轮检测流程的睡眠时段内，测试应用程序进入睡眠状态；在每一轮检测流程的检测时段内，测试应用程序执行上述图3所示实施例中的各个步骤完成对测试应用程序的一轮检测。

具体来讲，在当前一轮的检测流程的检测时段内，测试应用程序根据错误记录信息检测被测应用程序在检测时间窗口内是否发生目标类型的错误。其中，在当前一轮检测流程为第1轮检测流程时，检测时间窗口包括第1轮检测流程的睡眠时段；在当前一轮检测流程为第i轮检测流程时，检测时间窗口包括第i-1轮检测流程的检测时段和第i轮检测流程的睡眠时段，i≥2。

结合参考图5，其示出了测试应用程序采用n轮检测流程对被测应用程序进行错误检测所涉及的流程图，该检测过程可包括如下几个步骤：

步骤51，测试应用程序初始化设置检测时间窗口time_span＝time_span0。

其中，time_span即为检测时间窗口对应的时长。初始化时，将time_span设置为预设值time_span0，该预设值time_span0也是各个睡眠时段的时长。

步骤52，测试应用程序记录当前时间t1为当前一轮的检测流程的开始时间。

步骤53，测试应用程序获取由设备的操作系统记录的错误记录信息。

若对Crash类型的错误进行检测，则测试应用程序获取系统服务的状态信息；若对ANR类型的错误进行检测，则测试应用程序获取系统日志信息。

步骤54，测试应用程序根据错误记录信息检测被测应用程序在检测时间窗口内是否发生目标类型的错误。

检测时间窗口所对应的时间区间为[t1-time_span，t1]，t1-time_span为检测时间窗口的起始时刻，t1为检测时间窗口的结束时刻。

若被测应用程序在检测时间窗口内发生目标类型的错误，则测试应用程序执行下述步骤55；否则，测试应用程序执行下述步骤60。

另外，步骤54存在如下两种可能的情况。

在第一种情况下，错误记录信息包括系统服务的状态信息，步骤54可以包括如下几个子步骤：

1，从系统服务的状态信息中解析获取发生目标类型的错误的应用程序的标识以及错误发生时间。

在第一种情况下，目标类型的错误即为Crash类型的错误。应用程序的标识可以是进程号。

2，检测被测应用程序是否符合预定条件。

其中，预定条件是指发生目标类型的错误的应用程序的标识中包含被测应用程序的标识，且错误发生时间在检测时间窗口内。

3，若被测应用程序符合预定条件，则确定被测应用程序在检测时间窗口内发生目标类型的错误。

相应地，若被测应用程序不符合预定条件，则确定被测应用程序在检测时间窗口内未发生目标类型的错误。

在第二种情况下，错误记录信息包括系统日志信息，步骤54可以包括如下几个子步骤：

1，获取系统日志信息对应的创建时间。

2，检测该创建时间是否在检测时间窗口内。

3，若该创建时间在检测时间窗口内，则从系统日志信息中解析获取发生目标类型的错误的应用程序的标识。

在第二种情况下，目标类型的错误即为ANR类型的错误。

另外，若该创建时间不在检测时间窗口内，则说明包括被测应用程序在内的所有应用程序在检测时间窗口内均未发生ANR类型的错误，则可确定被测应用程序在检测时间窗口内未发生目标类型的错误。

4，检测发生目标类型的错误的应用程序的标识中是否包含被测应用程序的标识。

应用程序的标识可以是进程号。

5，若发生目标类型的错误的应用程序的标识中包含被测应用程序的标识，则确定被测应用程序在检测时间窗口内发生目标类型的错误。

相应地，若发生目标类型的错误的应用程序的标识中不包含被测应用程序的标识，则确定被测应用程序在检测时间窗口内未发生目标类型的错误。

需要说明的一点是，在对被测应用程序进行ANR类型的错误检测时，通过检测系统日志信息对应的创建时间是否在检测时间窗口内，并在检测结果为是的情况下再进一步执行解析系统日志信息的操作，可以避免每一轮检测流程都去解析系统日志信息，有利于减少系统的计算和处理开销。

步骤55，测试应用程序获取与目标类型的错误对应的场景信息。

其中，场景信息用于指示发生目标类型的错误时的设备状况和错误情况。场景信息可以包括诸如错误类型、错误发生时间之类的错误情况信息，以及诸如设备的机型信息、网络连接状况信息、存储卡使用状况信息、内存使用状况信息、CPU使用状况信息、屏幕截图信息、操作系统信息、屏幕分辨率信息之类的设备状况信息。

步骤56，测试应用程序将场景信息保存至本地。

步骤57，测试应用程序判断当前网络状况是否满足数据上报条件。

若当前网络状况满足数据上报条件，则测试应用程序执行下述步骤58；否则，测试应用程序执行下述步骤59。

步骤58，测试应用程序向数据分析设备自动发送场景信息，并记录场景信息的上报状态为已上报。

在步骤58之后，测试应用程序执行下述步骤60。

步骤59，测试应用程序记录场景信息的上报状态为未上报。

在步骤59之后，测试应用程序执行下述步骤60。

需要说明的一点是，在步骤55之后，测试应用程序直接将场景信息保存至本地，可以确保场景信息不会丢失。当然，在其它可能的实施方式中，在步骤55之后，测试应用程序可以先执行步骤57，并在判断结果为当前网络状况不满足数据上报条件的情况下，将场景信息保存至本地；在判断结果为当前网络状况满足数据上报条件的情况下，直接将场景信息自动发送给目标设备。

步骤60，测试应用程序记录当前时间t2为当前一轮的检测流程的结束时间。

步骤61，测试应用程序进入下一轮检测流程的睡眠时段，并更新检测时间窗口time_span＝time_span0+(t2-t1)。

其中，睡眠时段的时长为预设值time_span0。因此，下一轮检测流程的睡眠时段对应的时间区间为[t2，t2+time_span0]，t2为下一轮检测流程的睡眠时段的起始时刻，t2+time_span0为下一轮检测流程的睡眠时段的结束时刻。

需要说明的一点是，在本实施例中，每一轮检测流程过后都会动态调整检测时间窗口，以使得在下一轮检测流程中能够将当前一轮的检测流程的检测时段内可能发生的目标类型的错误也检测出来，充分提高了错误检测的准确度。

在下一轮检测流程的睡眠时段结束时，测试应用程序再次执行上述步骤52，进入下一轮检测流程的检测时段。

综上所述，测试应用程序采用n轮检测流程对被测应用程序进行错误检测，提高了错误检测和测试结果采集的实时性和效率。

还需要补充说明的一点是，测试应用程序的运行/停止可以灵活配置。在一种可能的实施方式中，可以采用设定参数的方式。例如，可以为测试应用程序设定启动标识，当启动标识为1时，指示启动运行测试应用程序，当启动标识为0时，指示停止运行测试应用程序。当测试应用程序采用n轮检测流程对被测应用程序进行错误检测时，在每一轮检测流程之前，通过检测启动标识确定测试应用程序的运行/停止。在另一种可能的实施方式中，也可以采用监听被测应用程序启动和关闭状态的方式。例如，当监听到被测应用程序启动时，运行测试应用程序；当监听到被测应用程序关闭时，停止运行测试应用程序。当然，并不限定其它可能的实施方式。

还需要补充说明的一点是，在其它可能的实施方式中，测试应用程序也可获取系统debug日志或者其它日志信息，根据获取到的系统debug日志或者其它日志信息检测被测应用程序是否发生Crash类型的错误。或者，在其它可能的实施方式中，由于被测应用程序在发生Crash类型的错误和/或ANR类型的错误时，设备的UI(User Interface，用户界面)上会显示相应的控件，因此测试应用程序也可采集设备的UI上显示的控件的类型或属性信息，根据采集的控件的类型或属性信息检测被测应用程序是否发生Crash类型的错误和/或ANR类型的错误。

还需要补充说明的一点是，在其它可能的实施方式中，测试应用程序在获取错误记录信息之后，还可以先把获取到的错误记录信息保存下来，并不实时对其进行分析以确定被测应用程序是否发生目标类型的错误。测试应用程序可以后续在设备本地对存储的错误记录信息进行分析以确定被测应用程序是否发生目标类型的错误。或者，测试应用程序也可将错误记录信息直接上报给测试平台，在测试平台侧对该错误记录信息进行分析和处理。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

请参考图6，其示出了本发明一个实施例提供的应用程序测试装置的框图。该应用程序测试装置应用于运行有测试应用程序和被测应用程序的设备中。例如，该设备可以是图1所示实施环境中的终端120。测试应用程序和被测应用程序之间互相独立。该应用程序测试装置可以包括：信息获取模块610、错误检测模块620和场景信息获取模块630。

信息获取模块610，用于通过测试应用程序获取由设备的操作系统记录的错误记录信息。

错误检测模块620，用于根据错误记录信息检测被测应用程序是否发生目标类型的错误。

场景信息获取模块630，用于当被测应用程序发生目标类型的错误时，通过测试应用程序获取与目标类型的错误对应的场景信息，该场景信息用于指示发生目标类型的错误时的设备状况和错误情况。

综上所述，本实施例提供的应用程序测试装置，通过独立的测试应用程序对被测应用程序进行错误检测；解决了相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题；既无需在被测应用程序中集成测试应用程序，也无需修改被测应用程序的配置文件，达到了充分避免对被测应用程序产生不利影响的技术效果。

请参考图7，其示出了本发明另一实施例提供的应用程序测试装置的框图。该应用程序测试装置应用于运行有测试应用程序和被测应用程序的设备中。例如，该设备可以是图1所示实施环境中的终端120。测试应用程序和被测应用程序之间互相独立。该应用程序测试装置可以包括：信息获取模块610、错误检测模块620和场景信息获取模块630。

信息获取模块610，用于通过测试应用程序获取由设备的操作系统记录的错误记录信息。

错误检测模块620，用于根据错误记录信息检测被测应用程序是否发生目标类型的错误。

场景信息获取模块630，用于当被测应用程序发生目标类型的错误时，通过测试应用程序获取与目标类型的错误对应的场景信息，该场景信息用于指示发生目标类型的错误时的设备状况和错误情况。

可选地，当错误记录信息包括系统服务的状态信息时，目标类型的错误包括Crash类型的错误；和/或，

当错误记录信息包括系统日志信息时，目标类型的错误包括ANR类型的错误。

可选地，对被测应用程序进行检测的过程包括依次进行的n轮检测流程，每一轮检测流程包括：睡眠时段以及位于睡眠时段之后的检测时段，n为正整数。

相应地，错误检测模块620，具体用于在当前一轮的检测流程的检测时段内，根据错误记录信息检测被测应用程序在检测时间窗口内是否发生目标类型的错误。

其中，在当前一轮检测流程为第1轮检测流程时，检测时间窗口包括第1轮检测流程的睡眠时段；在当前一轮检测流程为第i轮检测流程时，检测时间窗口包括第i-1轮检测流程的检测时段和第i轮检测流程的睡眠时段，i≥2。

可选地，错误记录信息包括系统服务的状态信息。

相应地，错误检测模块620，包括：信息解析单元620a、条件检测单元620b和第一确定单元620c。

信息解析单元620a，用于在当前一轮检测流程的检测时段内，从系统服务的状态信息中解析获取发生目标类型的错误的应用程序的标识以及错误发生时间。

条件检测单元620b，用于检测被测应用程序是否符合预定条件；其中，预定条件是指发生目标类型的错误的应用程序的标识中包含被测应用程序的标识，且错误发生时间在检测时间窗口内。

第一确定单元620c，用于当被测应用程序符合预定条件时，确定被测应用程序在检测时间窗口内发生目标类型的错误。

可选地，错误记录信息包括系统日志信息。

相应地，错误检测模块620，包括：时间获取单元620d、时间检测单元620e、标识获取单元620f、标识检测单元620g和第二确定单元620h。

时间获取单元620d，用于在当前一轮检测流程的检测时段内，获取系统日志信息对应的创建时间。

时间检测单元620e，用于检测创建时间是否在检测时间窗口内。

标识获取单元620f，用于当创建时间在检测时间窗口内时，从系统日志信息中解析获取发生目标类型的错误的应用程序的标识。

标识检测单元620g，用于检测发生目标类型的错误的应用程序的标识中是否包含被测应用程序的标识。

第二确定单元620h，用于当发生目标类型的错误的应用程序的标识包含被测应用程序的标识时，确定被测应用程序在检测时间窗口内发生目标类型的错误。

可选地，该装置还包括：网络判断模块640、场景信息发送模块650和场景信息保存模块660。

网络判断模块640，用于判断当前网络状况是否满足数据上报条件。

场景信息发送模块650，用于当当前网络状况满足数据上报条件时，向数据分析设备自动发送场景信息。

场景信息保存模块660，用于当当前网络状况不满足数据上报条件时，将场景信息保存至本地。

综上所述，本实施例提供的应用程序测试装置，通过独立的测试应用程序对被测应用程序进行错误检测；解决了相关技术采用在被测应用程序中集成SDK的方式进行错误检测，所导致的被测应用程序的文件过大以及影响被测应用程序的安全性的问题；既无需在被测应用程序中集成测试应用程序，也无需修改被测应用程序的配置文件，达到了充分避免对被测应用程序产生不利影响的技术效果。

另外，本实施例提供的应用程序测试装置，还通过判断当前网络状况是否满足数据上报条件，并在当前网络状况不满足数据上报条件的情况下将场景信息保存至本地，对于一些无网络或弱网络的特殊测试场景，可以避免测试结果的丢失。

另外，在灵活性方面，由于测试应用程序独立于被测应用程序，因此测试应用程序可以支持对设备中安装的任意应用程序进行错误检测，更为灵活方便地切换被测目标。

另外，本实施例提供的应用程序测试装置，不仅实现了Crash类型的错误检测，还实现了ANR类型的错误检测，扩展了错误检测范围，提高了测试效果。

另外，本实施例提供的应用程序测试装置，还通过采用n轮检测流程对被测应用程序进行错误检测，提高了错误检测和测试结果采集的实时性和效率。

需要说明的是：上述实施例提供的应用程序测试装置在对被测应用程序进行测试时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的应用程序测试装置与应用程序测试方法的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

请参考图8，其示出了本发明一个实施例提供的终端的结构示意图。该终端用于实施上述实施例中提供的应用程序测试方法。具体来讲：

终端800可以包括RF(Radio Frequency，射频)电路810、包括有一个或一个以上计算机可读存储介质的存储器820、输入单元830、显示单元840、传感器850、音频电路860、WiFi(wireless fidelity，无线保真)模块870、包括有一个或者一个以上处理核心的处理器880、以及电源890等部件。本领域技术人员可以理解，图8中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

RF电路810可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器880处理；另外，将涉及上行的数据发送给基站。通常，RF电路810包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、LNA(Low Noise Amplifier，低噪声放大器)、双工器等。此外，RF电路810还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于GSM(Global System of Mobile communication，全球移动通讯系统)、GPRS(General Packet Radio Service，通用分组无线服务)、CDMA(Code Division Multiple Access，码分多址)、WCDMA(Wideband CodeDivision Multiple Access,宽带码分多址)、LTE(Long Term Evolution,长期演进)、电子邮件、SMS(Short Messaging Service，短消息服务)等。

存储器820可用于存储软件程序以及模块，处理器880通过运行存储在存储器820的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器820可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端800的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器820可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器820还可以包括存储器控制器，以提供处理器880和输入单元830对存储器820的访问。

输入单元830可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元830可包括图像输入设备831以及其他输入设备832。图像输入设备831可以是摄像头，也可以是光电扫描设备。除了图像输入设备831，输入单元830还可以包括其他输入设备832。具体地，其他输入设备832可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元840可用于显示由用户输入的信息或提供给用户的信息以及终端800的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元840可包括显示面板841，可选的，可以采用LCD(Liquid Crystal Display，液晶显示器)、OLED(Organic Light-Emitting Diode，有机发光二极管)等形式来配置显示面板841。

终端800还可包括至少一种传感器850，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板841的亮度，接近传感器可在终端800移动到耳边时，关闭显示面板841和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于终端800还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路860、扬声器861，传声器862可提供用户与终端800之间的音频接口。音频电路860可将接收到的音频数据转换后的电信号，传输到扬声器861，由扬声器861转换为声音信号输出；另一方面，传声器862将收集的声音信号转换为电信号，由音频电路860接收后转换为音频数据，再将音频数据输出处理器880处理后，经RF电路810以发送给比如另一终端，或者将音频数据输出至存储器820以便进一步处理。音频电路860还可能包括耳塞插孔，以提供外设耳机与终端800的通信。

WiFi属于短距离无线传输技术，终端800通过WiFi模块870可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图8示出了WiFi模块870，但是可以理解的是，其并不属于终端800的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器880是终端800的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器820内的软件程序和/或模块，以及调用存储在存储器820内的数据，执行终端800的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器880可包括一个或多个处理核心；优选的，处理器880可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器880中。

终端800还包括给各个部件供电的电源890(比如电池)，优选的，电源可以通过电源管理系统与处理器880逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源890还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管未示出，终端800还可以包括蓝牙模块等，在此不再赘述。

具体在本实施例中，终端800还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行。上述一个或者一个以上程序包含用于进行上述实施例提供的应用程序测试方法的指令。

应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”(“a”、“an”、“the”)旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种应用程序测试方法，其特征在于，应用于运行有测试应用程序和被测应用程序的设备中，所述测试应用程序和所述被测应用程序之间互相独立，所述方法包括：

通过所述测试应用程序获取由所述设备的操作系统记录的错误记录信息；

根据所述错误记录信息检测所述被测应用程序是否发生目标类型的错误；

若所述被测应用程序发生所述目标类型的错误，则通过所述测试应用程序获取与所述目标类型的错误对应的场景信息，所述场景信息用于指示发生所述目标类型的错误时的设备状况和错误情况。

2.根据权利要求1所述的方法，其特征在于，

当所述错误记录信息包括系统服务的状态信息时，所述目标类型的错误包括崩溃Crash类型的错误；

和/或，

当所述错误记录信息包括系统日志信息时，所述目标类型的错误包括应用程序无响应ANR类型的错误。

3.根据权利要求1或2所述的方法，其特征在于，对所述被测应用程序进行检测的过程包括依次进行的n轮检测流程，每一轮检测流程包括：睡眠时段以及位于所述睡眠时段之后的检测时段，n为正整数；

所述根据所述错误记录信息检测所述被测应用程序是否发生目标类型的错误，包括：

在当前一轮的检测流程的检测时段内，根据所述错误记录信息检测所述被测应用程序在检测时间窗口内是否发生所述目标类型的错误；

其中，在所述当前一轮检测流程为第1轮检测流程时，所述检测时间窗口包括所述第1轮检测流程的睡眠时段；在所述当前一轮检测流程为第i轮检测流程时，所述检测时间窗口包括第i-1轮检测流程的检测时段和所述第i轮检测流程的睡眠时段，i≥2。

4.根据权利要求3所述的方法，其特征在于，所述错误记录信息包括所述系统服务的状态信息；

所述在当前一轮的检测流程的检测时段内，根据所述错误记录信息检测所述被测应用程序在检测时间窗口内是否发生所述目标类型的错误，包括：

在所述当前一轮检测流程的检测时段内，从所述系统服务的状态信息中解析获取发生所述目标类型的错误的应用程序的标识以及错误发生时间；

检测所述被测应用程序是否符合预定条件；其中，所述预定条件是指所述发生所述目标类型的错误的应用程序的标识中包含所述被测应用程序的标识，且所述错误发生时间在所述检测时间窗口内；

若所述被测应用程序符合所述预定条件，则确定所述被测应用程序在所述检测时间窗口内发生所述目标类型的错误。

5.根据权利要求3所述的方法，其特征在于，所述错误记录信息包括所述系统日志信息；

所述在当前一轮的检测流程的检测时段内，根据所述错误记录信息检测所述被测应用程序在检测时间窗口内是否发生所述目标类型的错误，包括：

在所述当前一轮检测流程的检测时段内，获取所述系统日志信息对应的创建时间；

检测所述创建时间是否在所述检测时间窗口内；

若所述创建时间在所述检测时间窗口内，则从所述系统日志信息中解析获取发生所述目标类型的错误的应用程序的标识；

检测所述发生所述目标类型的错误的应用程序的标识中是否包含所述被测应用程序的标识；

若所述发生所述目标类型的错误的应用程序的标识中包含所述被测应用程序的标识，则确定所述被测应用程序在所述检测时间窗口内发生所述目标类型的错误。

6.根据权利要求1或2所述的方法，其特征在于，所述通过所述测试应用程序获取与所述目标类型的错误对应的场景信息之后，还包括：

判断当前网络状况是否满足数据上报条件；

若所述当前网络状况满足所述数据上报条件，则向数据分析设备自动发送所述场景信息；

若所述当前网络状况不满足所述数据上报条件，则将所述场景信息保存至本地。

7.一种应用程序测试装置，其特征在于，应用于运行有测试应用程序和被测应用程序的设备中，所述测试应用程序和所述被测应用程序之间互相独立，所述装置包括：

信息获取模块，用于通过所述测试应用程序获取由所述设备的操作系统记录的错误记录信息；

错误检测模块，用于根据所述错误记录信息检测所述被测应用程序是否发生目标类型的错误；

场景信息获取模块，用于当所述被测应用程序发生所述目标类型的错误时，通过所述测试应用程序获取与所述目标类型的错误对应的场景信息，所述场景信息用于指示发生所述目标类型的错误时的设备状况和错误情况。

8.根据权利要求7所述的装置，其特征在于，

当所述错误记录信息包括系统服务的状态信息时，所述目标类型的错误包括崩溃Crash类型的错误；

和/或，

当所述错误记录信息包括系统日志信息时，所述目标类型的错误包括应用程序无响应ANR类型的错误。

9.根据权利要求7或8所述的装置，其特征在于，对所述被测应用程序进行检测的过程包括依次进行的n轮检测流程，每一轮检测流程包括：睡眠时段以及位于所述睡眠时段之后的检测时段，n为正整数；

所述错误检测模块，具体用于在当前一轮的检测流程的检测时段内，根据所述错误记录信息检测所述被测应用程序在检测时间窗口内是否发生所述目标类型的错误；

其中，在所述当前一轮检测流程为第1轮检测流程时，所述检测时间窗口包括所述第1轮检测流程的睡眠时段；在所述当前一轮检测流程为第i轮检测流程时，所述检测时间窗口包括第i-1轮检测流程的检测时段和所述第i轮检测流程的睡眠时段，i≥2。

10.根据权利要求9所述的装置，其特征在于，所述错误记录信息包括所述系统服务的状态信息；

所述错误检测模块，包括：信息解析单元、条件检测单元和第一确定单元；

所述信息解析单元，用于在所述当前一轮检测流程的检测时段内，从所述系统服务的状态信息中解析获取发生所述目标类型的错误的应用程序的标识以及错误发生时间；

所述条件检测单元，用于检测所述被测应用程序是否符合预定条件；其中，所述预定条件是指所述发生所述目标类型的错误的应用程序的标识中包含所述被测应用程序的标识，且所述错误发生时间在所述检测时间窗口内；

所述第一确定单元，用于当所述被测应用程序符合所述预定条件时，确定所述被测应用程序在所述检测时间窗口内发生所述目标类型的错误。

11.根据权利要求9所述的装置，其特征在于，所述错误记录信息包括所述系统日志信息；

所述错误检测模块，包括：时间获取单元、时间检测单元、标识获取单元、标识检测单元和第二确定单元；

所述时间获取单元，用于在所述当前一轮检测流程的检测时段内，获取所述系统日志信息对应的创建时间；

所述时间检测单元，用于检测所述创建时间是否在所述检测时间窗口内；

所述标识获取单元，用于当所述创建时间在所述检测时间窗口内时，从所述系统日志信息中解析获取发生所述目标类型的错误的应用程序的标识；

所述标识检测单元，用于检测所述发生所述目标类型的错误的应用程序的标识中是否包含所述被测应用程序的标识；

所述第二确定单元，用于当所述发生所述目标类型的错误的应用程序的标识中包含所述被测应用程序的标识时，确定所述被测应用程序在所述检测时间窗口内发生所述目标类型的错误。

12.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：

网络判断模块，用于判断当前网络状况是否满足数据上报条件；

场景信息发送模块，用于当所述当前网络状况满足所述数据上报条件时，向数据分析设备自动发送所述场景信息；

场景信息保存模块，用于当所述当前网络状况不满足所述数据上报条件时，将所述场景信息保存至本地。