CN108733561A - 应用程序启动时长测试方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种应用程序启动时长测试方法、装置、电子设备及存储介质，其中，该方法应用于预置测试框架中，该方法包括：启动待测试应用程序，并记录该待测试应用程序的启动起始时间和启动结束时间，该启动结束时间为待测试应用程序的首页数据加载完成时的时间，根据该启动起始时间和该启动结束时间，确定待测试应用程序的启动时长。该技术方案的测试流程完整，能够自动、高效、精确、快速得到应用程序的启动时长，解决了现有手动测试方法依赖测试者、测试数据容易出现误差及无法完成大量测试的问题。

Description

应用程序启动时长测试方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用程序启动时长测试方法、装置、电子设备及存储介质。

背景技术

随着移动终端中应用程序版本功能的迭代更新，应用程序的功能复杂度和代码的量级都会增大，可能致使应用程序的启动时长增加，相应的降低了该应用程序的用户使用体验和用户转化率。因而，在应用程序的开发过程中，需要测试应用程序的启动时长来评价应用程序的性能。

目前，主要通过手动测试方法计算应用程序的启动时长，即测试者点击应用程序图标并记录起始时间，当观察到应用程序首页数据时记录结束时间，因而，应用程序的启动时长为结束时间减去起始时间。该方法贴近用户真实感受，不需要编写代码，没有维护代码的成本。但是该方法依赖于测试者操作时的点击动作和记录时间的同步性，一旦快和慢都会给测试数据带来误差，而且耗时较多。

综上所述，现有手动测试方法存在依赖测试者，测试数据容易出现误差，且无法完成大量测试的问题。

发明内容

本申请提供一种应用程序启动时长测试方法、装置、电子设备及存储介质，以解决现有手动测试方法依赖测试者、测试数据容易出现误差及无法完成大量测试的问题。

第一方面，本申请实施例提供一种应用程序启动时长测试方法，应用于预置测试框架中，所述方法包括：

启动待测试应用程序，并记录所述待测试应用程序的启动起始时间和启动结束时间，所述启动结束时间为所述待测试应用程序的首页数据加载完成时的时间；

根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长。

可选的，所述方法还包括：

获取所述待测试应用程序的多个启动时长；

根据所述多个启动时长，确定所述待测试应用程序的平均启动时长。

可选的，在所述启动待测试应用程序之前，还包括：

接收测试指令，所述测试指令用于触发测试所述待测试应用程序的启动时长；

根据所述测试指令，启动所述预置测试框架。

可选的，在所述根据所述测试指令，启动所述预置测试框架之前，还包括：

配置所述待测试应用程序的启动参数，所述启动参数包括：所述待测试应用程序所在的设备名称、所述待测试应用程序的运行平台和所述待测试应用程序的系统版本；

在所述预置测试框架中创建该启动参数；

所述启动待测试应用程序，包括：

通过所述预置测试框架，根据所述启动参数，启动所述待测试应用程序。

可选的，在所述根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长之后，还包括：

接收任务结束命令，所述任务结束命令用于停止所述预置测试框架；

运行所述任务结束命令，停止所述预置测试框架。

可选的，在所述启动待测试应用程序之后，还包括：

判断是否检测到所述待测试应用程序的首页数据；

若检测不到所述待测试应用程序的首页数据，则等待；

在累计等待时间超出预设检测时间时，退出所述应用程序启动时长测试方法。

第二方面，本申请实施例提供一种应用程序启动时长测试装置，应用于预置测试框架中，所述装置包括：

测试模块，用于启动待测试应用程序，并记录所述待测试应用程序的启动起始时间和启动结束时间，所述启动结束时间为所述待测试应用程序的首页数据加载完成时的时间；

确定模块，用于根据所述测试模块得到的所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长。

可选的，所述测试模块，还用于获取所述待测试应用程序的多个启动时长；

所述确定模块，还用于根据所述测试模块得到的所述多个启动时长，确定所述待测试应用程序的平均启动时长。

可选的，所述测试模块，还用于在启动待测试应用程序之前接收测试指令，根据所述测试指令，启动所述预置测试框架，所述测试指令用于触发测试所述待测试应用程序的启动时长。

可选的，所述测试模块，还用于在所述根据所述测试指令，启动所述预置测试框架之前，配置所述待测试应用程序的启动参数，在所述预置测试框架中创建该启动参数，所述启动参数包括：所述待测试应用程序所在的设备名称、所述待测试应用程序的运行平台和所述待测试应用程序的系统版本；

相应的，所述测试模块，用于启动待测试应用程序，具体为：

所述测试模块，用于通过所述预置测试框架，根据所述启动参数，启动所述待测试应用程序。

可选的，所述测试模块，还用于在所述确定模块根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长之后，接收任务结束命令，运行所述任务结束命令，停止所述预置测试框架，所述任务结束命令用于停止所述预置测试框架。

可选的，所述测试模块，还用于在启动待测试应用程序之后，判断是否检测到所述待测试应用程序的首页数据，并在检测不到所述待测试应用程序的首页数据时，等待，在累计等待时间超出预设检测时间时，退出应用程序启动时长测试方法。

第三方面，本申请实施例提供一种电子设备，包括：

存储器，用于存储程序指令；

处理器，用于调用并执行所述存储器中的程序指令，以实现如第一方面所述的应用程序启动时长测试方法。

第四方面，本申请实施例一种存储介质，所述存储介质中存储有计算机程序，当应用程序启动时长测试装置的至少一个处理器执行所述计算机程序时，应用程序启动时长测试装置执行如第一方面所述的应用程序启动时长测试方法。

本申请实施例提供的应用程序启动时长测试方法、装置、电子设备及存储介质，通过启动待测试应用程序，并记录该待测试应用程序的启动起始时间和启动结束时间，以及根据该启动起始时间和启动结束时间，确定该待测试应用程序的启动时长，该启动结束时间为该待测试应用程序的首页数据加载完成时的时间，其能够自动、高效、精确、快速得到应用程序的启动时长，解决了现有手动测试方法依赖测试者、测试数据容易出现误差及无法完成大量测试的问题。

附图说明

图1为本申请实施例提供的应用程序启动时长测试方法实施例一的流程示意图；

图2为本申请实施例提供的应用程序启动时长测试方法实施例二的流程示意图；

图3为本申请实施例提供的应用程序启动时长测试方法实施例三的流程示意图；

图4为本申请实施例提供的应用程序启动时长测试方法实施例四的流程示意图；

图5为本申请实施例提供的应用程序启动时长测试方法的整体工作流程图；

图6为本申请实施例提供的应用程序启动时长测试方法中脚本执行调用的逻辑图；

图7为本申请实施例提供的应用程序启动时长测试装置实施例一的结构示意图；

图8为本申请实施例提供的应用程序启动时长测试装置实施例二的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下，对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解：

应用程序：

应用程序在本申请实施例中指运行平台(Android或ISO)平台开发的应用程序，后续简称app。

Appium：

Appium是一种app自动化用户界面(user interface，UI)层测试框架，支持跨平台、支持多种开发语言。

app启动：

当app启动时，若后台没有该app的进程，这时系统会重新创建一个新的进程分配给该app，这种启动方式就叫做app启动。

启动时长：

站在用户的角度，启动时长是指点击终端桌面上的app图标后，直到app首页数据被完全展示的一段时间。

现阶段，衡量一款app的性能是否突出，app的启动时长通常排在第一位。因为若一款app从下载完成到首页被打开花费的时间很长，则表明该app启动太慢，甚至出现启动崩溃现象，这些使得用户的使用体验差，这可能致使用户立即卸载这款app，这样就降低了用户转化率等因素。尤其，随着app版本功能的迭代更新，功能复杂度和代码的量级都会增大，如果在开发的过程把一些耗时的操作、一些非必须的网络请求放到了启动后的主线程中，那么必定会引发app启动过慢。因而，为了确定app的启动时长，在app的开发过程中，需要对app的启动时长进行测试，通过app的启动时长来评价该款app的性能。

本申请实施例针对现有手动测试方法中存在的依赖测试者、测试数据容易出现误差以及无法完成大量测试的问题，提供了一种应用程序启动时长测试方法、装置、电子设备及存储介质，基于预置测试框架可以自动、快速且准确的得到app的启动时长，效率高、精准性高。

可选的，本申请实施例的开发环境可以如下：

1、预置测试框架可以使用Appium框架和unnittest单元测试框架；

2、应用程序测试语言使用python语言。

可选的，本申请实施例中涉及的代码工程架构如下：

Driver.py：负责启动预置测试框架；

Test_LaunchTime.py：负责启动应用程序启动时长测试方法；

RunSscript.py：运行脚本；

Lanuch_Time.txt：记录启动时长的文件。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图1为本申请实施例提供的应用程序启动时长测试方法实施例一的流程示意图。本申请实施例提供的应用程序启动时长测试方法，应用于预置测试框架中，如图1所示，该方法可以包括如下步骤：

步骤101：启动待测试应用程序，并记录该待测试应用程序的启动起始时间和启动结束时间。

其中，该启动结束时间为该待测试应用程序的首页数据加载完成时的时间。

在应用程序开发过程中，为了确定某一应用程序的性能，最简单直接的方法便是测试该应用程序的启动时长，而测试应用程序启动时长的前提是启动该应用程序。可选的，本申请实施例中，将参与测试的应用程序定义为待测试应用程序。

可选的，在本实施例中，可以通过编写测试脚本来启动待测试应用程序。具体的，在预置测试框架中配置待测试应用程序的启动参数，随后通过该预置测试框架调用并执行测试脚本，这样便可以自动启动待测试应用程序。

值得说明的是，在本实施例中，预置测试框架可以Appium服务，其是app自动化UI层的测试框架，支持跨平台、支持多种开发语言。

当待测试应用程序启动的瞬间自动记录下启动起始时间，其类似于手动测试方法中用户手动点击app图标后记录下启动起始时间的步骤。相应的，在待测试应用程序启动后，便检测是否可以查找到待测试应用程序的首页数据，若是，则检测该待测试应用程序的首页数据是否加载完成，并在首页数据加载完成时，自动记录下启动结束时间，此时待测试应用程序已完成启动。

步骤102：根据上述启动起始时间和启动结束时间，确定该待测试应用程序的启动时长。

在本实施例中，在获取到待测试应用程序的启动起始时间和启动结束时间后，利用启动结束时间减去启动起始时间，两者之差便是待测试应用程序的启动时长，即待测试应用程序在一次启动过程中，从开始启动到首页数据加载完成的时长。可选的，本实施例中的启动起始时间和启动结束时间实际上指的是启动起始时刻和启动结束时刻。

本申请实施例提供的应用程序启动时长测试方法，应用于预置测试框架，该方法通过启动待测试应用程序，并记录该待测试应用程序的启动起始时间和启动结束时间，以及根据该启动起始时间和启动结束时间，确定该待测试应用程序的启动时长，该启动结束时间为该待测试应用程序的首页数据加载完成时的时间。该技术方案的测试流程完整，能够自动、高效、精确、快速得到应用程序的启动时长，解决了现有手动测试方法依赖测试者、测试数据容易出现误差及无法完成大量测试的问题。

可选的，图2为本申请实施例提供的应用程序启动时长测试方法实施例二的流程示意图。本申请实施例是在上述实施例的基础上对应用程序启动时长测试方法的进一步说明。如图2所示，本申请实施例提供的应用程序启动时长测试方法，还可以包括如下步骤：

步骤201：获取待测试应用程序的多个启动时长。

可选的，为了得到准确的待测试应用程序的启动时长，可以通过获取多个启动时长，并求其平均值进行判定。

具体的，在执行应用程序启动时长测试方法之前，可以首先设定测试该待测试应用程序启动时长的次数，即预设测试次数，进而在应用程序启动时长测试方法启动之后，根据该预设测试次数，重复执行上述步骤101和步骤102，得到多个启动时长。

可选的，本申请的技术方案中可以首先定义一个启动时长记录文件，这样每次启动应用程序得到的启动时长都可以写入到该启动时长记录文件中，待执行完所有的预设测试次数之后，根据该启动时长记录文件中多个启动时长来计算平均启动时长。

步骤202：根据上述多个启动时长，确定待测试应用程序的平均启动时长。

可选的，可以假定预设测试次数为N，N为正整数，那么循环执行N次上述步骤101和步骤102，得到N个启动时长之后，便可以求出平均启动时长。具体的，N个启动时长相加求和之后再除以N，结果便是该待测试应用程序的平均启动时长。

可选的，理论上预设测试次数越大，得出的启动时长个数越多，最后得到的平均启动时长就越接近待测试应用程序的实际启动时长，也就能越准确反映出待测试应用程序的性能。但是，预设测试次数越大，执行本申请的技术方案花费的时间就越长，因而，具体的预设测试次数需要根据实际情况进行设定。

值得说明的是，应用程序启动时长测试方法每次执行完成后，均会在工程目录下生成“时间戳+Launch_Time”的文件，其内容记录的是待测试应用程序启动开始到首页数据完全加载的时长和平均启动时长。

本申请实施例提供的应用程序启动时长测试方法，通过获取待测试应用程序的多个启动时长，并根据得到的多个启动时长，确定待测试应用程序的平均启动时长。该技术方案利用平均启动时长能够准确反映出待测试应用程序的理论启动时长，避免了根据一个启动时长对应用程序性能做出错误评价的问题。

可选的，图3为本申请实施例提供的应用程序启动时长测试方法实施例三的流程示意图。本申请实施例是在上述实施例的基础上对应用程序启动时长测试方法的进一步说明。如图3所示，本申请实施例提供的应用程序启动时长测试方法，在上述启动待测试应用程序之前，还可以包括如下步骤：

步骤301：接收测试指令，该测试指令用于触发测试上述待测试应用程序的启动时长。

步骤302：根据该测试指令，启动预置测试框架。

可选的，由于本实施例提供的应用程序启动时长测试方法是在预置测试框架下实现的，因而，为了实现自动测试，在启动待测试应用程序之前，首先需要接收到用于触发测试待测试应用程序启动时长的测试指令，进而根据该测试指令启动预置测试框架。

可选的，本申请实施例所述的预置测试框架指的是Appium服务，即应用程序启动时长测试方法需要在Appium服务启动的基础上执行，若Appium服务未启动，那么应用程序启动时长测试方法则无法运行。

值得说明的是，该测试指令可以有两方面作用，一方面用于启动预置测试框架，另一方面在预置测试框架启动后，用于触发测试待测试应用程序的启动时长。

本申请实施例提供的应用程序启动时长测试方法，在启动待测试应用程序之前，通过接收测试指令，该测试指令用于触发测试待测试应用程序的启动时长，并根据该测试指令，启动预置测试框架，为利用该应用程序启动时长测试方法确定待测试应用程序的启动时长奠定了基础。

可选的，在上述实施例三的基础上，图4为本申请实施例提供的应用程序启动时长测试方法实施例四的流程示意图。如图4所示，在上述步骤302之前，即在根据该测试指令，启动预置测试框架之前，还可以包括如下步骤：

步骤401：配置待测试应用程序的启动参数。

可选的，该启动参数可以包括：待测试应用程序所在的设备名称、待测试应用程序的运行平台和待测试应用程序的系统版本等。

在本申请实施例中，驱动器(Drvier)负责配置待测试应用程序的启动参数，比如设备名称、运行平台、系统版本等参数。值得说明的是，该启动参数包括但不局限于设备名称、运行平台、系统版本等参数，其还可以根据实际情况包括其他的启动参数，此处不对其进行限定。

步骤402：在上述预置测试框架中创建启动参数。

具体的，当配置完待测试应用程序的启动参数之后，为了启动待测试应用程序，需要在上述预置测试框架中创建启动参数。本实施例中，在上述预置测试框架中创建启动参数可以解释为AppiumWebDrvier中创建启动参数。该AppiumWebDrvier实际上是一个扩展的WebDriver协议，其与Appium服务相对应，即测试人员可以在编写测试用例时，将WebDriver协议扩展到需要的测试框架中(例如，本申请实施例中的Appium服务)。

相应的，上述步骤101中的启动待测试应用程序可以通过如下步骤实现：

通过预置测试框架，根据上述启动参数，启动待测试应用程序。

具体的，由于应用程序启动时长测试方法的执行需要以预置测试框架(本实施了中的Appium服务)运行为基础，因而，在上述预置测试框架中创建启动参数后，通过预置测试框架，根据启动参数，便可以启动该启动参数对应的待测试应用程序。

本申请实施例提供的应用程序启动测试方法，通过配置待测试应用程序的启动参数，在预置测试框架中创建启动参数，这样便可以通过该预置测试框架，根据启动参数，启动上述待测试应用程序。该技术方案能够自动启动待测试应用程序，为自动确定待测试应用程序的启动时长提供了实现可能。

进一步的，本申请实施例提供的应用程序启动时长测试方法，在上述步骤102之后，即在根据上述启动起始时间和启动结束时间，确定该待测试应用程序的启动时长之后，还可以包括如下步骤：

接收任务结束命令，该任务结束命令用于停止上述预置测试框架；

运行该任务结束命令，停止上述预置测试框架。

在本实施例中，当确定出待测试应用程序的启动时长之后，即测试流程执行完毕时，上述预置测试框架依然处于运行状态，此时，上述应用程序启动时长测试方法对应的测试脚本仍不能停止，因而需要停止预置测试框架以停止应用程序启动时长测试方法。

具体的，可以首先确定出预置测试框架的监听端口，进而通过运行任务结束命令停止预置测试框架。

可选的，在上述图1对应的实施例中，具体的，在上述步骤101中，在启动待测试应用程序之后，该应用程序启动时长测试方法还可以包括如下步骤：

判断是否检测到该待测试应用程序的首页数据；

若是，则等待，若否，在累计等待时间超出预设检测时间时，退出该应用程序启动时长测试方法。

具体的，在启动待测试应用程序之后，有可能出现待测试应用程序无法完成启动或启动过慢的问题，通过判断是否检测到该待测试应用程序的首页数据来确定。具体的，当检测不到该待测试应用程序的首页数据时，则继续检测并且等待，直到累计等待时间超出预设检测时间。若在累计等待时间小于预设检测时间时，检测到待测试应用程序的首页数据，此时可断定待测试应用程序只是启动较慢，相应的，在首页数据加载完成时，记录下启动结束时间。若在累计等待时间超出预设检测时间时，仍未检测到该待测试应用程序的首页数据，此时则触发程序异常的操作，退出该测试方法。此时可以断定待测试应用程序无法完成启动。

值得说明的是，若不设置预设检测时间，且当检测不到待测试应用程序的首页数据时，程序将会进入死循环，无法自动退出应用程序启动时长测试方法，因而，本实施例设置了预设检测时间，即设置检测等待的最长时间段来避免程序进入死循环。可选的，该预设检测时间可以设置为10s，当累计等待时间超过10s时，则触发异常操作程序，退出运行测试方法。

本申请实施例提供的应用程序启动时长测试方法，通过设置预设检测时间，这样在启动待测试应用程序之后，若检测不到该待测试应用程序的首页数据，且累计等待时间超出预设检测时间时，可以自动退出该测试方法，避免了程序进入死循环的问题。

综合上述实施例可知，图5为本申请实施例提供的应用程序启动时长测试方法的整体工作流程图。如图5所示，该整体工作流程具体为：

步骤501、接收输入的测试次数；

步骤502、通过预置测试框架启动待测试应用程序；

步骤503、在待测试应用程序启动的瞬间，记录启动起始时间；

步骤504、检测待测试应用程序的首页数据是否加载完成；

步骤505、在该待测试应用程序的首页数据加载完成时，记录启动结束时间；

步骤506、确定待测试应用程序的一个启动时长，该启动时长等于启动结束时间减去启动起始时间；

步骤507、将该启动时长写入启动时长记录文件；

步骤508、判断测试次数是否大于或等于预设测试次数，若是执行步骤509，若否，执行步骤502；

步骤509、根据启动时长记录文件中的所有启动时长求出平均启动时长。

相应的，该平均启动时长便可以作为待测试应用程序的启动时长。

可选的，图6为本申请实施例提供的应用程序启动时长测试方法中脚本执行调用的逻辑图。如图6所示，该方法共包括三个线程，即线程一、线程二和主线程，其中，线程一用于管理预置测试框架，线程二用于获取待测试应用程序的启动时长，主线程用于控制测试脚本的运行。如图6所示，脚本执行的逻辑流程如下：

步骤601、接收测试指令，该测试指令用于触发测试待测试应用程序的启动时长；

该测试指令可以为python RunScript.py-t 10，这个指令可以分为三部分解读。python RunScri.py表示运行一个python的文件，-t表示需要输入“预设测试次数”参数，10表示“预设测试次数”是10次。

步骤602、根据预设测试次数，执行测试指令；

在线程一中，步骤603、启动预置测试框架；

在线程二中，步骤604、利用该预置测试框架，根据在预置测试框架中创建的启动参数，启动待测试应用程序；

步骤605、执行应用程序启动时长测试方法，获取待测试应用程序的启动时长；

步骤606、将启动时长写入启动时长记录文件中，根据预设测试次数，然后转回执行605；

步骤607、退出线程二，应用程序启动时长测试方法流程结束；

在线程一中，步骤608、关闭预置测试框架；

步骤609、退出主线程，脚本任务结束。

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

图7为本申请实施例提供的应用程序启动时长测试装置实施例的结构示意图。如图7所示，该应用程序启动时长测试装置，应用于预置测试框架中，该装置可以包括：测试模块701和确定模块702。

其中，该测试模块701，用于启动待测试应用程序，并记录所述待测试应用程序的启动起始时间和启动结束时间，所述启动结束时间为所述待测试应用程序的首页数据加载完成时的时间；

该确定模块702，用于根据所述测试模块701得到的所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长。

可选的，在本申请的一实施例中，上述测试模块701，还用于获取所述待测试应用程序的多个启动时长。

相应的，上述确定模块702，还用于根据测试模块701得到的所述多个启动时长，确定所述待测试应用程序的平均启动时长。

可选的，在本申请的另一实施例中，上述测试模块701，还用于在启动待测试应用程序之前接收测试指令，根据所述测试指令，启动预置测试框架，所述测试指令用于触发测试所述待测试应用程序的启动时长。

可选的，上述测试模块701，还用于在所述根据所述测试指令，启动所述预置测试框架之前，配置所述待测试应用程序的启动参数，在所述预置测试框架中创建该启动参数，所述启动参数包括：所述待测试应用程序所在的设备名称、所述待测试应用程序的运行平台和所述待测试应用程序的系统版本；

相应的，测试模块701，用于启动待测试应用程序，具体为：

该测试模块701，用于通过所述预置测试框架，根据所述启动参数，启动所述待测试应用程序。

可选的，在本申请的再一实施例中，上述测试模块701，还用于在上述确定模块702根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长之后，接收任务结束命令，运行所述任务结束命令，停止所述预置测试框架，所述任务结束命令用于停止所述预置测试框架。

可选的，在本申请的又一实施例中，上述测试模块701，还用于在启动待测试应用程序之后，判断是否检测到所述待测试应用程序的首页数据，并在检测不到所述待测试应用程序的首页数据时，等待，在累计等待时间超出预设检测时间时，退出应用程序启动时长测试方法。

本实施例的装置对应的可用于执行图1-6所示方法实施例的技术方案，其实现原理和有益效果类似，此处不再赘述。

本申请各装置实施例中可以根据上述方法示例对应用程序启动时长测试装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请各实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

图8为本申请实施例提供的应用程序启动时长测试装置实施例二的结构示意图，包括：存储器801和处理器802.

其中，存储器801，用于存储程序指令，该存储器可以是flash(闪存)。处理器802，用于调用并执行存储器中的程序指令，以实现图1～图6任一所示的应用程序启动时长测试方法中的各个步骤。具体可以参见前面方法实施例中的相关描述。

可选地，存储器801既可以是独立的，也可以是与处理器802集成在一起的。

本申请实施例还提供一种电子设备，该电子设备用于执行图1～图6任一所示的应用程序启动时长测试方法中的各个步骤。

本申请还提供一种存储介质，存储介质中存储有计算机程序，当应用程序启动时长测试装置的至少一个处理器执行该计算机程序时，应用程序启动时长测试装置执行图1～图6任一所述的方法。

本申请还提供一种程序产品，该程序产品包括计算机程序，该计算机程序存储在存储介质中。应用程序启动时长测试装置的至少一个处理器可以从存储介质读取该计算机程序，至少一个处理器执行该计算机程序使得应用程序启动时长测试装置实施图1～图6任一所述的方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (14)

1.一种应用程序启动时长测试方法，其特征在于，应用于预置测试框架中，所述方法包括：

启动待测试应用程序，并记录所述待测试应用程序的启动起始时间和启动结束时间，所述启动结束时间为所述待测试应用程序的首页数据加载完成时的时间；

根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长。

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

获取所述待测试应用程序的多个启动时长；

根据所述多个启动时长，确定所述待测试应用程序的平均启动时长。

3.根据权利要求1所述的方法，其特征在于，在所述启动待测试应用程序之前，还包括：

接收测试指令，所述测试指令用于触发测试所述待测试应用程序的启动时长；

根据所述测试指令，启动所述预置测试框架。

4.根据权利要求3所述的方法，其特征在于，在所述根据所述测试指令，启动所述预置测试框架之前，还包括：

配置所述待测试应用程序的启动参数，所述启动参数包括：所述待测试应用程序所在的设备名称、所述待测试应用程序的运行平台和所述待测试应用程序的系统版本；

在所述预置测试框架中创建该启动参数；

所述启动待测试应用程序，包括：

通过所述预置测试框架，根据所述启动参数，启动所述待测试应用程序。

5.根据权利要求1-4任一项所述的方法，其特征在于，在所述根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长之后，还包括：

接收任务结束命令，所述任务结束命令用于停止所述预置测试框架；

运行所述任务结束命令，停止所述预置测试框架。

6.根据权利要求1-4任一项所述的方法，其特征在于，在所述启动待测试应用程序之后，还包括：

判断是否检测到所述待测试应用程序的首页数据；

若检测不到所述待测试应用程序的首页数据，则等待；

在累计等待时间超出预设检测时间时，退出所述应用程序启动时长测试方法。

7.一种应用程序启动时长测试装置，其特征在于，应用于预置测试框架中，所述装置包括：

测试模块，用于启动待测试应用程序，并记录所述待测试应用程序的启动起始时间和启动结束时间，所述启动结束时间为所述待测试应用程序的首页数据加载完成时的时间；

确定模块，用于根据所述测试模块得到的所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长。

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

所述测试模块，还用于获取所述待测试应用程序的多个启动时长；

所述确定模块，还用于根据所述测试模块得到的所述多个启动时长，确定所述待测试应用程序的平均启动时长。

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

所述测试模块，还用于在启动待测试应用程序之前接收测试指令，根据所述测试指令，启动所述预置测试框架，所述测试指令用于触发测试所述待测试应用程序的启动时长。

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

所述测试模块，还用于在所述根据所述测试指令，启动所述预置测试框架之前，配置所述待测试应用程序的启动参数，在所述预置测试框架中创建该启动参数，所述启动参数包括：所述待测试应用程序所在的设备名称、所述待测试应用程序的运行平台和所述待测试应用程序的系统版本；

相应的，所述测试模块，用于启动待测试应用程序，具体为：

所述测试模块，用于通过所述预置测试框架，根据所述启动参数，启动所述待测试应用程序。

11.根据权利要求7-10任一项所述的装置，其特征在于，

所述测试模块，还用于在所述确定模块根据所述启动起始时间和所述启动结束时间，确定所述待测试应用程序的启动时长之后，接收任务结束命令，运行所述任务结束命令，停止所述预置测试框架，所述任务结束命令用于停止所述预置测试框架。

12.根据权利要求7-10任一项所述的装置，其特征在于，

所述测试模块，还用于在启动待测试应用程序之后，判断是否检测到所述待测试应用程序的首页数据，并在检测不到所述待测试应用程序的首页数据时，等待，在累计等待时间超出预设检测时间时，退出应用程序启动时长测试方法。

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

存储器，用于存储程序指令；

处理器，用于调用并执行所述存储器中的程序指令，以实现权利要求1～6任一项所述的应用程序启动时长测试方法。

14.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，当应用程序启动时长测试装置的至少一个处理器执行所述计算机程序时，应用程序启动时长测试装置执行权利要求1～6任一项所述的应用程序启动时长测试方法。