CN112181822A - 一种测试方法和应用程序的启动耗时测试方法 - Google Patents

Abstract

本公开关于一种测试方法和应用程序的启动耗时测试方法。所述方法包括：基于第一测试框架和第二测试框架搭建当前设备环境；接收测试请求，所述测试请求包括测试配置参数；在所述当前设备环境下，根据所述测试配置参数生成适配所述第一测试框架的第一测试指令，所述第一测试指令使用所述第一测试框架支持的第一类编程语言描述；当目标测试对象的运行环境支持第二类编程语言时，将所述第一测试指令转化为第二测试指令，所述第二测试指令使用所述第二测试框架支持的所述第二类编程语言描述；将所述第二测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二测试指令。利用测试框架可以提高相关测试指令生成的效率，进而提高测试效率。

Description

一种测试方法和应用程序的启动耗时测试方法

技术领域

本公开涉及互联网通信技术领域，尤其涉及一种测试方法和应用程序的启动耗时测试方法。

背景技术

随着互联网通信技术的迅猛发展以及终端设备的快速升级换代，越来越多的程序被开发出来，终端设备上可以安装的应用程序(Application，APP)也越来越多。各种各样的应用程序使人们的工作、生活变得丰富多彩，人们可以通过安装于终端上的应用程序进行视频直播、网上购物、导航等等。

不同终端设备的尺寸、操作***、硬件配置等往往各异，需要对终端的性能表现进行测试。在相关技术中，采用adb(安卓调试桥)这一通用命令行工具来建立测试方与被测试方(比如终端设备)间的连接，测试方向被测试方发送adb命令以使得被测试方根据该adb命令执行相关测试方案。adb命令往往由测试人员手动输入，对于测试方案中需要被测试方不断执行的相同测试步骤且若一个测试步骤对应一个adb命令，则需要测试人员不断输入adb命令。这样会导致测试成本高、测试效率低。

发明内容

本公开提供一种测试方法和应用程序的启动耗时测试方法，以至少解决相关技术中测试成本高、测试效率低的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种测试方法，所述方法包括：

基于第一测试框架和第二测试框架搭建当前设备环境；

接收测试请求，所述测试请求包括测试配置参数；

在所述当前设备环境下，根据所述测试配置参数生成适配所述第一测试框架的第一测试指令，所述第一测试指令使用所述第一测试框架支持的第一类编程语言描述；

当目标测试对象的运行环境支持第二类编程语言时，将所述第一测试指令转化为第二测试指令，所述第二测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

将所述第二测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二测试指令。

在一示例性的实施方式中，所述将所述第二测试指令发送至所述目标测试对象步骤，包括：

调用所述第二测试框架的预设功能建立与所述目标测试对象间的通信通道；

基于所述通信通道将所述第二测试指令发送给所述目标测试对象。

在一示例性的实施方式中，所述根据所述测试配置参数生成适配所述第一测试框架的第一测试指令步骤，包括：

获取对应所述第一测试框架的测试配置模板；

拼接所述测试配置模板和所述测试配置参数，得到所述第一测试指令。

根据本公开实施例的第二方面，提供一种应用程序的启动耗时测试方法，所述方法包括：

基于第一测试框架和第二测试框架搭建当前设备环境；

接收启动耗时测试请求，所述启动耗时测试请求包括目标应用程序的安装包信息；

在所述当前设备环境下，根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令，所述第一启动耗时测试指令使用所述第一测试框架支持的第一类编程语言描述；

当目标测试对象的运行环境支持第二类编程语言时，将所述第一启动耗时测试指令转化为第二启动耗时测试指令，所述第二启动耗时测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

将所述第二启动耗时测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二启动耗时测试指令。

在一示例性的实施方式中，当所述启动耗时测试请求还包括启动循环次数时，所述根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令步骤，包括：

获取启动循环次数计数规则，所述启动循环次数计数规则指示不对冷启动计数；

根据所述启动循环次数和所述启动循环次数计数规则得到循环次数描述信息；

根据所述安装包信息和所述循环次数描述信息生成适配所述第一测试框架的第一启动耗时测试指令。

在一示例性的实施方式中，当所述安装包信息指示至少两个版本时，所述根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令步骤，包括：

获取版本规则，所述版本规则指示不同版本的安装包按顺序依次启动；

根据所述安装包信息和所述版本规则生成适配所述第一测试框架的第一启动耗时测试指令。

在一示例性的实施方式中，所述将所述第二启动耗时测试指令发送至所述目标测试对象步骤之后，所述方法还包括：

从所述目标测试对象获取目标测试日志；

确定目标字段；

从所述目标测试日志中提取与所述目标字段相关联的日志数据；

根据所述相关联的日志数据得到启动耗时测试结果。

在一示例性的实施方式中，所述从所述目标测试对象获取目标测试日志步骤，包括：

从所述目标测试对象获取记录进程运行信息的第一类测试日志和记录页面加载信息的第二类测试日志；

利用所述第一类测试日志检测所述第二类测试日志中是否存在异常数据；

当所述第二类测试日志中不存在异常数据时，将所述第二类测试日志作为所述目标测试日志。

在一示例性的实施方式中，当所述启动耗时测试请求还包括启动循环次数时，所述根据所述相关联的日志数据得到启动耗时测试结果步骤，包括：

根据所述相关联的日志数据确定每次启动所述目标应用程序所对应的启动耗时；

根据每次启动所述目标应用程序所对应的启动耗时，得到所述启动循环次数次启动所述目标应用程序的总启动耗时以及中位启动耗时；

根据所述总启动耗时和所述启动循环次数得到所述目标应用程序的平均启动耗时。

在一示例性的实施方式中，当所述安装包信息指示至少两个版本时，所述根据所述相关联的日志数据得到启动耗时测试结果步骤，包括：

根据所述相关联的日志数据确定每个版本的安装包所对应的目标应用程序启动耗时。

根据本公开实施例的第三方面，提供一种测试装置，所述装置包括：

第一环境搭建单元，被配置为执行基于第一测试框架和第二测试框架搭建当前设备环境；

测试请求接收单元，被配置为执行接收测试请求，所述测试请求包括测试配置参数；

第一指令生成单元，被配置为执行在所述当前设备环境下，根据所述测试配置参数生成适配所述第一测试框架的第一测试指令，所述第一测试指令使用所述第一测试框架支持的第一类编程语言描述；

第二指令得到单元，被配置为执行当目标测试对象的运行环境支持第二类编程语言时，将所述第一测试指令转化为第二测试指令，所述第二测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

第二指令发送单元，被配置为执行将所述第二测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二测试指令。

在一示例性的实施方式中，所述第二指令发送单元包括：

通信通道建立单元，被配置为执行调用所述第二测试框架的预设功能建立与所述目标测试对象间的通信通道；

第二指令发送子单元，被配置为执行基于所述通信通道将所述第二测试指令发送给所述目标测试对象。

在一示例性的实施方式中，所述第一指令生成单元包括：

模板获取单元，被配置为执行获取对应所述第一测试框架的测试配置模板；

拼接单元，被配置为执行拼接所述测试配置模板和所述测试配置参数，得到所述第一测试指令。

根据本公开实施例的第四方面，提供一种应用程序的启动耗时测试装置，所述装置包括：

第二环境搭建单元，被配置为执行基于第一测试框架和第二测试框架搭建当前设备环境；

启动耗时测试请求接收单元，被配置为执行接收启动耗时测试请求，所述启动耗时测试请求包括目标应用程序的安装包信息；

第一启动耗时指令生成单元，被配置为执行在所述当前设备环境下，根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令，所述第一启动耗时测试指令使用所述第一测试框架支持的第一类编程语言描述；

第二启动耗时指令得到单元，被配置为执行当目标测试对象的运行环境支持第二类编程语言时，将所述第一启动耗时测试指令转化为第二启动耗时测试指令，所述第二启动耗时测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

第二启动耗时指令发送单元，被配置为执行将所述第二启动耗时测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二启动耗时测试指令。

在一示例性的实施方式中，当所述启动耗时测试请求还包括启动循环次数时，所述第一启动耗时指令生成单元包括：

第一规则获取单元，被配置为执行获取启动循环次数计数规则，所述启动循环次数计数规则指示不对冷启动计数；

描述信息得到单元，被配置为执行根据所述启动循环次数和所述启动循环次数计数规则得到循环次数描述信息；

第一类指令生成单元，被配置为执行根据所述安装包信息和所述循环次数描述信息生成适配所述第一测试框架的第一启动耗时测试指令。

在一示例性的实施方式中，当所述安装包信息指示至少两个版本时，所述第一启动耗时指令生成单元包括：

第二规则获取单元，被配置为执行获取版本规则，所述版本规则指示不同版本的安装包按顺序依次启动；

第二类指令生成单元，被配置为执行根据所述安装包信息和所述版本规则生成适配所述第一测试框架的第一启动耗时测试指令。

在一示例性的实施方式中，所述装置还包括：

目标测试日志获取单元，被配置为执行从所述目标测试对象获取目标测试日志；

目标字段确定单元，被配置为执行确定目标字段；

提取单元，被配置为执行从所述目标测试日志中提取与所述目标字段相关联的日志数据；

启动耗时测试结果得到单元，被配置为执行根据所述相关联的日志数据得到启动耗时测试结果。

在一示例性的实施方式中，所述目标测试日志获取单元包括：

测试日志获取单元，被配置为执行从所述目标测试对象获取记录进程运行信息的第一类测试日志和记录页面加载信息的第二类测试日志；

检测单元，被配置为执行利用所述第一类测试日志检测所述第二类测试日志中是否存在异常数据；

目标测试日志确定单元，被配置为执行当所述第二类测试日志中不存在异常数据时，将所述第二类测试日志作为所述目标测试日志。

在一示例性的实施方式中，当所述启动耗时测试请求还包括启动循环次数时，所述启动耗时测试结果得到单元包括：

单次启动耗时确定单元，被配置为执行根据所述相关联的日志数据确定每次启动所述目标应用程序所对应的启动耗时；

总启动耗时确定单元，被配置为执行根据每次启动所述目标应用程序所对应的启动耗时，得到所述启动循环次数次启动所述目标应用程序的总启动耗时以及中位启动耗时；

平均启动耗时确定单元，被配置为执行根据所述总启动耗时和所述启动循环次数得到所述目标应用程序的平均启动耗时。

在一示例性的实施方式中，当所述安装包信息指示至少两个版本时，所述启动耗时测试结果得到单元包括：

单版本目标应用程序启动耗时确定单元，被配置为执行根据所述相关联的日志数据确定每个版本的安装包所对应的目标应用程序启动耗时。

根据本公开实施例的第五方面，提供一种电子设备，包括：

处理器；

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

其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的测试方法或者如第二方面所述的应用程序的启动耗时测试方法。

根据本公开实施例的第六方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如第一方面所述的测试方法或者如第二方面所述的应用程序的启动耗时测试方法。

根据本公开实施例的第七方面，提供一种计算机程序产品，当其在计算机上运行时，使得所述计算机执行第一方面所述的测试方法或者如第二方面所述的应用程序的启动耗时测试方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

基于第一测试框架和第二测试框架搭建测试方所在的当前设备环境，根据测试请求中的测试配置参数生成适配第一测试框架的第一测试指令(第一类编程语言)，当目标测试对象(被测试方)的运行环境支持第二类编程语言时，将第一测试指令转化为第二测试指令(第二类编程语言)，进而将第二测试指令发送至目标测试对象，以使得目标测试对象执行第二测试指令。相较于输入adb命令，上述技术方案中基于测试框架来生成测试指令，使得测试指令的生成更加方便。对于需要不断执行的相同测试步骤(若一个测试步骤对应一个adb命令)，利用测试框架可以提高相关测试指令生成的效率，进而提高测试效率。基于第一测试框架和第二测试框架搭建的当前设备环境，为转换测试指令的适配编程语言提供了条件，使得将测试指令发送给目标测试对象更加顺利。此外，为开发出与终端设备更适配的应用程序，在开发过程中需要对所开发的应用程序进行测试，也可以利用上述技术方案来实现。

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

附图说明

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

图1是根据一示例性实施例示出的一种测试方法的流程图。

图2是根据一示例性实施例示出的一种应用程序的启动耗时测试方法的流程图。

图3是根据一示例性实施例示出的将第二测试指令发送至目标测试对象的流程图。

图4也是根据一示例性实施例示出的一种应用程序的启动耗时测试方法的流程图。

图5是根据一示例性实施例示出的adb(安卓调试桥)的应用场景图。

图6是根据一示例性实施例示出的应用程序的启动耗时测试方法的架构设计图。

图7也是根据一示例性实施例示出的一种应用程序的启动耗时测试方法的流程图。

图8是根据一示例性实施例示出的一种测试装置的框图。

图9是根据一示例性实施例示出的一种应用程序的启动耗时测试装置的框图。

图10是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

对本公开提供的实施例进行进一步详细说明之前，对实施例中涉及的名词和术语进行说明，本公开提供的实施例中涉及的名词和术语适用于如下的解释。

Python：它是一种跨平台的计算机程序设计语言，它是一个高层次的结合了解释性、编译性、互动性和面向对象的脚本语言。

Pytest：它是一款以Python为开发语言的测试框架。

Java：它是一门面向对象编程语言，它具有简单性、面向对象、分布式、健壮性、安全性、平***立与可移植性、多线程、动态性等特点。

UiAutomator：它是谷歌官方提供的一个测试框架，它支持Java。

本公开提供的测试方法可以应用于安装有测试***或者应用程序的启动耗时测试***的电子设备中，本公开提供的应用程序的启动耗时测试方法可以应用于安装有应用程序的启动耗时测试***的电子设备中。电子设备可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云计算服务的云服务器。电子设备还可以是台式电脑、平板电脑、笔记本电脑等。相对于作为测试方的电子设备，被测试方可以是终端设备本身，也可以是由终端设备作为运行载体的应用程序，终端设备可以是智能手机、台式电脑、平板电脑、笔记本电脑、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、数字助理、智能音箱、智能可穿戴设备等。终端和服务器之间可以通过有线网络或者无线网络连接。图1是根据一示例性实施例示出的一种测试方法的流程图，如图1所示，该方法包括下述步骤S101至S105。

在步骤S101中，基于第一测试框架和第二测试框架搭建当前设备环境。

第一测试框架支持第一类编程语言，第二测试框架支持第二类编程语言。可以获取对应第一测试框架的第一框架文件以及获取对应第二测试框架的第二框架文件，基于第一框架文件和第二框架文件搭建当前设备环境。若作为测试方的电子设备为服务器或者个人计算机(Personal Computer，PC)，搭建当前设备环境相当于在服务器或者PC部署第一测试框架和第二测试框架，以使得服务器或者PC具有自动化测试工作环境。

在一个实施例中，第一类测试框架所支持的第一类编程语言可以是Python，第一类测试框架可以采用Pytest、Robot Framework(一种Python测试框架，主要被用在测试驱动(test-driven)类型的开发与验收中)、UnitTest/PyUnit(一种标准化的针对单元测试的Python类自动化测试框架)、Behave(一种基于“行为驱动开发(BDD)”范式的Python测试框架)、Lettuce(一种基于Cucumber和Python的行为驱动类自动化工具；Cucumber，它是基于BDD的一个自动化测试副产品)等等。第二类测试框架所支持的第二类编程语言可以是Java，第二类测试框架可以采用UiAutomator2(基于UiAutomator派生的一个测试框架)，UiAutomator2基于同源的UiAutomator支持第二类编程语言(Java)，同时UiAutomator2还支持第一类编程语言(Python)。

在另一个实施例中，可以利用作为测试方的电子设备构建一个测试平台。测试平台提供与测试人员进行交互的交互界面。比如，在具有显示界面的PC上部署第一测试框架和第二测试框架，显示界面可以作为与测试人员进行交互的交互界面。在不具有显示界面的服务器上部署第一测试框架和第二测试框架，可以纳入与服务器通信连接的客户端一起构建测试平台，由该客户端提供显示界面以与测试人员进行交互。

在步骤S102中，接收测试请求，所述测试请求包括测试配置参数。

测试请求可以对应不同类型的测试，进而对应不同类型测试中的不同测试项目。测试请求可以对应功能测试，具体的测试项目可以是参数类型测试、边界值测试等。测试请求可以对应性能测试，具体的测试项目可以是响应时间测试、并发数和吞吐量测试等。测试请求可以对应安全测试，具体的测试项目可以是关于敏感信息是否加密的测试、关于接口是否防恶意请求的测试等。不同的测试请求可以对应不同的测试配置参数。测试配置参数可以用于构成一个测试用例的测试输入、执行条件等。

当然，考虑到被测试方为终端设备本身，或者为由终端设备作为运行载体的应用程序，那么可以将终端设备作为目标测试对象。相应的，测试请求还包括目标测试对象的标识信息。

在步骤S103中，在所述当前设备环境下，根据所述测试配置参数生成适配所述第一测试框架的第一测试指令，所述第一测试指令使用所述第一测试框架支持的第一类编程语言描述。

在确定测试配置参数的情况下，第一测试指令可以看作是基于第一测试框架进行编写得到的。在实际应用中，第一测试框架可以采用Pytest，第一测试指令则是基于Pytest进行编写得到的，第一测试指令是使用Python描述的。

在一个实施例中，步骤S103可以包括步骤S1031，获取对应所述第一测试框架的测试配置模板；以及步骤S1032，拼接所述测试配置模板和所述测试配置参数，得到所述第一测试指令。

测试配置参数需要与对应的测试配置项一起来构成一个测试用例。可以先获取对应第一测试框架的测试配置模板，测试配置模板可以是预设设置的，测试配置模板是使用第一类编程语言描述的，测试配置模板可以包括预先设置的多个测试配置项；然后拼接测试配置模板和测试配置参数，相当于将测试配置参数与对应的测试配置项进行匹配，进而得到使用第一类编程语言描述的第一测试指令。这样可以提高测试指令的生成速度。比如测试请求包括3个测试配置参数：测试配置参数a(对应的测试配置项为测试配置项A)、测试配置参数b(对应的测试配置项为测试配置项B)和测试配置参数c(对应的测试配置项为测试配置项C)。测试配置模板包括测试配置项A、测试配置项B、测试配置项C和测试配置项D。那么将测试配置参数a填入测试配置模板中的测试配置项A对应的可填位置、将测试配置参数b填入测试配置中的测试配置项B应的可填位置、将测试配置参数c填入测试配置模板中的测试配置项C应的可填位置，测试配置模板中的测试配置项D应的可填位置则可以置空。

在另一个实施例中，测试请求可以由测试人员通过前述步骤S101中提及的测试平台的交互界面生成，交互界面上列有测试配置参数选项，测试人员可根据实际需求进行填写。测试平台根据填写的测试配置参数生成适配第一测试框架的第一测试指令。

在步骤S104中，当目标测试对象的运行环境支持第二类编程语言时，将所述第一测试指令转化为第二测试指令，所述第二测试指令使用所述第二测试框架支持的所述第二类编程语言描述。

当目标测试对象的运行环境支持第二类编程语言时，目标测试对象执行使用第一类编程语言描述的第一测试指令便存在困难，这样会影响测试的进行。由于当前设备环境的构建用到了第二测试框架，可以借助第二测试框架将使用第一类编程语言描述的第一测试指令转化为使用第二类编程语言描述的第二测试指令，通过转化测试指令的适配编程语言可以保证测试指令能够被目标测试对象有效执行。

在一个实施例中，第二类测试框架采用UiAutomator2，虽然UiAutomator2本身支持第一类编程语言(Python)，但是基于同源的UiAutomator也可以支持第二类编程语言(Java)。可以通过调用第二类测试框架的相关功能转化测试指令的适配编程语言。在实际应用中，第一测试框架可以采用Pytest，可以由Pytest调用UiAutomator2的相关功能，以使得使用Python描述的第一测试指令转化为使用Java描述的第二测试指令。

在步骤S105中，将所述第二测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二测试指令。

使用第二类编程语言描述的第二测试指令可以基于adb(安卓调试桥)发送给相连接的目标测试对象。当存在至少两个相连接的测试对象时，可以通过测试请求中的目标测试对象的标识信息进行确定。

下面对“基于adb(安卓调试桥)发送给相连接的目标测试对象”进行介绍，可参考图5。图5中左侧的为作为测试方的PC，右侧为作为被测试方的安卓(Android)手机或者是作为被测试方的应用程序的运行载体(Android手机)。adb作为一功能多样的命令行工具，可以让PC与Android手机进行通信。PC通过adb命令可以执行各种设备操作(例如安装、启动、调试应用)。adb作为一种客户端-服务器程序，包括以下三个组件：

客户端(adb client)：用于发送命令。它运行在PC上，即DDMS(DalvikDebugMonitor Service，它是Android开发环境中的Dalvik虚拟机调试监控服务)或者在Windowsdos(一种***命令)下启动的adb shell(一种与adb相关的命令)。

守护程序(adbd，adbd服务进程)：用于在设备上运行命令。它运行在Android手机上，它在每个设备上作为后台进程运行。

服务器(adb server)：用于管理客户端与守护程序之间的通信，它和守护程序可通过USB(Universal Serial Bus，通用串行总线)或TCP(Transmission Control Protoco，传输控制协议)连接。它运行在PC上，它在PC上作为后台进程运行。它既作为adb client的服务端，也作为守护程序的客户端。

当启动某个adb client时，该客户端会先检查是否有adb server作为后台进程正在运行。如果没有，则会启动adb server。adb server在启动后会与本地TCP端口5037绑定，并监听adb client发出的命令。adb server会与正在运行的设备建立连接，它通过扫描5555到5585之间(该范围供前16个模拟器使用)的奇数号端口查找设备。adb server一旦发现守护程序(adbd)，便会与相应的端口建立连接。每个设备都使用一对按顺序排列的端口，包括用于控制台连接的偶数号端口和用于adb连接的奇数号端口。服务器与设备建立连接后，测试人员可以使用adb命令访问这些设备。一般情况下，adb通过USB与设备进行通信，但也可以在通过USB完成一些初始设置后，通过WLAN(Wireless Local Area Network，无线局域网)使用adb。

相应的，可以先将第二测试指令传递至测试方的adb client，再由adb client通过adb server、adbd服务进程传递至目标测试对象。

在一个实施例中，如图3所示，步骤S105可以包括步骤S1051，调用所述第二测试框架的预设功能建立与所述目标测试对象间的通信通道；以及步骤S1052，基于所述通信通道将所述第二测试指令发送给所述目标测试对象。

由于目标测试对象的运行环境支持第二类编程语言，第二测试框架支持第二类编程语言，那么可以通过调用第二测试框架的预设功能来建立与目标测试对象间的通信通道，进而通过该通信通道传递第二测试指令。这里的通信通道可以视作上述adb，调用第二测试框架的预设功能的步骤起到了触发adb工作的作用。

需要说明的是，在实际应用中，第一测试框架可以采用Pytest，第二类测试框架采用UiAutomator2。可以由Pytest调用UiAutomator2的预设功能，以使得步骤S104中“将所述第一测试指令转化为第二测试指令”和步骤S105中“将所述第二测试指令发送至所述目标测试对象”一起实现。UiAutomator在测试场景中具有一定的局限性，比如对于测试指令的语言、打包形式，这影响着对于运行安卓***的终端设备的测试效率。利用Pytest编写测试指令，其中Python相比Java简单灵活更易上手，同时Pytest框架具有很多第三方插件并且可以自定义扩展，比如pytest-html(完美html测试报告生成；html，超文本标记语言，是一种标识性的语言)、pytest-rerunfailures(失败用例重复执行)等。这样可以降低指令生成难度、扩大适用范围(更多工作人员可以参与测试指令编写)、提高指令生成效率。利用UiAutomator2进行两类编程语言的转化以及触发adb工作可以提高测试指令的传递速度。

上述实施例中提供的测试方法，基于第一测试框架和第二测试框架搭建测试方所在的当前设备环境，根据测试请求中的测试配置参数生成适配第一测试框架的第一测试指令(第一类编程语言)，当目标测试对象(被测试方)的运行环境支持第二类编程语言时，将第一测试指令转化为第二测试指令(第二类编程语言)，进而将第二测试指令发送至目标测试对象，以使得目标测试对象执行第二测试指令。相较于输入adb命令，上述技术方案中基于测试框架来生成测试指令，使得测试指令的生成更加方便。对于需要不断执行的相同测试步骤(若一个测试步骤对应一个adb命令)，利用测试框架可以提高相关测试指令生成的效率，进而提高测试效率。基于第一测试框架和第二测试框架搭建的当前设备环境，为转换测试指令的适配编程语言提供了条件，使得将测试指令发送给目标测试对象更加顺利。

图2是根据一示例性实施例示出的一种应用程序的启动耗时测试方法的流程图，如图2所示，该方法包括下述步骤S201至S205。

在步骤S201中，基于第一测试框架和第二测试框架搭建当前设备环境。

这里可以参考前述实施例中步骤S101中的相关内容，不再赘述。

在步骤S202中，接收启动耗时测试请求，所述启动耗时测试请求包括目标应用程序的安装包信息。

启动耗时测试请求指示测试目标应用程序在终端设备上运行的启动耗时，其中被测试方为该应用程序。终端设备则作为目标测试对象，也就是后续测试指令的接收方。启动耗时测试请求的测试配置参数可以是目标应用程序的安装包信息，安装包信息的内容可以为具体的apkurl(安装包下载地址)。随着目标应用程序的更新，目标应用程序的安装包可以有至少两个版本，安装包信息的内容则可以包括每个版本具体的apkurl(安装包下载地址)以及对应的Ver(安装包版本)。还可以引入compareid(至少两个版本包对比标示)，后续目标测试对象在执行测试指令时可以快速确定是否存在至少两个版本的安装包，以及确定对应的执行逻辑，进而提高测试效率。

当然，考虑到启动耗时的测试准确性，需要多次启动目标应用程序来进行测试，启动耗时测试请求还可以包括具体的counts(启动循环次数)。启动耗时测试请求还可以包括目标测试对象的标识信息，以提高后续发送测试指令的准确性和效率。

在步骤S203中，在所述当前设备环境下，根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令，所述第一启动耗时测试指令使用所述第一测试框架支持的第一类编程语言描述。

如图6、7所示，启动耗时测试请求可以由测试人员通过前述实施例中步骤S101中提及的测试平台的交互界面生成，交互界面上列有测试配置参数选项，测试人员可根据实际需求进行填写。测试平台根据填写的测试配置参数生成适配第一测试框架的第一启动耗时测试指令。apkurl(安装包下载地址)、Ver(安装包版本)、compareid(至少两个版本包对比标示)和counts(启动循环次数)作为交互界面上列有测试配置参数选项，也就是定制命令参数，这些定制命令参数可以构成测试配置模板。测试人员填写定制命令参数的具体值，测试平台基于这些具体值和对应的定制命令参数进行拼接得到定制脚本命令：Python3-mpytest-m test_starttime--counts＝$counts--apkurl＝$apkurl--Ver＝$Ver--compareid＝$compareid。该定制脚本命令可以基于以下代码生成：

其中，第一行“defpytest_addoption(parser):”指示通过pytest_addoption方法(可以让用户注册一个自定义的命令行参数，方便用户将数据传递给Pytest)进行参数传递；后四行分别指示将自定义参数“--counts”添加到Pytest的相关配置项中，将自定义参数“--apkurl”添加到Pytest的相关配置项中，将自定义参数“--Ver”添加到Pytest的相关配置项中以及将自定义参数“--compareid”添加到Pytest的相关配置项中。

需要说明的是，当有至少两个安装包下载地址和对应的安装包版本需要填写时，可以使用英文逗号相隔以填写。比如，--apkurl＝$apkurl1,$apkurl2--Ver＝$Ver1,$Ver2。一般将靠前填写的安装包版本作为默认版本，其他安装包版本作为对比版本。

当然，测试配置参数选项也可以包括安装包配置文件，测试平台基于填写的安装包配置文件的具体值进行安装包打包。

在一个实施例中，当所述启动耗时测试请求还包括启动循环次数时，步骤S203可以包括步骤S2031，获取启动循环次数计数规则，所述启动循环次数计数规则指示不对冷启动计数；步骤S2032，根据所述启动循环次数和所述启动循环次数计数规则得到循环次数描述信息；以及步骤S2033，根据所述安装包信息和所述循环次数描述信息生成适配所述第一测试框架的第一启动耗时测试指令。

启动循环次数指示终端设备上安装某应用程序后循环启动该应用程序的次数。冷启动指示终端设备上安装某应用程序后的该应用程序的首次启动。冷启动时由于需要的文件不在内存中，需要将相关文件从存储空间读入内存，从存储空间中读取数据的耗时较长。因而冷启动耗时较长，对上述从存储空间中读取数据的耗时存在依赖。而该应用程序的非首次启动，由于冷启动的存在，相关文件已存于内存中，此时的启动耗时较短，也不再受上述从存储空间中读取数据的耗时的影响。启动循环次数计数规则指示不对冷启动计数，也就是说，需要将冷启动之后的一次应用程序启动作为第一次启动开始计数。忽略冷启动耗时，保证启动耗时测试环境的变量更一致、变量波动更小，进而得到更准确的启动耗时数据。

根据启动循环次数和启动循环次数计数规则得到循环次数描述信息。比如，启动循环次数为50，在包括冷启动的情况下，应用程序在终端设备上实际启动测试应该为51次，但第1次也就是冷启动那次的启动耗时不纳入统计。相应的，一方面，终端设备生成的启动耗时测试日志可以不将冷启动对应的日志数据纳入。一方面，测试方在从终端设备获取启动耗时测试日志时也可以将冷启动对应的日志数据排除。然后根据安装包信息和循环次数描述信息生成适配第一测试框架的第一启动耗时测试指令。这里“生成适配第一测试框架的第一启动耗时测试指令的内容”参考前述实施例中步骤S103中“生成适配第一测试框架的第一测试指令的内容”，不再赘述。

在另一个实施例中，当所述安装包信息指示至少两个版本时，步骤S203可以包括步骤S2031'，获取版本规则，所述版本规则指示不同版本的安装包按顺序依次启动；以及步骤S2032'，根据所述安装包信息和所述版本规则生成适配所述第一测试框架的第一启动耗时测试指令。

版本规则指示不同版本的安装包按顺序依次启动，也就是说，当安装包有至少两个版本：V1、V2时，终端设备需要先安装应用程序的安装包1(对应V1)然后启动完成启动耗时测试，终端设备需要再安装应用程序的安装包2(对应V2)然后启动完成启动耗时测试。基于版本规则，有序的启动可以保证测试执行的有序性。多个版本的执行流程是串行的，上一个版本执行完后下一个版本开始执行，保证基本运行环境一致。在得到版本规则的基础上，根据安装包信息和版本规则生成适配第一测试框架的第一启动耗时测试指令。这里“生成适配第一测试框架的第一启动耗时测试指令的内容”参考前述实施例中步骤S103中“生成适配第一测试框架的第一测试指令的内容”，不再赘述。

在实际应用中，如图7所示，当启动耗时测试请求还包括启动循环次数(比如50)且安装包信息指示至少两个版本(比如V1、V2)时，终端设备需要先安装应用程序的安装包1(对应V1)，然后在冷启动完成后循环启动50次完成启动耗时测试；终端设备需要再安装应用程序的安装包2(对应V2)，然后在冷启动完成后循环启动50次完成启动耗时测试。

在步骤S204中，当目标测试对象的运行环境支持第二类编程语言时，将所述第一启动耗时测试指令转化为第二启动耗时测试指令，所述第二启动耗时测试指令使用所述第二测试框架支持的所述第二类编程语言描述。

这里“将所述第一启动耗时测试指令转化为第二启动耗时测试指令的内容”参考前述实施例中步骤S104中“将所述第一测试指令转化为第二测试指令的内容”，不再赘述。

在步骤S205中，将所述第二启动耗时测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二启动耗时测试指令。

这里“将第二启动耗时测试指令发送至目标测试对象”参考前述实施例中步骤S105中“将第二测试指令发送至目标测试对象”，不再赘述。

如图7所示，在目标测试对象执行第二启动耗时测试指令的过程中，目标测试对象基于至少两个版本包对比标示确定当前执行多版本逻辑，也就是先完成默认版本的启动耗时测试，再完成对比版本的启动耗时测试。其中当有至少两个对比版本时，在一个对比版本的启动耗时测试完成之后再开始下一个对比版本的启动耗时测试。某一版本的启动耗时测试的过程可以参考下述内容：目标测试对象基于具体的安装包下载地址进行安装包下载、安装。当安装包信息包括注册用户的账号信息时，目标测试对象第一次启动当前版本对应的目标应用程序并基于该账号信息进行登录，否则完成第一次启动即可。目标测试对象基于具体的启动循环次数开始循环启动该目标应用程序，每次启动后将对应字段的日志数据存入启动耗时测试日志。这里的对应字段可以是基于实际需求预先设置的。每次启动后可以停留于首页，读取本次启动所产生相关的日志数据并且解析对应字段以保存。

在一个实施例中，如图4所示，所述将所述第二启动耗时测试指令发送至所述目标测试对象步骤之后，所述方法还包括步骤S206-S209：

在步骤S206中，从所述目标测试对象获取目标测试日志；

在步骤S207中，确定目标字段；

在步骤S208中，从所述目标测试日志中提取与所述目标字段相关联的日志数据；

在步骤S209中，根据所述相关联的日志数据得到启动耗时测试结果。

目标测试对象执行第二启动耗时测试指令的过程中会产生相关的日志数据。日志数据可以通过安装包信息实现定制化，日志数据可以以logcat日志的形式呈现，进而方便利用lagcat(一种命令行工具)进行字段查询。相应的，可以测试方从目标测试对象获取记录进程运行信息的第一类测试日志和记录页面加载信息的第二类测试日志。

第一类测试日志可以为MsgQueue(消息队列)日志，它记录与首页启动相关的所有业务逻辑，比如页面生命周期、开始节点与结束节点等等：

---------beginning of/dev/log/system

---------beginning of/dev/log/main

06-09 18:22:43.122W/AppPro(13102):>>>>>Dispatching to Handler(android.view.ViewRootImpl$ViewRootHandler){429a21d0}android.view.View$SendViewStateChangedAccessibilityEvent@43299ef0:0

06-09 18:22:43.123W/AppPro(13102):<<<<<Finished to Handler(android.view.ViewRootImpl$ViewRootHandler){429a21d0}android.view.View$SendViewStateChangedAccessibilityEvent@43299ef0

其中，“beginning of/dev/log/system”指示低等级***信息和debugging(调试以排除故障信息)的开始，“beginning of/dev/log/main”指示主应用程序日志的开始。“AppPro:>>>>>Dispatching to Handler”可以作为Msg(Windows程序中的结构体)开始的标识，“AppPro:<<<<<Finishedto Handler”Msg结束的标识，Finished(结束)减去Dispatching(开始)的时间间隔可以作为一个Msg的耗时，一个Msg的名字可以通过截取Dispatching to Handler后面的字符串来表示。

第二类测试日志可以包括两个维度的页面加载信息记录：LaunchEventV1(事件开启V1)日志，用于记录用户无感知的页面加载信息，可采用JSON(一种轻量级的数据交换格式)结构。基于LaunchEventV1可以解析出timeCost(总耗时)、frameworkCost(框架耗时)、launchHomeActivityCost(页面启动耗时)、fetchDataCost(拉Feed(信息流)耗时)、allVisibleCost(显示封面耗时)等内容；LaunchEventV2日志，用于记录用户有感知的页面加载信息，可采用JSON结构。基于LaunchEventV1可以解析出totalCost(总耗时)、pageWindowFocusChangedEnd(第一帧绘制完成时间)等内容。

可以利用第一类测试日志检测第二类测试日志中是否存在异常数据，因为第一类测试日志关注进程运行可以作为辅助排查第二类测试日志是否存在性能情况异常的数据，以确保第二类测试日志所记录的日志加载信息的准确性。相应的，当第二类测试日志中不存在异常数据时，将第二类测试日志作为所述目标测试日志。在实际应用中，常将从LaunchEventV2日志中解析出的内容作为核心字段，也可以利用第一类测试日志和LaunchEventV1日志作为对比参数对LaunchEventV2日志进行异常数据检测。

目标字段作为关键字段可以有效定位目标测试日志中与启动耗时测试结果相关性更强的日志数据。目标测试日志可以以logcat日志的形式呈现，测试方利用logcat可以进行目标字段查询以获取相关联的日志数据，进而根据相关联的日志数据得到启动耗时测试结果：

1)当所述启动耗时测试请求还包括启动循环次数时，步骤S209可以包括步骤S2091，根据所述相关联的日志数据确定每次启动所述目标应用程序所对应的启动耗时；步骤S2092，根据每次启动所述目标应用程序所对应的启动耗时，得到所述启动循环次数次启动所述目标应用程序的总启动耗时以及中位启动耗时；步骤S2093，根据所述总启动耗时和所述启动循环次数得到所述目标应用程序的平均启动耗时。

比如，目标应用程序的启动循环次数为4次，可以先根据相关联的日志数据确定每次启动目标应用程序所对应的启动耗时：第一次启动目标应用程序所对应的启动耗时为9秒、第二次启动目标应用程序所对应的启动耗时为8秒、第三次启动目标应用程序所对应的启动耗时为10秒、第四次启动目标应用程序所对应的启动耗时为12秒；然后根据每次启动目标应用程序所对应的启动耗时，得到启动循环次数次启动所述目标应用程序的总启动耗时：39(＝9+8+10+12)秒，以及中位启动耗时：

再者根据总启动耗时和启动循环次数得到目标应用程序的平均启动耗时：

2)当所述安装包信息指示至少两个版本时，步骤S209可以包括：根据所述相关联的日志数据确定每个版本的安装包所对应的目标应用程序启动耗时。也就是说，分别从相关联的日志数据中提取每个版本的安装包所对应的版本日志数据，再根据版本日志数据确定对应版本的目标应用程序的启动耗时。“根据版本日志数据确定对应版本的目标应用程序的启动耗时”，可以参考上述启动耗时测试请求还包括启动循环次数时，求得总启动耗时、中位启动耗时以及平均启动耗时的内容。不同版本的启动耗时统计，可以用于对比以排查不同版本间的问题。

在实际应用中，测试平台在生成启动耗时请求(由测试人员触发)后，可以自动开启测试指令生成、测试指令的适配编程语言转化、测试指令发送、测试日志获取以及耗时测试结果生成的过程。这样可以有效节省人力成本，在发版测试阶段测试人员仅需进行参数配置；可以节省时间、提升测试效率，对于某测试测试时间可以从之前的2天缩短到1小时内。得到的启动耗时测试结果可以保存于数据库中，后续测试平台可以通过读取数据库来呈现对应版本的应用程序的启动耗时均值报告和中位值报告。启动耗时均值报告和中位值报告不仅可以用于不同版本间的启动耗时验证、分析，也可以用于同版本不同分支间的启动耗时验证、分析，进而快速定位存在问题的分支。需要说明的是，计算得到启动耗时测试结果的过程可以依赖第一测试框架实现。

上述实施例中提供的应用程序的启动耗时测试方法，基于第一测试框架和第二测试框架搭建测试方所在的当前设备环境，根据启动耗时测试请求中的测试配置参数生成适配第一测试框架的第一启动耗时测试指令(第一类编程语言)，当目标测试对象(被测试方)的运行环境支持第二类编程语言时，将第一启动耗时测试指令转化为第二启动耗时测试指令(第二类编程语言)，进而将第二启动耗时测试指令发送至目标测试对象，以使得目标测试对象执行第二测试指令。相较于输入adb命令，上述技术方案中基于测试框架来生成启动耗时测试指令，使得启动耗时测试指令的生成更加方便。对于需要不断执行的相同测试步骤(若一个测试步骤对应一个adb命令)，利用测试框架和启动循环次数可以提高相关启动耗时测试指令生成的效率，进而提高测试效率。基于第一测试框架和第二测试框架搭建的当前设备环境，为转换启动耗时测试指令的适配编程语言提供了条件，使得将启动耗时测试指令发送给目标测试对象更加顺利。

图8是根据一示例性实施例示出的一种测试装置框图。参照图8，该装置包括第一环境搭建单元810、测试请求接收单元820、第一指令生成单元830、第二指令得到单元840和第二指令发送单元850。

该第一环境搭建单元810被配置为执行基于第一测试框架和第二测试框架搭建当前设备环境；

该测试请求接收单元820被配置为执行接收测试请求，所述测试请求包括测试配置参数；

该第一指令生成单元830被配置为执行在所述当前设备环境下，根据所述测试配置参数生成适配所述第一测试框架的第一测试指令，所述第一测试指令使用所述第一测试框架支持的第一类编程语言描述；

该第二指令得到单元840被配置为执行当目标测试对象的运行环境支持第二类编程语言时，将所述第一测试指令转化为第二测试指令，所述第二测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

该第二指令发送单元850被配置为执行将所述第二测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二测试指令。

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

图9是根据一示例性实施例示出的一种应用程序的启动耗时测试装置框图。参照图9，该装置包括第二环境搭建单元910、启动耗时测试请求接收单元920、第一启动耗时指令生成单元930、第二启动耗时指令得到单元940和第二启动耗时指令发送单元950。

该第二环境搭建单元910被配置为执行基于第一测试框架和第二测试框架搭建当前设备环境；

该启动耗时测试请求接收单元920被配置为执行接收启动耗时测试请求，所述启动耗时测试请求包括目标应用程序的安装包信息；

该第一启动耗时指令生成单元930被配置为执行在所述当前设备环境下，根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令，所述第一启动耗时测试指令使用所述第一测试框架支持的第一类编程语言描述；

该第二启动耗时指令得到单元940被配置为执行当目标测试对象的运行环境支持第二类编程语言时，将所述第一启动耗时测试指令转化为第二启动耗时测试指令，所述第二启动耗时测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

该第二启动耗时指令发送单元950被配置为执行将所述第二启动耗时测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二启动耗时测试指令。

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

在示例性实施例中，还提供了一种电子设备，包括处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行存储器上所存放的指令时，实现上述实施例中任一测试方法或者应用程序的启动耗时测试方法的步骤。

该电子设备可以终端、服务器或者类似的运算装置，以该电子设备是服务器为例，图10是根据一示例性实施例示出的一种用于测试或者应用程序的启动耗时测试的电子设备的框图，该电子设备100可以包括一个或多个(图中采用1002a、1002b，……，1002n来示出)处理器1002(处理器1002可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1004、以及用于通信功能的传输装置1006。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图10所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备100还可包括比图10中所示更多或者更少的组件，或者具有与图10所示不同的配置。

应当注意到的是上述一个或多个处理器1002和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到电子设备100(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器1004可用于存储应用软件的软件程序以及模块，如本发明实施例中所述的游戏数据处理方法对应的程序指令/数据存储装置，处理器1002通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种游戏数据处理方法。存储器1004可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实施例中，存储器1004可进一步包括相对于处理器1002远程设置的存储器，这些远程存储器可以通过网络连接至电子设备100。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置1006用于经由一个网络接收或者发送数据。上述的网络具体实例可包括电子设备100的通信供应商提供的无线网络。在一个实例中，传输装置1006包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实施例中，传输装置1006可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与电子设备100(或移动设备)的用户界面进行交互。

在示例性实施例中，还提供了一种存储介质，当存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述实施例中任一测试方法或者应用程序的启动耗时测试方法的步骤。

在示例性实施例中，还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行上述任一种实施方式中提供的测试方法或者应用程序的启动耗时测试方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

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

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

Claims (10)

1.一种测试方法，其特征在于，所述方法包括：

基于第一测试框架和第二测试框架搭建当前设备环境；

接收测试请求，所述测试请求包括测试配置参数；

在所述当前设备环境下，根据所述测试配置参数生成适配所述第一测试框架的第一测试指令，所述第一测试指令使用所述第一测试框架支持的第一类编程语言描述；

当目标测试对象的运行环境支持第二类编程语言时，将所述第一测试指令转化为第二测试指令，所述第二测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

将所述第二测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二测试指令。

2.根据权利要求1所述的方法，其特征在于，所述将所述第二测试指令发送至所述目标测试对象步骤，包括：

调用所述第二测试框架的预设功能建立与所述目标测试对象间的通信通道；

基于所述通信通道将所述第二测试指令发送给所述目标测试对象。

3.根据权利要求1所述的方法，其特征在于，所述根据所述测试配置参数生成适配所述第一测试框架的第一测试指令步骤，包括：

获取对应所述第一测试框架的测试配置模板；

拼接所述测试配置模板和所述测试配置参数，得到所述第一测试指令。

4.一种应用程序的启动耗时测试方法，其特征在于，所述方法包括：

基于第一测试框架和第二测试框架搭建当前设备环境；

接收启动耗时测试请求，所述启动耗时测试请求包括目标应用程序的安装包信息；

在所述当前设备环境下，根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令，所述第一启动耗时测试指令使用所述第一测试框架支持的第一类编程语言描述；

当目标测试对象的运行环境支持第二类编程语言时，将所述第一启动耗时测试指令转化为第二启动耗时测试指令，所述第二启动耗时测试指令使用所述第二测试框架支持的所述第二类编程语言描述；

将所述第二启动耗时测试指令发送至所述目标测试对象，以使得所述目标测试对象执行所述第二启动耗时测试指令。

5.根据权利要求4所述的方法，其特征在于，当所述启动耗时测试请求还包括启动循环次数时，所述根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令步骤，包括：

获取启动循环次数计数规则，所述启动循环次数计数规则指示不对冷启动计数；

根据所述启动循环次数和所述启动循环次数计数规则得到循环次数描述信息；

根据所述安装包信息和所述循环次数描述信息生成适配所述第一测试框架的第一启动耗时测试指令。

6.根据权利要求4所述的方法，其特征在于，当所述安装包信息指示至少两个版本时，所述根据所述安装包信息生成适配所述第一测试框架的第一启动耗时测试指令步骤，包括：

获取版本规则，所述版本规则指示不同版本的安装包按顺序依次启动；

根据所述安装包信息和所述版本规则生成适配所述第一测试框架的第一启动耗时测试指令。

7.根据权利要求4所述的方法，其特征在于，所述将所述第二启动耗时测试指令发送至所述目标测试对象步骤之后，所述方法还包括：

从所述目标测试对象获取目标测试日志；

确定目标字段；

从所述目标测试日志中提取与所述目标字段相关联的日志数据；

根据所述相关联的日志数据得到启动耗时测试结果。

8.根据权利要求7所述的方法，其特征在于，所述从所述目标测试对象获取目标测试日志步骤，包括：

从所述目标测试对象获取记录进程运行信息的第一类测试日志和记录页面加载信息的第二类测试日志；

利用所述第一类测试日志检测所述第二类测试日志中是否存在异常数据；

当所述第二类测试日志中不存在异常数据时，将所述第二类测试日志作为所述目标测试日志。

9.根据权利要求7所述的方法，其特征在于，当所述启动耗时测试请求还包括启动循环次数时，所述根据所述相关联的日志数据得到启动耗时测试结果步骤，包括：

根据所述相关联的日志数据确定每次启动所述目标应用程序所对应的启动耗时；

根据每次启动所述目标应用程序所对应的启动耗时，得到所述启动循环次数次启动所述目标应用程序的总启动耗时以及中位启动耗时；

根据所述总启动耗时和所述启动循环次数得到所述目标应用程序的平均启动耗时。

10.根据权利要求7所述的方法，其特征在于，当所述安装包信息指示至少两个版本时，所述根据所述相关联的日志数据得到启动耗时测试结果步骤，包括：

根据所述相关联的日志数据确定每个版本的安装包所对应的目标应用程序启动耗时。

Images