CN108984389B

CN108984389B - 一种应用程序测试方法及终端设备

Info

Publication number: CN108984389B
Application number: CN201810554464.5A
Authority: CN
Inventors: 张辉
Original assignee: Ping An Technology Shenzhen Co Ltd
Current assignee: Ping An Technology Shenzhen Co Ltd
Priority date: 2018-06-01
Filing date: 2018-06-01
Publication date: 2021-04-09
Anticipated expiration: 2038-06-01
Also published as: CN108984389A; WO2019227641A1

Abstract

本发明提供了一种应用程序测试方法及终端设备，适用于数据处理技术领域，该方法包括：获取构成测试用例对应的测试过程的各个测试节点，以及所调用的界面控件及调用顺序；从与待测试设备中的待测试应用程序关联的多个控件标识库中，筛选出与操作***类型对应的控件标识库，查找出每个界面控件的控件标识名；在依次运行各个测试节点的过程中，对构成测试节点的界面控件基于调用顺序依次调用，以完成测试用例对应的测试过程。本发明实施例中，即使是不同的操作***，也可以根据上述操作来确定出对应的待测试界面控件并进行相应的测试，从而实现了使用一个测试用例对不同操作***的终端设备进行相同应用程序功能的兼容测试。

Description

一种应用程序测试方法及终端设备

技术领域

本发明属于数据处理技术领域，尤其涉及应用程序测试方法及终端设备。

背景技术

研发人员在对应用程序的界面控件进行命名存储时，需要根据终端设备安装的操作***的实际研发要求/命名规则来对应用程序的界面控件进行命名，以得到每个界面控件的控件标识名，如IOS***中的某个应用程序，其登录控件的控件标识名可以设置为“Login控件”，即对于IOS***的该应用程序而言，“Login控件”对应的就是登录控件，后续在需要调用IOS***中该应用程序的登录控件时，只需要查找出控件标识名为“Login控件”的界面控件即可。

一个完整的应用程序测试包含着一个或多个测试节点，如应用程序的注册测试，可以包含注册节点以及登录节点，而在编写测试用例时，需要对测试中每一个测试节点所需调用的界面控件以及调用顺序进行设置，以使得在执行测试用例时能够准确为每个测试节点依次调用对应的界面控件，完成该测试节点的操作，如对登录节点时需要调用登录控件完成登录节点的操作，此时就需要在测试用例中设置好登录节点所需调用的界面控件为登录控件。现有技术中，为了保证每一个测试节点对界面控件的正确调用，会在测试用例中直接编写好测试节点所需的界面控件在操作***中的控件标识名，从而使得在应用程序测试时，直接读取控件标识名对应的界面控件即可。

由于不同的操作***的实际研发要求/命名规则不同，因此使得同一应用程序的界面控件在不同操作***中的控件标识名各不相同，如登录控件的控件标识名既可以为“Login控件”也可以为“登录控件”。而现有技术中都是利用自动化测试工具，针对应用程序所处的终端设备的操作***来编写对应的测试用例，即现有技术都是直接根据操作***，来为每个测试节点设置对应的待调用控件标识名以及对应的调用顺序，当需要对装有不同操作***的终端设备进行相同的应用程序测试时，由于不同的操作***中界面控件的控件标识名各不相同，因此只能针对每个终端设备分别编写对应的不同测试用例，以保证对该终端设备中应用程序功能的正常测试。因此，现有技术无法实现使用一个测试用例对不同操作***的终端设备进行相同应用程序功能的兼容测试。

发明内容

有鉴于此，本发明实施例提供了一种应用程序测试方法及终端设备，以解决现有技术中无法实现使用一个测试用例对不同操作***的终端设备进行相同应用程序功能的兼容测试的问题。

本发明实施例的第一方面提供了一种应用程序测试方法，包括：

解析测试用例，获取构成所述测试用例对应的测试过程的各个测试节点，以及获取每个所述测试节点在运行过程中所调用的界面控件及每个所述界面控件对应的调用顺序；

从与待测试设备中的待测试应用程序关联的多个控件标识库中，筛选出与所述待测试设备的操作***类型对应的所述控件标识库；

在筛选出的所述控件标识库中查找出每个所述界面控件的控件标识名；

基于查找出的每个所述界面控件的控件标识名，在依次运行各个所述测试节点的过程中，对构成所述测试节点的界面控件基于所述调用顺序依次调用，以完成所述测试用例对应的测试过程。

本发明实施例的第二方面提供了一种应用程序测试方法，包括：

从与待测试应用程序关联的多个控件标识库中，筛选出与在线的N个待测试设备的操作***类型分别对应的N个所述控件标识库，所述N个待测试设备中均安装有所述待测试应用程序，其中，N为大于1的正整数；

基于筛选出的N个所述控件标识库，查询出每个所述待测试设备中所述界面控件的控件标识名；

基于查找出的每个所述界面控件的控件标识名，在每个所述待测试设备依次运行各个所述测试节点的过程中，对构成所述测试节点的界面控件基于所述调用顺序依次调用，以完成每个所述待测试设备中所述测试用例对应的测试过程。

本发明实施例的第三方面提供了一种应用程序测试终端设备，所述应用程序测试终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下节点。

本发明实施例的第四方面提供了一种应用程序测试终端设备，所述应用程序测试终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下节点。

本发明实施例的第五方面提供了一种计算机可读存储介质，包括：存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上所述的应用程序测试方法的节点。

本发明实施例与现有技术相比存在的有益效果是：通过对终端设备进行操作***的识别，并根据操作***的不同查找出对应的控件标识库，以确定并对测试用例中待调用界面控件的控件标识名，再基于控件标识名来对已命名的界面控件进行查询调用，从而使得本发明实施例在测试用例中只需要设置所需调用的界面控件，而无需设置其在不同操作***中具体的控件标识名。因此，即使是不同的操作***，也可以根据上述操作来确定出对应的待测试界面控件，并进行相应的测试，从而实现了使用一个测试用例对不同操作***的终端设备进行相同应用程序功能的兼容测试。

附图说明

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

图1是本发明实施例一提供的应用程序测试方法的实现流程示意图；

图2是本发明实施例二提供的应用程序测试方法的实现流程示意图；

图3是本发明实施例三提供的应用程序测试方法的实现流程示意图；

图4是本发明实施例四提供的应用程序测试方法的实现流程示意图；

图5是本发明实施例五提供的应用程序测试方法的实现流程示意图；

图6是本发明实施例六提供的应用程序测试方法的实现流程示意图；

图7是本发明实施例七提供的应用程序测试装置的结构示意图；

图8是本发明实施例八提供的应用程序测试终端设备的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定***结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的***、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

为了说明本发明所述的技术方案，下面通过具体实施例来进行说明。

图1示出了本发明实施例一提供的应用程序测试方法的实现流程图，详述如下：

S101，解析测试用例，获取构成测试用例对应的测试过程的各个测试节点，以及获取每个测试节点在运行过程中所调用的界面控件及每个界面控件对应的调用顺序。

由于测试用例中可能包含对应用程序一个或多个功能的测试，每个功能的实现都需要一个或多个操作步骤，而在对应用程序的这些功能进行测试时，对应于每个操作步骤，测试过程中都需要包含着相应的测试节点进行测试，因此，每个测试过程都对应着功能实现所需的一个或多个测试节点。例如，一些应用程序的注册功能中包含注册和登陆两个步骤，因此在对注册功能进行测试时，测试过程至少包含对应的注册节点和登陆节点两个测试节点。同时，为了完成对每个操作步骤的测试，在测试节点时，都需要根据实际的操作步骤来依次调用对应的界面控件，如登陆节点时，需要依次调用信息输入控件、登陆控件以及验证控件。因此，为了保证对应用程序的正常有效测试，本发明实施例中，需要技术人员根据实际所需测试的应用程序的功能，设置好对应的测试节点，以及每个节点中所需调用的应用程序的界面控件，以及调用的顺序。

其中，应当特别说明地，为了保证测试用例对不同操作***的终端设备的兼容测试，本发明实施例的测试用例中，并未像现有技术中一样直接以控件标识名的方式记录每个测试节点所需调用的界面控件，而是直接对每个测试节点所需调用的界面控件进行了记录，从而使得后续针对不同操作***类型的终端设备进行测试时，可以根据记录的界面控件来进行对应控件标识名的界面控件的调用，以实现对不同操作***的终端设备的兼容测试。

实例说明如下：假设登陆节点需要调用登陆控件，在IOS***中登陆控件的控件标识名为“Login控件”，在安卓***中的控件标识名为“LOGIN控件”，现有技术在对测试用例中登陆节点编写对应的界面控件时，对于IOS***会记录为：调用“Login控件”，对于安卓***会记录为：调用“LOGIN控件”，以保证测试时对能根据记录的控件标识名直接调用对应的界面控件，保证测试的正常运行。而在本发明实施例中，在测试用例中仅会记录为：调用登陆控件，以使得后续步骤能根据终端设备的操作***类型来确定出对应的控件标识名，以进行后续的界面控件的调用和测试。

S102，从与待测试设备中的待测试应用程序关联的多个控件标识库中，筛选出与待测试设备的操作***类型对应的控件标识库。

S103，在筛选出的控件标识库中查找出每个界面控件的控件标识名。

由于应用程序的界面控件在不同的操作***中的控件标识名有所差异，因此，为了保证对每种不同的操作***中对界面控件的准确调用，本发明实施例中，会针对每种操作***设置一个对应的控件标识库，以记录该操作***中应用程序每个界面控件的控件标识名，如假设对于IOS***，登陆控件的控件标识名为“Login控件”，此时，本发明实施例会在IOS***的控件标识库中，记录好登陆控件的控件标识名为“Login控件”。在得到每种操作***分别对应的控件标识库后，即可得到与待测试的应用程序相关联的多个控件标识库。其中，操作***类型包括但不限于IOS***以及安卓***等。

由于每个操作***对应的控件标识库中，已经记录好了应用程序每个界面控件的控件标识名，因此在确定出终端设备的操作***对应的控件标识库之后，只需要直接根据控件标识库来查找界面控件的控件标识名即可，如上述的实例中，当确定出IOS***对应的控件标识库后，如确定出需要调用登陆控件，此时只需要在IOS***对应的控件标识库中，查找出登陆控件对应的控件标识名“Login控件”即可。

S104，基于查找出的每个界面控件的控件标识名，在依次运行各个测试节点的过程中，对构成测试节点的界面控件基于调用顺序依次调用，以完成测试用例对应的测试过程。

其中，由于在操作***中，每个界面控件的命名已经预先设定好，因此在确定出所需调用的界面控件的控件标识名之后，根据控件标识名即可实现对实际所需的界面控件的调用，如假设在IOS***中登陆控件的控件标识名为“Login控件”，即说明在IOS***中的待测试的应用程序中，名称为“Login控件”的界面控件即为登陆控件，此时若需要调用登陆控件，只需要查找出名称为“Login控件”的界面控件即可。

在确定出每个界面控件在终端设备的操作***中对应的控件标识名之后，开始对终端设备中的待测试的应用程序进行测试。此时，只需要根据测试用例中的测试过程依次进行测试即可，若需要调用界面控件，只需要根据确定出来的控件标识名进行调用即可。

以一实例进行说明，如当需要测试应用程序的注册功能，假设注册功能包括注册节点以及登陆节点两个测试节点，其中登录节点需要依次调用信息输入控件、登陆控件以及验证控件，同时假设在IOS***对应的应用程序的控件标识库中，信息输入控件、登陆控件以及验证控件的控件标识名分别为“Information input控件”、“Login控件”以及“Validate控件”，且终端设备的操作***即为IOS***。

在进行应用程序注册功能测试时，依次进行注册节点和登陆节点的测试，判断是否正常，且在进行登陆节点时，首先需要根据IOS***的控件标识库，确定出所需调用的信息输入控件、登陆控件以及验证控件的控件标识名分别为“Information input控件”、“Login控件”以及“Validate控件”，再从应用程序的界面控件中，依次查找出名称为“Information input控件”、“Login控件”以及“Validate控件”的界面控件进行调用，从而完成了对注册节点以及登陆节点的测试，以完成对应用程序注册功能的测试。

在本发明实施例中，通过对终端设备进行操作***的识别，并根据操作***的不同查找出对应的控件标识库，以确定并对测试用例中待调用界面控件的控件标识名，再基于控件标识名来对已命名的界面控件进行查询调用，从而使得本发明实施例在测试用例中只需要设置所需调用的界面控件，而无需设置其在不同操作***中具体的控件标识名。因此，即使是不同的操作***，也可以根据上述操作来确定出对应的待测试界面控件，并进行相应的测试，从而实现了使用一个测试用例对不同操作***的终端设备进行相同应用程序功能的兼容测试。

作为本发明实施例二，如图2所示，在对测试用例进行解析时，包括：

S1011，识别测试用例的格式类型，格式类型包括Excel格式、YAML格式以及脚本格式。

S1012，基于预设的格式类型对应的解析工具对测试用例进行解析，确定出构成测试用例对应的测试过程的各个测试节点，以及获取每个测试节点在运行过程中所调用的界面控件及每个界面控件对应的调用顺序。

由于实际应用中负责编写测试用例的用户的***等各不相同，而不同格式的测试用例的编写难度和运行速度之间也存在差异，如编写难度YAML格式>Excel格式>脚本格式，且一般编写难度越大，运行速度越高，测试效率也越高，因此为了满足不同用户的实际需求，本发明实施例增加了对各种不同格式的测试用例的同步支持功能，用户只需根据自己的需求选取对应格式的测试用例进行编写即可。其中，由于对不同格式的测试脚本的解析属于现有技术，因此，在进行解析工具预设时，只需要选取一些对应的现有的解析工具即可，此处不予赘述限定。

作为本发明实施例三，如图3所示，考虑到实际情况中，对测试用例的编写往往具有较高的技术门槛，普通用户可能难以实现，因此为了降低对用户测试用例编写的难度，使得不同用户均可根据自己实际需求进行应用程序的测试，本发明实施例中，在解析测试用例之前，还包括：

S301，获取测试用例录制指令，并确定出待测试应用程序包含的界面控件。

在本发明实施例中，测试用例录制指令用于触发移动终端对脚本的录制开始，录制停止指令用于终止移动终端对测试用例的录制，通过测试用例录制指令以及录制停止指令，可以实现对测试用例录制始终的控制，以生成对应所需的测试用例。其中，测试用例录制指令以及录制停止指令，既可以由用户手动输入的，也可以是由其他预设的触发条件生成，如设置定时机制，定时自动生成测试用例录制指令以及录制停止指令以完成对测试用例的录制。

移动终端开始进行测试用例录制的模式，此时首先会确定出应用程序中所包含的所有界面控件，如在使用Uiautomator作为测试工具时，可以根据元素的text、hint、contentDescription等属性，利用findObject()方法来查找到应用程序包含的界面控件。

S302，记录待测试应用程序在对用户输入的操作指令响应过程中，界面控件对应的响应数据。

其中，界面控件对应响应数据是指界面控件对用户操作行为进行响应时产生的数据，以及对应的用户操作行为的时间，如用户视频播放应用程序在视频播放时进行了1.5倍的快进操作，此时快进按钮控件会响应执行1.5倍的快进操作，此时快进按钮控件对应的响应数据就是1.5倍的快进倍率以及用户快进操作时的时间。

用户在对应用程序进行操作时，界面控件会对用户的操作行为进行响应，从而实现应用程序的各个功能对用户操作的响应，如视频播放应用程序中用户若在录制时点击了播放/暂停按钮，对应的播放/暂停按钮控件执行播放/暂停功能任务，因此，此时对界面控件的响应数据进行记录，即可知道在用户的操作过程中应用程序都在何时执行了一些什么功能，以便后续对用户操作的准确回放。

S303，获取录制停止指令，并基于记录的界面控件对应的响应数据进行分析，生成测试用例。

在用户完成对应用程序的操作行为后，在测试工具中输入相应的录制停止指令，或者由满足触发条件时，自动生成录制停止指令，即可停止对用户操作行为的录制，并会将录制得到的界面控件的响应数据进行处理，得到相应的测试用例，以为后续应用程序测试作为基础。如用户录制期间完成对视频播放应用程序的播放/暂停/快进/停止功能操作后，得到了对应界面控件的响应数据之后，根据这些响应数据生成测试用例，以记录用户对应用程序的操作。

作为本发明实施例四，如图4所示，为了后续对控件标识库的准确选择，需要在解析测试用例之前，识别待测试设备的操作***，具体包括：

S401，建立与待测试设备的通信，并基于adb工具以及instruments工具，分别获取待测试设备的物理地址。

S402，若adb工具成功获取到物理地址，则判定待测试设备的操作***类型为安卓***。

S403，若instruments工具成功获取到物理地址，则判定待测试设备的操作***类型为IOS***。

在连接好终端设备之后，为了识别出终端设备的操作***类型，本发明实施例会利用adb工具以及instruments工具来分别尝试获取终端设备的物理地址，由于adb工具仅能与安卓***正常进行通信并实现物理地址的获取，因此当adb工具成功获取到物理地址，则说明该测连接的终端设备是安卓***的设备。反之，若instruments工具成功获取到物理地址，则说明该测连接的终端设备是IOS***的设备。其中，由于adb工具和instruments工具，均是现有的测试工具，因此，关于两个工具的相关说明，此处不予赘述，感兴趣的读者可自行查阅相关资料。

作为本发明实施例五，如图5所示，考虑到单台终端设备的测试偶然性较大，及时得到了测试异常的结果，也一定就是待测试的应用程序本身的问题，也有可能是待测试的终端设备或者其他环境因素的影响，因此，为了提升对测试的有效性，保证得到的测试结果的准确有效，本发明实施例中，在完成测试用例对应的测试过程之后，还包括：

S501，对测试得到的测试数据进行分析，判断待测试应用程序的测试结果是否存在异常。

其中，存在异常的具体标准可由技术人员自行设定，包括但不限于如，对测试得到的测试数据中的每个参数，都预先设置一个正常数据范围，并在测试完成后，对测试得到的测试数据中的每个参数分别进行校验，判断是否处于正常数据范围，若存在不处于的，则判定结测试结果为存在异常。

S502，若判断结果为待测试应用程序的测试结果存在异常，从在线的待测试设备组中筛选出与待测试设备的操作***版本相同的多个待测试设备。

S503，基于测试用例，对多个待测试设备进行测试。

由于操作***版本相同，说明应用程序运行的软件环境是相同的，如都是安卓7.0版本的终端设备，因此，为了排除单台终端设备的偶然因素导致的测试异常，本发明实施例会对所有操作***版本相同的终端设备，再次进行相同的测试，以验证最终的测试结果如何，为应用程序测试的准确有效提供保障。

作为本发明的一个优选实施例，在完成对应用程序的测试后，还包括：根据用户设定的待测试指标，对得到的测试数据进行分析，得到每个待测试指标对应的指标测试结果。

由于不同的用户测试的需求存在差异，如有些是想看看应用程序的某个功能是否正常，有些是想看看应用程序在运行过程中，对终端设备的性能占用情况如何。因此，为了满足用户的实际需求，本发明实施例中，用户可以自行设置所需测试分析的指标，如功能稳定性、内存占有率以及耗电速度等指标。在完成对应用程序的测试后，本发明实施例会根据得到的测试数据，对用户设置所需分析的指标进行分析，以得到对应的指标测试结果，如应用程序运行过程中对内存的占有率，此时可以对测试过程中，应用程序对终端设备内存的占有率进行记录，并整理生成内存占有率性能曲线等。

图6示出了本发明实施例六提供的应用程序测试方法的实现流程图，由于本发明实施例一中针对的都是单台终端设备的测试，实现了无论单台终端设备安装的是何种操作***，均可实现对其的应用程序功能的兼容想测试，但考虑到实际情况中，为了提高对终端设备测试的效率，经常会批量对终端设备进行，因此，此时为了满足一次性对多台操作***可能不同的终端设备的兼容性测试，本发明实施例提出了一种可以对多台终端设备同时进行测试的技术方案，详述如下：

S601，解析测试用例，获取构成测试用例对应的测试过程的各个测试节点，以及获取每个测试节点在运行过程中所调用的界面控件及每个界面控件对应的调用顺序。

S602，从与待测试应用程序关联的多个控件标识库中，筛选出与在线的N个待测试设备的操作***类型分别对应的N个控件标识库，N个待测试设备中均安装有待测试应用程序，其中，N为大于1的正整数。

S603，基于筛选出的N个控件标识库，查询出每个待测试设备中界面控件的控件标识名。

S604，基于查找出的每个界面控件的控件标识名，在每个待测试设备依次运行各个测试节点的过程中，对构成测试节点的界面控件基于调用顺序依次调用，以完成每个待测试设备中测试用例对应的测试过程。

在本发明实施例中，针对每台终端设备的测试方法与本发明实施例一中相同，因此，此处不予赘述，与本发明实施例不同之处在于，本发明实施例六会同时对在线的每台终端设备，分别基于操作***进行控件标识库的筛选以及控件标识名的查找，并会根据查找结果，分别对每台终端设备分别进行测试节点的界面控件的调用测试，以完成同时对多台操作***可能不同的终端设备的兼容测试，极大地满足用户的实际需求。

应当说明地，在本发明实施例六的基础上，上述本发明实施例二至本发明

实施例四，同样可以适用于多台操作***可能不同的终端设备的测试，具体可参考上述本发明实施例的相关说明，此处不予赘述。

对应于上文实施例的方法，图7示出了本发明实施例提供的应用程序测试装置的结构框图，为了便于说明，仅示出了与本发明实施例相关的部分。图7示例的应用程序测试装置可以是前述实施例一提供的应用程序测试方法的执行主体。

参照图7，该应用程序测试装置包括：

用例解析模块71，用于解析测试用例，获取构成所述测试用例对应的测试过程的各个测试节点，以及获取每个所述测试节点在运行过程中所调用的界面控件及每个所述界面控件对应的调用顺序。

标识库筛选模块72，用于从与待测试设备中的待测试应用程序关联的多个控件标识库中，筛选出与所述待测试设备的操作***类型对应的所述控件标识库。

标识名查询模块73，用于在筛选出的所述控件标识库中查找出每个所述界面控件的控件标识名。

测试模块74，用于基于查找出的每个所述界面控件的控件标识名，在依次运行各个所述测试节点的过程中，对构成所述测试节点的界面控件基于所述调用顺序依次调用，以完成所述测试用例对应的测试过程。

进一步地，用例解析模块71，包括：

格式识别模块，用于识别所述测试用例的格式类型，所述格式类型包括Excel格式、YAML格式以及脚本格式。

格式用例解析模块，用于基于预设的所述格式类型对应的解析工具对所述测试用例进行解析，确定出构成所述测试用例对应的测试过程的各个所述测试节点，以及获取每个所述测试节点在运行过程中所调用的界面控件及每个所述界面控件对应的所述调用顺序。

进一步地，该应用程序测试装置，还包括：

获取测试用例录制指令，并确定出所述待测试应用程序包含的界面控件。

记录所述待测试应用程序在对用户输入的操作指令响应过程中，所述界面控件对应的响应数据。

获取录制停止指令，并基于记录的所述界面控件对应的响应数据进行分析，生成所述测试用例。

进一步地，该应用程序测试装置，还包括：

建立与所述待测试设备的通信，并基于adb工具以及instruments工具，分别获取所述待测试设备的物理地址。

若所述adb工具成功获取到所述物理地址，则判定所述待测试设备的所述操作***类型为安卓***。

若所述instruments工具成功获取到所述物理地址，则判定所述待测试设备的所述操作***类型为IOS***。

进一步地，该应用程序测试装置，还包括：

对测试得到的测试数据进行分析，判断所述待测试应用程序的测试结果是否存在异常。

若判断结果为所述待测试应用程序的所述测试结果存在异常，从在线的待测试设备组中筛选出与所述待测试设备的操作***版本相同的多个待测试设备。

基于所述测试用例，对所述多个待测试设备进行测试。

本发明实施例提供的应用程序测试装置中各模块实现各自功能的过程，具体可参考前述图1所示实施例一的描述，此处不再赘述。

应理解，上述实施例中各节点的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本发明实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一接触可以被命名为第二接触，并且类似地，第二接触可以被命名为第一接触，而不背离各种所描述的实施例的范围。第一接触和第二接触都是接触，但是它们不是同一接触。

图8是本发明一实施例提供的应用程序测试终端设备的示意图。如图8所示，该实施例的应用程序测试终端设备8包括：处理器80、存储器81，所述存储器81中存储有可在所述处理器80上运行的计算机程序82。所述处理器80执行所述计算机程序82时实现上述各个应用程序测试方法实施例中的节点，例如图1所示的节点101至104。或者，所述处理器80执行所述计算机程序82时实现上述各装置实施例中各模块/单元的功能，例如图7所示模块71至74的功能。

所述应用程序测试终端设备8可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述应用程序测试终端设备可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是应用程序测试终端设备8的示例，并不构成对应用程序测试终端设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述应用程序测试终端设备还可以包括输入发送设备、网络接入设备、总线等。

所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器81可以是所述应用程序测试终端设备8的内部存储单元，例如应用程序测试终端设备8的硬盘或内存。所述存储器81也可以是所述应用程序测试终端设备8的外部存储设备，例如所述应用程序测试终端设备8上配备的插接式硬盘，智能存储卡(SmartMedia Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器81还可以既包括所述应用程序测试终端设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储所述计算机程序以及所述应用程序测试终端设备所需的其他程序和数据。所述存储器81还可以用于暂时地存储已经发送或者将要发送的数据。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的节点。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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

Claims

1.一种应用程序测试方法，其特征在于，包括：

2.如权利要求1所述的应用程序测试方法，其特征在于，所述解析测试用例，获取构成所述测试用例对应的测试过程的各个测试节点，以及获取每个所述测试节点在运行过程中所调用的界面控件及每个所述界面控件对应的调用顺序，包括：

识别所述测试用例的格式类型，所述格式类型包括Excel格式、YAML格式以及脚本格式；

基于预设的所述格式类型对应的解析工具对所述测试用例进行解析，确定出构成所述测试用例对应的测试过程的各个所述测试节点，以及获取每个所述测试节点在运行过程中所调用的界面控件及每个所述界面控件对应的所述调用顺序。

3.如权利要求1或2所述的应用程序测试方法，其特征在于，在所述解析测试用例之前，还包括：

获取测试用例录制指令，并确定出所述待测试应用程序包含的界面控件；

记录所述待测试应用程序在对用户输入的操作指令响应过程中，所述界面控件对应的响应数据；

4.如权利要求1所述的应用程序测试方法，其特征在于，在所述从与待测试设备中的待测试应用程序关联的多个控件标识库中，筛选出与所述待测试设备的操作***类型对应的所述控件标识库之前，还包括：

建立与所述待测试设备的通信，并基于adb工具以及instruments工具，分别获取所述待测试设备的物理地址；

若所述adb工具成功获取到所述物理地址，则判定所述待测试设备的所述操作***类型为安卓***；

5.如权利要求1所述的应用程序测试方法，其特征在于，在所述完成所述测试用例对应的测试过程之后，还包括：

对测试得到的测试数据进行分析，判断所述待测试应用程序的测试结果是否存在异常；

若判断结果为所述待测试应用程序的所述测试结果存在异常，从在线的待测试设备组中筛选出与所述待测试设备的操作***版本相同的多个待测试设备；

基于所述测试用例，对所述多个待测试设备进行测试。

6.一种应用程序测试方法，其特征在于，包括：

7.一种应用程序测试终端设备，其特征在于，所述应用程序测试处理终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下节点：

8.如权利要求7所述应用程序测试终端设备，其特征在于，在所述完成所述测试用例对应的测试过程之后，还包括：

基于所述测试用例，对所述多个待测试设备进行测试。

9.一种应用程序测试终端设备，其特征在于，所述应用程序测试处理终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下节点：

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述方法的节点。