CN104317699A - 应用程序审核方法及装置 - Google Patents

Abstract

本公开是关于一种应用程序审核方法及装置，属于移动终端测试领域。所述方法包括：将待审核的应用程序安装到移动终端中；向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序；向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作；根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。本公开通过自动安装和启动待审核的应用程序，并通过稳定性检测指令对启动后的应用程序进行稳定性检测，整个应用程序的稳定性检测过程自动执行，节省了人力资源，并且，保障了审核通过后的APP质量不会出现参差不齐的现象。

Description

应用程序审核方法及装置

技术领域

本公开涉及智能移动终端领域，尤其涉及一种应用程序审核方法及装置。 

背景技术

随着智能手机的广泛使用，手机上的应用程序(Application，简称，“APP”)也随之得到广泛应用。 

现在APP应用市场上，每次上架一个APP之前，都需要对APP进行审核，只有通过审核的APP才能上架到应用市场中，提供给用户下载。相关技术中对APP进行审核是采用人工审核的方式，人工审核主要是采用人工点击的方式来模拟使用APP，从而对APP进行稳定性检测，只有当稳定性检测过程中没有出现程序异常退出(Force Clash，简称“FC”)或者应用程序无响应(Application Not Responding，简称“ANR”)等现象的情况下，APP才算通过审核。 

人工审核APP的方法既耗时长，又需要较多的审核人员，另外，由于人工点击过程中操作的标准不统一，造成了APP稳定性检测的标准不统一，使得上架的APP质量参差不齐。 

发明内容

为了解决人工审核耗时长、需要审核人员多且上架的APP质量参差不齐的问题，本公开提供了一种应用程序审核方法及装置。 

根据本公开实施例的第一方面，提供一种应用程序审核方法，包括： 

将待审核的应用程序安装到移动终端中； 

向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序； 

向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作； 

根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。 

根据本公开实施例的第一方面的一种实现方式，所述第一脚本包括信息获 取指令，所述移动终端用于执行所述信息获取指令，以获取所述应用程序的信息。 

根据本公开实施例的第一方面的另一种实现方式，所述第一脚本还包括可滑动控件检测指令和跳过欢迎页面指令，所述移动终端用于执行所述可滑动控件检测指令，以判断所述应用程序是否存在欢迎页面，当所述应用程序存在所述欢迎页面时，执行所述跳过欢迎页面指令。 

根据本公开实施例的第一方面的另一种实现方式，所述第一脚本还包括登录页面检测指令和登录操作模拟指令，所述移动终端用于执行所述登录页面检测指令，以判断所述应用程序是否存在登录页面，当所述应用程序存在所述登录页面时，执行登录操作模拟指令。 

根据本公开实施例的第一方面的另一种实现方式，所述方法还包括： 

向所述移动终端发送第二脚本和第二脚本执行指令，所述第二脚本执行指令用于指示所述移动终端执行所述第二脚本，以对所述应用程序进行遍历性测试。 

根据本公开实施例的第一方面的另一种实现方式，所述方法还包括： 

向所述移动终端发送截图指令和处理器占有率获取指令中的至少一种，所述截图指令用于指示所述移动终端定时保存屏幕图像，所述处理器占有率获取指令用于指示所述移动终端定时获取所述移动终端的处理器占有率。 

根据本公开实施例的第一方面的另一种实现方式，所述方法还包括： 

从所述移动终端中卸载所述应用程序。 

根据本公开实施例的第一方面的另一种实现方式，所述根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核，采用如下方式： 

生成执行日志文件； 

根据所述执行日志文件，判断稳定性检测指令执行过程中是否出现应用程序异常现象； 

若稳定性检测指令执行过程中，未出现应用程序异常现象，则所述应用程序通过审核。 

根据本公开实施例的第一方面的另一种实现方式，所述方法还包括： 

定时下载待测的应用程序。 

根据本公开实施例的第二方面，提供一种应用程序审核装置，包括： 

安装模块，用于将待审核的应用程序安装到移动终端中； 

第一发送模块，用于向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序； 

第二发送模块，用于向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作； 

判断模块，用于根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。 

根据本公开实施例的第二方面的一种实现方式，所述装置还包括： 

第三发送模块，用于向所述移动终端发送第一脚本和第一脚本执行指令，所述第一脚本包括信息获取指令，所述移动终端用于执行所述信息获取指令，以获取所述应用程序的信息。 

根据本公开实施例的第二方面的另一种实现方式，所述第一脚本还包括可滑动控件检测指令和跳过欢迎页面指令，所述移动终端用于执行所述可滑动控件检测指令，以判断所述应用程序是否存在欢迎页面，当所述应用程序存在所述欢迎页面时，执行所述跳过欢迎页面指令。 

根据本公开实施例的第二方面的另一种实现方式，所述第一脚本还包括登录页面检测指令和登录操作模拟指令，所述移动终端用于执行所述登录页面检测指令，以判断所述应用程序是否存在登录页面，当所述应用程序存在所述登录页面时，执行登录操作模拟指令。 

根据本公开实施例的第二方面的另一种实现方式，所述装置还包括： 

第四发送模块，用于向所述移动终端发送第二脚本和第二脚本执行指令，所述第二脚本执行指令用于指示所述移动终端执行所述第二脚本，以对所述应用程序进行遍历性测试。 

根据本公开实施例的第二方面的另一种实现方式，所述装置还包括： 

第五发送模块，用于向所述移动终端发送截图指令和处理器占有率获取指令中的至少一种，所述截图指令用于指示所述移动终端定时保存屏幕图像，所述处理器占有率获取指令用于指示所述移动终端定时获取所述移动终端的处理器占有率。 

根据本公开实施例的第二方面的另一种实现方式，所述装置还包括： 

卸载模块，用于从所述移动终端中卸载所述应用程序。 

根据本公开实施例的第二方面的另一种实现方式，所述判断模块包括: 

生成单元，用于生成执行日志文件； 

判断单元，用于根据所述执行日志文件，判断稳定性检测指令执行过程中是否出现应用程序异常现象； 

确定单元，用于当所述判断单元判断稳定性检测指令执行过程中，未出现应用程序异常现象时，确定所述应用程序通过审核。 

根据本公开实施例的第二方面的另一种实现方式，所述装置还包括： 

下载模块，用于定时下载待测的应用程序。 

根据本公开实施例的第三方面，提供一种应用程序审核装置，包括： 

处理器； 

用于存储处理器可执行指令的存储器； 

其中，所述处理器被配置为： 

将待审核的应用程序安装到移动终端中； 

向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序； 

向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作； 

根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。 

本公开的实施例提供的技术方案可以包括以下有益效果： 

通过自动安装和启动待审核的应用程序，并通过稳定性检测指令对启动后的应用程序进行稳定性检测，整个应用程序的稳定性检测过程自动执行，节省了人力资源，并且，稳定性检测指令对所有待审核的APP通用，使得APP稳定性检测的标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。 

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。 

附图说明

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

图1是根据一示例性实施例示出的应用场景图。 

图2是根据一示例性实施例示出的一种应用程序审核方法的流程图。 

图3是根据一示例性实施例示出的一种应用程序审核方法的流程图。 

图4是根据一示例性实施例示出的一种应用程序审核装置的框图。 

图5是根据一示例性实施例示出的一种应用程序审核装置的框图。 

图6是根据一示例性实施例示出的一种应用程序审核装置的框图。 

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。 

为了便于实施例的描述，下面先简单介绍一下本公开中实施例的应用场景。参见图1，该场景中包括移动终端1和测试装置(例如计算机)2，移动终端1是运行APP的设备，测试装置2用于测试移动终端1中安装的APP。移动终端1与测试装置2之间可以采用有线或无线连接。 

需要说明的是，以上所述的设备种类、连接关系以及连接方式仅为举例，本公开对此不作限制。 

图2是根据一示例性实施例示出的一种应用程序审核方法的流程图，如图2所示，包括以下步骤。该方法可以在测试装置中执行。 

在步骤S11中，将待审核的APP安装到移动终端中。 

在本公开的一种实现方式中，该步骤S11可以采用如下方式实现： 

调用安卓调试桥(Android Debug Bridge，简称“ADB”)工具执行安装指令(adb install-r-packagename指令)，从而将APP安装到移动终端中。 

在步骤S12中，向移动终端发送应用程序启动指令，该应用程序启动指令用于指示移动终端启动APP。 

在实际应用中，该应用程序启动指令可以是start activity指令。 

移动终端收到该应用程序启动指令后，即启动该APP。 

在步骤S13中，向移动终端发送稳定性检测指令，该稳定性检测指令用于指示移动终端执行设定个数的用户操作。 

实现时，稳定性检测指令可以为adb shell monkey指令，例如：adb shell monkey-v-throttle(操作间隔)300--pct-touch(点击)30--pct-motion(滑动)20--pct-nav(“基本”导航事件)20--pct-majornav(“主要”导航事件)15--pct-appswitch(APP切换)5--pct-anyevent(其它类型事件)5--pct-trackball(调整轨迹事件)0-v--pct-syskeys(调整“系统”按键事件)0-p'％s'1000等。执行adb shell monkey指令默认模拟人工执行设定个数(例如1000个)的用户操作，包括点击、滑动、导航、APP切换、滚动等，完全随机操作，以检测APP是否发生FC现象。该检测操作的检测操作次数多且完全随机，能充分检测APP，保障检测后APP的质量，且该稳定性检测指令为通用指令，检测操作标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。 

在步骤S14中，根据稳定性检测指令的执行结果，判断APP是否通过审核。 

其中，稳定性检测指令的执行结果包括APP是否出现应用程序异常现象，例如，FC现象或者ANR现象。 

该步骤S14可以包括：如果稳定性检测指令的执行结果为应用程序出现异常现象，则APP审核不通过；如果稳定性检测指令的执行结果为应用程序未出现异常现象，则APP审核通过。 

进一步地，在实现时，该步骤S14可以采用如下方式： 

生成执行日志文件； 

根据执行日志文件判断稳定性检测指令执行过程中，是否出现应用程序异常现象； 

若稳定性检测指令执行过程中，未出现应用程序异常现象，则应用程序通过审核。 

其中，执行日志文件可以采用adb bugreport命令生成，在执行日志文件生成后，在执行日志文件中查找“Force stopping”和“Stop Responsing”的关键字，若查找到“Force stopping”或“Stop Responsing”的关键字，则表示出现应用程序异常现象，反之，则表示未出现应用程序异常现象。 

在实际应用中，安装应用程序指令、启动应用程序指令以及稳定性检测指 令都可以保存在预先设置的python脚本中，通过bash代码将这些python脚本串起来，从而使其自动依次执行，使得整个审核过程实现全自动化，节省人力资源。 

本公开实施例通过自动安装和启动待审核的应用程序，并通过稳定性检测指令对启动后的应用程序进行稳定性检测，整个应用程序的稳定性检测过程自动执行，节省了人力资源，并且，稳定性检测指令对所有待审核的APP通用，使得APP稳定性检测的标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。 

图3是根据一示例性实施例示出的一种应用程序审核方法的流程图，如图3所示，该包括以下步骤。该方法可以由测试装置执行。 

在步骤S21中，定时下载待审核的APP。 

通常，待审核的APP储存在APP市场服务器的后台中，测试装置可以定时从APP市场服务器下载待审核的APP，定时时间可以为15分钟、20分钟等，时间的间隔视实际审核APP需求而定，这里不做限制。 

实现时，可以采用crontab指令实现定时下载的功能，crontab指令存储在crontab文件中，由计算机后台运行。通过crontab指令实现定时下载的功能，可以进一步实现审核过程的自动化。 

可以理解地，一次可以下载多个APP，例如50个。下载后，可以按顺序依次执行下述步骤S22～S29。 

在步骤S22中，将下载的APP安装到移动终端中。 

在本公开的一种实现方式中，该步骤S22可以采用如下方式实现： 

调用ADB工具执行安装指令(adb install-r-packagename指令)，从而将APP安装到移动终端中。 

在步骤S23中，向移动终端发送第一脚本和第一脚本执行指令。 

该第一脚本包括信息获取指令，第一脚本执行指令用于指示移动终端执行第一脚本。移动终端用于根据第一脚本执行指令，执行信息获取指令，以获取APP的信息。 

该第一脚本可以为使用Google自带的Uiautomator自动化测试框架编写的通用脚本。其中的信息获取指令可以是aapt dump badging package name指令。 该第一脚本可以通过adb push命令发送给移动终端。 

APP的信息包括但不限于APP的包名、APP的名称、(Software Development Kit，简称“SDK”)的版本、启动的Activity、应用的权限。 

在本实施例中，该第一脚本中还可以包括可滑动控件检测指令和跳过欢迎页面指令，移动终端用于执行可滑动控件检测指令，以判断APP是否存在欢迎页面，当APP存在欢迎页面时，执行跳过欢迎页面指令。 

在本实施例中，该第一脚本还可以包括登录页面检测指令和登录操作模拟指令，移动终端用于执行登录页面检测指令，以判断APP是否存在登录页面，当APP存在登录页面时，执行登录操作模拟指令。 

在步骤S24中，向移动终端发送应用程序启动指令。 

在实际应用中，该应用程序启动指令可以是start activity指令。移动终端收到该应用程序启动指令后，即启动该APP。 

可以理解地，该步骤在移动终端执行完信息获取指令后执行。移动终端收到该应用程序启动指令后，启动应用程序。 

在启动应用程序的同时，继续执行第一脚本中的其他指令。 

例如，在启动应用程序的同时，执行可滑动控件检测指令，以判断APP是否存在欢迎页面。实现时，可滑动控件检测指令用于调用UI Automator工具来判断APP是否具有可滑动(scrollable)属性，如果APP具有scrollable属性，则可以判断APP中存在欢迎页面，反之，如果APP没有scrollable属性，则表示APP中不存在欢迎页面。 

如果APP存在欢迎页面，则执行跳过欢迎页面指令，相应地，该跳过欢迎页面指令用于调用swipe函数，通过swipe函数，将欢迎页面往一边拖拽，从而模拟滑动操作(例如：屏幕分辨率从左侧到右侧的分布为0至256，使用swipe函数，将当前屏幕所处的左侧的分辨率0变换为分辨率256，实现模拟滑动操作)，跳过欢迎页面。通过自动跳过有欢迎页面的APP，可以免除审核人员观看欢迎页面的时间，节约了审核时间，更重要的是跳过欢迎页使得后面的monkey随机事件能在一个APP内部执行，而不是一直停留在欢迎页，进而能够更好地测试一个APP的健壮性。 

又例如，在跳过欢迎页面后，可以执行登录页面检测指令。 

在实际应用中，可以通过判断APP中是否有“登录”或“Login”字样或者 是否有可以输入文字的文本框来判断APP中是否存在登录页面。具体地，可以通过UI Automator工具中提供的识字的接口来判断是否有“登录”或“Login”字样或者是否有可以输入文字的文本框，如果有“登录”或“Login”字样且有可以输入文字的文本框，则表示检测到登录页面。 

如果检测到登录页面，则移动终端执行登录操作模拟指令。实现时，移动终端可以根据该APP的信息查询预先保存在数据库中的账户信息(例如用户名和密码)，然后将查询到的账户信息输入文本框中，自动完成模拟登录操作。通过自动完成需要登录的APP的登录操作，免除了审核人的登录操作时间，进一步节约了审核时间，同样跳过登录页，也是为了更好的测试一个APP的健壮性。 

在步骤S25中，向移动终端发送稳定性检测指令，该稳定性检测指令用于指示移动终端执行设定个数的用户操作。 

实现时，稳定性检测指令可以为adb shell monkey指令，例如：adb shell monkey-v-throttle(操作间隔)300--pct-touch(点击)30--pct-motion(滑动)20--pct-nav(“基本”导航事件)20--pct-majornav(“主要”导航事件)15--pct-appswitch(APP切换)5--pct-anyevent(其它类型事件)5--pct-trackball(调整轨迹事件)0-v--pct-syskeys(调整“系统”按键事件)0-p'％s'1000等。执行adb shell monkey指令默认模拟人工执行设定个数(例如1000个)的用户操作，包括点击、滑动、导航、APP切换、滚动等，完全随机操作，以检测APP是否发生FC现象。该检测操作的检测操作次数多且完全随机，能充分检测APP，保障检测后APP的质量，且该稳定性检测指令为通用指令，检测操作标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。 

在步骤S26中，向移动终端发送截图指令和处理器占有率获取指令中的至少一种，该截图指令用于指示移动终端定时保存屏幕图像，该处理器占有率获取指令用于指示移动终端定时获取移动终端的处理器占有率。 

该步骤S26可以与步骤S25同步执行。 

其中，截图指令可以为adb shell screencap指令，adb shell screencap指令用于指示移动终端每5秒进行一次屏幕截图，以保存稳定性检测指令执行过程中的屏幕图像，所得截图可用作对APP稳定性检测过程的参考。处理器占有率获取指令可以为adb shell dumpsys cpuinfo指令，用于获取APP稳定性检测过程中设备的CPU占有率，所得CPU占有率数据可用作对APP的耗能情况的参考分 析。 

需要说明的是，在本实施例中，该步骤S26中向移动终端发送截图指令和处理器占有率获取指令，在其他实施例中，也可以只向移动终端发送截图指令和处理器占有率获取指令中的一个，或者，可以直接省略该步骤S26。 

在步骤S27中，向移动终端发送第二脚本和第二脚本执行指令，第二脚本执行指令用于指示移动终端执行第二脚本，以对应用程序进行遍历性测试。 

该第二脚本可以为使用Google自带的Uiautomator自动化测试框架编写的通用脚本。与第一脚本一样，该第二脚本也可以通过adb push命令发送给移动终端。 

在实际应用中，可以根据设定的规则来判断该应用程序是否需要进行遍历性检测，例如，应用程序市场的下载排名中前100的APP需要进行遍历性检测，或者审核人员认定的需要进行遍历性检测的应用程序。 

具体地，该第二脚本可以采用深度优先算法进行遍历性测试，该第二脚本中还可以包括测试时间、循环次数等参数，移动终端在执行第二脚本时，开始计时，若遍历性测试的执行时间达到测试时间，则结束遍历性测试，同时，在执行遍历性测试的过程中，若重复检测同一Activity的次数超过循环次数，则跳出检测的Activity。测试时间、可以根据实际需要设定，例如3分钟、5分钟，循环次数也可以根据实际需要设定，例如3次、5次等。通过采用深度优先算法和合理设置测试时间、循环次数等参数，可以保障整个遍历性检测的平均遍历的分支超过70％，以尽可能的遍历APP中所有Activity。 

另外，为了使遍历性检测操作更接近人为操作，可以在遍历性测试的过程中，进行智能界面元素分析，得到当前界面元素类型，该界面元素类型包括长按、文字输入、滑动、hardkey等，遍历性检测操作依据不同比例的元素类型进行组合来达到模拟人为操作的效果。上述遍历性检测能更加全面的对APP进行检测，可以进一步确保优秀APP的质量。 

可以理解地，在其他实现方式中，该第二脚本可以采用广度优先算法进行遍历性测试。广度优先算法是指进入一个界面后，先遍历该页面所有的元素，但不进入下一层，待该页面所有元素处理完后，再从第一个元素开始进入下一层级，依次类推。 

此外，在执行步骤S27时也可以同时执行步骤S26，对遍历性测试过程进行 截图和获取CPU占有率数据。 

在步骤S28中，从移动终端中卸载该APP。 

在实际应用中，可以向移动终端发送卸载应用程序指令，从而从移动终端中卸载该APP，卸载应用程序指令可以为adb uninstall-r-packagename指令。这样，移动终端可以自动卸载已检测过的APP，这样设置免除了审核人员手动卸载APP的操作，进而节省了审核人员的审核时间，同时也避免了一台移动终端因为装了太多APP导致出现性能瓶颈。 

在步骤S29中，根据稳定性检测指令的执行结果，判断APP是否通过审核。 

具体地，稳定性检测指令的执行结果包括APP是否出现应用程序异常现象，例如，FC现象或者ANR现象。 

该步骤S29可以包括：如果稳定性检测指令的执行结果为应用程序出现异常现象，则APP审核不通过；如果稳定性检测指令的执行结果为应用程序未出现异常现象，则APP审核通过。 

进一步地，在实现时，该步骤S29可以采用如下方式： 

生成执行日志文件； 

根据执行日志文件判断稳定性检测指令执行过程中，是否出现应用程序异常现象； 

若稳定性检测指令执行过程中，未出现应用程序异常现象，则应用程序通过审核。 

其中，执行日志文件可以采用adb bugreport命令生成，在执行日志文件生成后，在执行日志文件中查找“Force stopping”和“Stop Responsing”的关键字，若查找到“Force stopping”或“Stop Responsing”的关键字，则表示出现应用程序异常现象，反之，则表示未出现应用程序异常现象。 

此外，上述执行日志文件可以通过程序转换成可观看的超文本标记语言(Hyper Text Mark-up Language，简称“HTML”)格式，便于审核人员查看。 

在实际应用中，安装应用程序指令、启动应用程序指令、第一脚本执行指令、第二脚本执行指令以及稳定性检测指令都可以分别保存在预先设置的python脚本中，通过bash代码将这些python脚本串起来，从而使其自动依次执行，使得整个审核过程实现全自动化，节省人力资源。 

本公开实施例通过自动安装和启动待审核的应用程序，并通过稳定性检测 指令对启动后的应用程序进行稳定性检测，整个应用程序的稳定性检测过程自动执行，节省了人力资源，并且，稳定性检测指令对所有待审核的APP通用，使得APP稳定性检测的标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。此外，本公开实施例通过向移动终端发送第一脚本，并使移动终端执行第一脚本，从而可以自动获取APP信息、跳过欢迎页面、跳过登录页面，进一步减少了审核人员的手动操作，并且本公开实施例通过向移动终端发送第二脚本，并使移动终端执行第二脚本，从而可以对APP进行遍历性测试，使得测试过程更加完整。另外，本公开实施例通过定时下载待审核的应用程序，从而可以进一步提高审核的自动化。 

图4是根据一示例性实施例示出的一种应用程序审核装置框图。参照图4，该装置包括安装模块401、第一发送模块402、第二发送模块403和判断模块404。 

其中，该安装模块401被配置为用于将待审核的应用程序安装到移动终端中。安装模块401可以调用ADB工具执行安装指令(adb install-r-packagename指令)，从而将APP安装到移动终端中。 

该第一发送模块402被配置为用于向移动终端发送应用程序启动指令，该应用程序启动指令用于指示移动终端启动应用程序。在实际应用中，该应用程序启动指令可以是start activity指令。移动终端收到该应用程序启动指令后，即启动该APP。 

该第二发送模块403被配置为用于向移动终端发送稳定性检测指令，该稳定性检测指令用于指示移动终端执行设定个数的用户操作。 

实现时，稳定性检测指令可以为adb shell monkey指令，例如：adb shell monkey-v-throttle(操作间隔)300--pct-touch(点击)30--pct-motion(滑动)20--pct-nav(“基本”导航事件)20--pct-majornav(“主要”导航事件)15--pct-appswitch(APP切换)5--pct-anyevent(其它类型事件)5--pct-trackball(调整轨迹事件)0-v--pct-syskeys(调整“系统”按键事件)0-p'％s'1000等。执行adb shell monkey指令默认模拟人工执行设定个数(例如1000个)的用户操作，包括点击、滑动、导航、APP切换、滚动等，完全随机操作，以检测APP是否发生FC现象。该检测操作的检测操作次数多且完全随机，能充分检测APP，保障检测后APP的质量，且该稳定性检测指令为通用指令，检测操作标准统一，保 障了审核通过后的APP质量不会出现参差不齐的现象。 

该判断模块404被配置为用于根据稳定性检测指令的执行结果，判断APP是否通过审核。 

其中，稳定性检测指令的执行结果包括APP是否出现应用程序异常现象，例如，FC现象或者ANR现象。如果稳定性检测指令的执行结果为应用程序出现异常现象，则APP审核不通过；如果稳定性检测指令的执行结果为应用程序未出现异常现象，则APP审核通过。 

在实际应用中，安装应用程序指令、启动应用程序指令以及稳定性检测指令都可以保存在预先设置的python脚本中，通过bash代码将这些python脚本串起来，从而使其自动依次执行，使得整个审核过程实现全自动化，节省人力资源。 

本公开实施例通过自动安装和启动待审核的应用程序，并通过稳定性检测指令对启动后的应用程序进行稳定性检测，整个应用程序的稳定性检测过程自动执行，节省了人力资源，并且，稳定性检测指令对所有待审核的APP通用，使得APP稳定性检测的标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。 

图5是根据一示例性实施例示出的一种应用程序审核装置框图。参照图5，该装置包括安装模块501、第一发送模块502、第二发送模块503和判断模块504。 

其中，该安装模块501被配置为用于将待审核的应用程序安装到移动终端中。安装模块501可以调用ADB工具执行安装指令(adb install-r-packagename指令)，从而将APP安装到移动终端中。 

该第一发送模块502被配置为用于向移动终端发送应用程序启动指令，该应用程序启动指令用于指示移动终端启动应用程序。在实际应用中，该应用程序启动指令可以是start activity指令。移动终端收到该应用程序启动指令后，即启动该APP。 

该第二发送模块503被配置为用于向移动终端发送稳定性检测指令，该稳定性检测指令用于指示移动终端执行设定个数的用户操作。 

实现时，稳定性检测指令可以为adb shell monkey指令，例如：adb shell monkey-v-throttle(操作间隔)300--pct-touch(点击)30--pct-motion(滑动) 20--pct-nav(“基本”导航事件)20--pct-majornav(“主要”导航事件)15--pct-appswitch(APP切换)5--pct-anyevent(其它类型事件)5--pct-trackball(调整轨迹事件)0-v--pct-syskeys(调整“系统”按键事件)0-p'％s'1000等。执行adb shell monkey指令默认模拟人工执行设定个数(例如1000个)的用户操作，包括点击、滑动、导航、APP切换、滚动等，完全随机操作，以检测APP是否发生FC现象。该检测操作的检测操作次数多且完全随机，能充分检测APP，保障检测后APP的质量，且该稳定性检测指令为通用指令，检测操作标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。 

该判断模块504被配置为用于根据稳定性检测指令的执行结果，判断APP是否通过审核。 

其中，稳定性检测指令的执行结果包括APP是否出现应用程序异常现象，例如，FC现象或者ANR现象。如果稳定性检测指令的执行结果为应用程序出现异常现象，则APP审核不通过；如果稳定性检测指令的执行结果为应用程序未出现异常现象，则APP审核通过。 

该判断模块504可以包括： 

生成单元，用于生成执行日志文件； 

判断单元，用于根据执行日志文件，判断稳定性检测指令执行过程中是否出现应用程序异常现象； 

确定单元，用于当判断单元判断稳定性检测指令执行过程中，未出现应用程序异常现象时，确定应用程序通过审核。 

其中，执行日志文件可以采用adb bugreport命令生成，在执行日志文件生成后，在执行日志文件中查找“Force stopping”和“Stop Responsing”的关键字，若查找到“Force stopping”或“Stop Responsing”的关键字，则表示出现应用程序异常现象，反之，则表示未出现应用程序异常现象。 

可选地，该装置还可以包括下载模块505，该下载模块505被配置为用于定时下载待审核的APP。通常，待审核的APP储存在APP市场服务器的后台中，测试装置可以定时从APP市场服务器下载待审核的APP，定时时间可以为15分钟、20分钟等，时间的间隔视实际审核APP需求而定，这里不做限制。 

实现时，可以采用crontab指令实现定时下载的功能，crontab指令存储在crontab文件中，由计算机后台运行。通过crontab指令实现定时下载的功能，可 以进一步实现审核过程的自动化。 

可选地，该装置还可以包括第三发送模块506，该第三发送模块被配置为用于向移动终端发送第一脚本和第一脚本执行指令。 

该第一脚本包括信息获取指令，第一脚本执行指令用于指示移动终端执行第一脚本。移动终端用于根据第一脚本执行指令，执行信息获取指令，以获取APP的信息。该第一脚本可以为使用Google自带的Uiautomator自动化测试框架编写的通用脚本。其中的信息获取指令可以是aapt dump badging package name指令。该第一脚本可以通过adb push命令发送给移动终端。 

APP的信息包括但不限于APP的包名、APP的名称、SDK的版本、启动的Activity、应用的权限。 

在本实施例中，该第一脚本中还可以包括可滑动控件检测指令和跳过欢迎页面指令，移动终端用于执行可滑动控件检测指令，以判断APP是否存在欢迎页面，当APP存在欢迎页面时，执行跳过欢迎页面指令。 

在本实施例中，该第一脚本还可以包括登录页面检测指令和登录操作模拟指令，移动终端用于执行登录页面检测指令，以判断APP是否存在登录页面，当APP存在登录页面时，执行登录操作模拟指令。 

移动终端可以在启动应用程序之前，执行第一脚本中的信息获取指令，在启动应用程序的同时，继续执行第一脚本中的其他指令。 

例如，在启动应用程序的同时，执行可滑动控件检测指令，以判断APP是否存在欢迎页面。实现时，可滑动控件检测指令用于调用UI Automator工具来判断APP是否具有可滑动(scrollable)属性，如果APP具有scrollable属性，则可以判断APP中存在欢迎页面，反之，如果APP没有scrollable属性，则表示APP中不存在欢迎页面。 

如果APP存在欢迎页面，则执行跳过欢迎页面指令，相应地，该跳过欢迎页面指令用于调用swipe函数，通过swipe函数，将欢迎页面往一边拖拽，从而模拟滑动操作(例如：屏幕分辨率从左侧到右侧的分布为0至256，使用swipe函数，将当前屏幕所处的左侧的分辨率0变换为分辨率256，实现模拟滑动操作)，跳过欢迎页面。通过自动跳过有欢迎页面的APP，可以免除审核人员观看欢迎页面的时间，节约了审核时间，更重要的是跳过欢迎页使得后面的monkey随机事件能在一个APP内部执行，而不是一直停留在欢迎页，进而能够更好地测试 一个APP的健壮性。 

又例如，在跳过欢迎页面后，可以执行登录页面检测指令。 

在实际应用中，可以通过判断APP中是否有“登录”或“Login”字样或者是否有可以输入文字的文本框来判断APP中是否存在登录页面。具体地，可以通过UI Automator工具中提供的识字的接口来判断是否有“登录”或“Login”字样或者是否有可以输入文字的文本框，如果有“登录”或“Login”字样且有可以输入文字的文本框，则表示检测到登录页面。 

如果检测到登录页面，则移动终端执行登录操作模拟指令。实现时，移动终端可以根据该APP的信息查询预先保存在数据库中的账户信息(例如用户名和密码)，然后将查询到的账户信息输入文本框中，自动完成模拟登录操作。通过自动完成需要登录的APP的登录操作，免除了审核人的登录操作时间，进一步节约了审核时间，同样跳过登录页，也是为了更好的测试一个APP的健壮性。 

可选地，该装置还包括第四发送模块507，向移动终端发送第二脚本和第二脚本执行指令，第二脚本执行指令用于指示移动终端执行第二脚本，以对应用程序进行遍历性测试。 

该第二脚本可以为使用Google自带的Uiautomator自动化测试框架编写的通用脚本。与第一脚本一样，该第二脚本也可以通过adb push命令发送给移动终端。 

在实际应用中，可以根据设定的规则来判断该应用程序是否需要进行遍历性检测，例如，应用程序市场的下载排名中前100的APP需要进行遍历性检测，或者审核人员认定的需要进行遍历性检测的应用程序。 

具体地，该第二脚本可以采用深度优先算法进行遍历性测试，该第二脚本中还可以包括测试时间、循环次数等参数，移动终端在执行第二脚本时，开始计时，若遍历性测试的执行时间达到测试时间，则结束遍历性测试，同时，在执行遍历性测试的过程中，若重复检测同一Activity的次数超过循环次数，则跳出检测的Activity。测试时间、可以根据实际需要设定，例如3分钟、5分钟，循环次数也可以根据实际需要设定，例如3次、5次等。通过采用深度优先算法和合理设置测试时间、循环次数等参数，可以保障整个遍历性检测的平均遍历的分支超过70％，以尽可能的遍历APP中所有Activity。 

另外，为了使遍历性检测操作更接近人为操作，可以在遍历性测试的过程 中，进行智能界面元素分析，得到当前界面元素类型，该界面元素类型包括长按、文字输入、滑动、hardkey等，遍历性检测操作依据不同比例的元素类型进行组合来达到模拟人为操作的效果。上述遍历性检测能更加全面的对APP进行检测，可以进一步确保优秀APP的质量。 

可选地，该装置还可以包括第五发送模块508，该第五发送模块508被配置为用于向移动终端发送截图指令和处理器占有率获取指令中的至少一种，该截图指令用于指示移动终端定时保存屏幕图像，该处理器占有率获取指令用于指示移动终端定时获取移动终端的处理器占有率。 

其中，截图指令可以为adb shell screencap指令，adb shell screencap指令用于指示移动终端每5秒进行一次屏幕截图，以保存稳定性检测指令执行过程中的屏幕图像，所得截图可用作对APP稳定性检测过程的参考。处理器占有率获取指令可以为adb shell dumpsys cpuinfo指令，用于获取APP稳定性检测过程中设备的CPU占有率，所得CPU占有率数据可用作对APP的耗能情况的参考分析。 

可选地，该装置还可以包括卸载模块509，该卸载模块509被配置为用于从移动终端中卸载应用程序。 

实现时，可以向移动终端发送卸载应用程序指令，从而从移动终端中卸载该APP，卸载应用程序指令可以为adb uninstall-r-packagename指令。这样，移动终端可以自动卸载已检测过的APP，这样设置免除了审核人员手动卸载APP的操作，进而节省了审核人员的审核时间。 

在实际应用中，安装应用程序指令、启动应用程序指令、第一脚本执行指令、第二脚本执行指令以及稳定性检测指令都可以分别保存在预先设置的python脚本中，通过bash代码将这些python脚本串起来，从而使其自动依次执行，使得整个审核过程实现全自动化，节省人力资源。 

本公开实施例通过自动安装和启动待审核的应用程序，并通过稳定性检测指令对启动后的应用程序进行稳定性检测，整个应用程序的稳定性检测过程自动执行，节省了人力资源，并且，稳定性检测指令对所有待审核的APP通用，使得APP稳定性检测的标准统一，保障了审核通过后的APP质量不会出现参差不齐的现象。此外，本公开实施例通过向移动终端发送第一脚本，并使移动终端执行第一脚本，从而可以自动获取APP信息、跳过欢迎页面、跳过登录页面， 进一步减少了审核人员的手动操作，并且本公开实施例通过向移动终端发送第二脚本，并使移动终端执行第二脚本，从而可以对APP进行遍历性测试，使得测试过程更加完整。另外，本公开实施例通过定时下载待审核的应用程序，从而可以进一步提高审核的自动化。 

图6是根据一示例性实施例示出的一种用于应用程序审核装置600的框图。例如，装置600可以是个人电脑等设备。 

参照图6，装置600可以包括以下一个或多个组件：处理组件602，存储器604，电源组件606，多媒体组件608，音频组件610，输入/输出(I/O)的接口612，传感器组件614，以及通信组件616。 

处理组件602通常控制装置600的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件602可以包括一个或多个处理器620来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件602可以包括一个或多个模块，便于处理组件602和其他组件之间的交互。例如，处理部件602可以包括多媒体模块，以方便多媒体组件608和处理组件602之间的交互。 

存储器604被配置为存储各种类型的数据以支持在装置600的操作。这些数据的示例包括用于在装置600上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。 

电源组件606为装置600的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置600生成、管理和分配电力相关联的组件。 

多媒体组件608包括在装置600和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。该 触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件608包括一个前置摄像头和/或后置摄像头。当装置600处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。 

音频组件610被配置为输出和/或输入音频信号。例如，音频组件610包括一个麦克风(MIC)，当装置600处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器604或经由通信组件616发送。在一些实施例中，音频组件610还包括一个扬声器，用于输出音频信号。 

I/O接口612为处理组件602和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。 

传感器组件614包括一个或多个传感器，用于为装置600提供各个方面的状态评估。例如，传感器组件614可以检测到装置600的打开/关闭状态，组件的相对定位，例如该组件为装置600的显示器和小键盘，传感器组件614还可以检测装置600或装置600一个组件的位置改变，用户与装置600接触的存在或不存在，装置600方位或加速/减速和装置600的温度变化。传感器组件614可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件614还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件614还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。 

通信组件616被配置为便于装置600和其他设备之间有线或无线方式的通信。装置600可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信部件616经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信部件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。 

在示例性实施例中，装置600可以被一个或多个应用专用集成电路(ASIC)、 数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。 

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器604，上述指令可由装置600的处理器620执行以完成上述方法。例如，该非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。 

一种非临时性计算机可读存储介质，当该存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行一种应用程序审核方法，该方法包括： 

将待审核的应用程序安装到移动终端中； 

向移动终端发送应用程序启动指令，该应用程序启动指令用于指示移动终端启动应用程序； 

向移动终端发送稳定性检测指令，该稳定性检测指令用于指示移动终端执行设定个数的用户操作； 

根据稳定性检测指令的执行结果，判断应用程序是否通过审核。 

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。 

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。 

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。 

Claims (19)

1.一种应用程序审核方法，其特征在于，所述方法包括：

将待审核的应用程序安装到移动终端中；

向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序；

向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作；

根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。

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

向所述移动终端发送第一脚本和第一脚本执行指令，所述第一脚本包括信息获取指令，所述移动终端用于执行所述信息获取指令，以获取所述应用程序的信息。

3.根据权利要求2所述的方法，其特征在于，所述第一脚本还包括可滑动控件检测指令和跳过欢迎页面指令，所述移动终端用于执行所述可滑动控件检测指令，以判断所述应用程序是否存在欢迎页面，当所述应用程序存在所述欢迎页面时，执行所述跳过欢迎页面指令。

4.根据权利要求2所述的方法，其特征在于，所述第一脚本还包括登录页面检测指令和登录操作模拟指令，所述移动终端用于执行所述登录页面检测指令，以判断所述应用程序是否存在登录页面，当所述应用程序存在所述登录页面时，执行登录操作模拟指令。

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

向所述移动终端发送第二脚本和第二脚本执行指令，所述第二脚本执行指令用于指示所述移动终端执行所述第二脚本，以对所述应用程序进行遍历性测试。

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

向所述移动终端发送截图指令和处理器占有率获取指令中的至少一种，所述截图指令用于指示所述移动终端定时保存屏幕图像，所述处理器占有率获取指令用于指示所述移动终端定时获取所述移动终端的处理器占有率。

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

从所述移动终端中卸载所述应用程序。

8.根据权利要求1所述的方法，其特征在于，所述根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核，采用如下方式：

生成执行日志文件；

根据所述执行日志文件，判断稳定性检测指令执行过程中是否出现应用程序异常现象；

若稳定性检测指令执行过程中，未出现应用程序异常现象，则所述应用程序通过审核。

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

定时下载待测的应用程序。

10.一种应用程序审核装置，其特征在于，所述装置包括：

安装模块，用于将待审核的应用程序安装到移动终端中；

第一发送模块，用于向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序；

第二发送模块，用于向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作；

判断模块，用于根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：

第三发送模块，用于向所述移动终端发送第一脚本和第一脚本执行指令，所述第一脚本包括信息获取指令，所述移动终端用于执行所述信息获取指令，以获取所述应用程序的信息。

12.根据权利要求11所述的装置，其特征在于，所述第一脚本还包括可滑动控件检测指令和跳过欢迎页面指令，所述移动终端用于执行所述可滑动控件检测指令，以判断所述应用程序是否存在欢迎页面，当所述应用程序存在所述欢迎页面时，执行所述跳过欢迎页面指令。

13.根据权利要求11所述的装置，其特征在于，所述第一脚本还包括登录页面检测指令和登录操作模拟指令，所述移动终端用于执行所述登录页面检测指令，以判断所述应用程序是否存在登录页面，当所述应用程序存在所述登录页面时，执行登录操作模拟指令。

14.根据权利要求10所述的装置，其特征在于，所述装置还包括：

第四发送模块，用于向所述移动终端发送第二脚本和第二脚本执行指令，所述第二脚本执行指令用于指示所述移动终端执行所述第二脚本，以对所述应用程序进行遍历性测试。

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

第五发送模块，用于向所述移动终端发送截图指令和处理器占有率获取指令中的至少一种，所述截图指令用于指示所述移动终端定时保存屏幕图像，所述处理器占有率获取指令用于指示所述移动终端定时获取所述移动终端的处理器占有率。

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

卸载模块，用于从所述移动终端中卸载所述应用程序。

17.根据权利要求10所述的装置，其特征在于，所述判断模块包括:

生成单元，用于生成执行日志文件；

判断单元，用于根据所述执行日志文件，判断稳定性检测指令执行过程中是否出现应用程序异常现象；

确定单元，用于当所述判断单元判断稳定性检测指令执行过程中，未出现应用程序异常现象时，确定所述应用程序通过审核。

18.根据权利要求10所述的装置，其特征在于，所述装置还包括：

下载模块，用于定时下载待测的应用程序。

19.一种应用程序审核装置，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

将待审核的应用程序安装到移动终端中；

向所述移动终端发送应用程序启动指令，所述应用程序启动指令用于指示所述移动终端启动所述应用程序；

向所述移动终端发送稳定性检测指令，所述稳定性检测指令用于指示所述移动终端执行设定个数的用户操作；

根据所述稳定性检测指令的执行结果，判断所述应用程序是否通过审核。