CN111444109B - 一种移动端ui自动化测试方法及系统 - Google Patents

Abstract

本发明提供了一种移动端UI自动化测试系统，所述系统包括后台管理模块、任务调度模块、以及终端执行模块；所述台管理模块负责数据上的管理，所述任务调度模块将数据打包为可执行的任务下发给终端，所述终端执行模块将执行的结果进行反馈操作；所述系统通过后台管理模块来实现UI自动化测试任务的创建、及脚本的配置；再通过任务调度模块配置任务的执行参数，并下发到终端进行具体的执行；最后由终端执行模块执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给后台管理模块；本发明可以同时执行多台设备进行自动化测试，有效的提高的自动化测试的效率。

Description

一种移动端UI自动化测试方法及系统

技术领域

本发明涉及软件测试技术领域，特别是一种移动端UI自动化测试方法及系统。

背景技术

软件开发过程中，软件测试是不可或缺的一个环节，随着移动智能设备的普及，在移动设备方面的测试质量要求尤为重要。开发及测试都需要通过工具去辅助软件测试，从而提升软件质量。其中UI(用户界面)自动化作为模拟用户界面行为的操作，起到举足轻重的地位。目前测试的执行脚本框架有很多种，比如：appium脚本框架、calabash脚本框架、IOS UIAutomation脚本框架、robotium脚本框架等。每个框架都有着各自的编写规范及环境，都需要编写对应的脚本，但是针对不同的设备，脚本可能存在着各种适配问题，同时很多软件测试场景不支持多台设备同时执行一份的自动化脚本，在自动化测试实施的时候会存在较多问题。而现有的软件测试存在如下缺点：

缺点一，目前的移动端UI自动化大多是需要通过测试员根据对应框架的编写规范来编写对应脚本，对测试员的技能有一定的要求，需要测试员具备一定的语言编码能力。随着对应框架的升级，测试员还需要针对历史脚本进行针对性维护，如果涉及脚本量级多的话，维护成本会随之提升。

缺点二，目前的移动端UI自动化大多是通过编写对应的脚本，再通过对应的框架进行自动化执行。在单台设备执行UI自动化的时候一般不会有问题，针对多部设备同时执行一个脚本的时候，存在很多场景是无法执行的。比如：有互踢机制的登陆应用，多台设备同时执行UI自动化，后进行登陆执行的设备将会把前者的账号踢下去，这样就导致UI自动化的异常中断。

缺点三，目前的移动端UI自动化生成的结果会以test case(测试用例)为单位来生成对应的测试报告，并告知哪些测试通过，哪些测试不通过。但是对应测试结果的分析来说，只是知道某一个步骤出现异常，并不能快速排查到UI自动化过程中出现的问题。

缺点四，目前手机设备琳琅满目，以安卓为例，目前市面上的机型很多，为保证软件能够在更多的设备上正常运行，手机适配环节必不可少。目前手机适配多以人工手机适配为主，但是受制于资金等各种因素，一个测试员手上可以持有的设备往往是有限制的，另一方面人工的方式来进行适配覆盖成本投入会比较大。

发明内容

为克服上述问题，本发明的目的是提供一种移动端UI自动化测试系统，可以同时执行多台设备进行自动化测试，有效的提高的自动化测试的效率。

本发明采用以下方案实现：一种移动端UI自动化测试系统，所述系统包括后台管理模块、任务调度模块、以及终端执行模块；所述后台管理模块负责数据上的管理，所述任务调度模块将数据打包为可执行的任务下发给终端，所述终端执行模块将执行的结果进行反馈操作；

所述系统通过后台管理模块来实现UI自动化测试任务的创建、及脚本的配置；再通过任务调度模块配置任务的执行参数，并下发到终端进行具体的执行；最后由终端执行模块执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给后台管理模块。

进一步的，所述后台管理模块进一步具体为：后台管理模块提供一用户操作管理的界面，通过界面创建对应的测试任务，创建一个测试任务后，后台管理模块会默认生成一个任务ID，并以此选择操作平台和操作平台对应的测试框架；再进行脚本的配置，界面提供自定义脚本操作或者非自定义脚本操作，自定义脚本操作即用户自定义测试用例的脚本，用户按照对应测试框架提供的模板接入编写测试用例的脚本并上传脚本即完成任务的创建；非自定义脚本操作即提供一脚本配置页面，通过脚本配置页面将测试数据导入，并进行新增用例，每个用例都会生成唯一值用例ID，并配置用例执行的具体行为，每个行为都会生成唯一值行为ID，该行为配置分为两类，一类是通用行为配置，通用行为包含但不局限于：保存截图、等待时间、上下左右滑动；另外一类是基于控件的行为配置。

进一步的，所述任务调度模块进一步具体为：任务配置后，针对任务发起执行，上传对应需要测试的测试包；则任务调度模块提供一个restful api，通过输入对应的任务ID即task_id和测试包下载链接，即能通过restful api发起对应测试；

上传完安装包之后系统会列出当前能使用的移动端设备列表，供用户进行挑选；

当选中需要测试的移动端设备，点击开始执行后，任务调度模块就会创建一条执行记录，并生成唯一值标识记录record_id，并将该记录record_id下发给终端进行执行；同时，任务调度所上传的测试包、所选择的测试的移动端设备及对应的task_id都会被存入数据库中。

进一步的，所述终端执行模块进一步具体为：终端执行模块负责监听接收服务端下发的请求，判断是否有命令下发；

接到服务端下发的记录record_id，终端会发起一次请求查阅该记录record_id上所配置的信息，解析出当前终端执行所需要的相关参数，所述相关参数包括：测试的移动端设备列表、对应的测试框架、对应的task_id；

通过解析出来的移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本；

框架脚本通过task_id查询该task_id下的所有配置信息，包括初始化的数据及需要执行的用例、行为；

终端会遍历执行每一个用例及每个用例下的action行为；

执行的过程中会记录当前的执行进度，在脚本全部执行完成的时候，会将当前的测试结果反馈给服务器，并通知对应的测试人员，能查阅对应的测试报告；

在后台管理模块上能查阅该任务的测试结果；当某个用例执行错误的时候，能具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。

进一步的，所述测试结果的信息包括用例通过率、每个用例的行为通过概率、稳定性错误记录、行为执行错误日志、以及截图信息。

本发明还提供了一种移动端UI自动化测试方法，所述方法包括如下步骤：

步骤S1、首先实现移动端UI自动化测试任务的创建、及脚本的配置；

步骤S2、配置任务的执行参数，并下发到终端进行具体的执行；

步骤S3、终端执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给服务器。

进一步的，所述步骤S1进一步具体为：提供一用户操作管理的界面，通过界面创建对应的测试任务，创建一个测试任务后，默认生成一个任务ID，并以此选择操作平台和操作平台对应的测试框架；再进行脚本的配置，界面提供自定义脚本操作或者非自定义脚本操作，自定义脚本操作即用户自定义测试用例的脚本，用户按照对应测试框架提供的模板接入编写测试用例的脚本并上传脚本即完成任务的创建；非自定义脚本操作即提供一脚本配置页面，通过脚本配置页面将测试数据导入，并进行新增用例，每个用例都会生成唯一值用例ID，并配置用例执行的具体行为，每个行为都会生成唯一值行为ID，该行为配置分为两类，一类是通用行为配置，通用行为包含但不局限于：保存截图、等待时间、上下左右滑动；另外一类是基于控件的行为配置。

进一步的，所述步骤S2进一步具体为：步骤S21、任务配置后，针对任务发起执行，上传对应需要测试的测试包；同时提供一个restful api，通过输入对应的任务ID即task_id和测试包下载链接，即能通过restful api发起对应测试；

步骤S22、上传完安装包之后系统会列出当前能使用的移动端设备列表，供用户进行挑选；

步骤S23、当选中需要测试的移动端设备，点击开始执行后，会创建一条执行记录，并生成唯一值标识记录record_id，并将该记录record_id下发给终端进行执行；同时，任务调度所上传的测试包、所选择的测试的移动端设备及对应的task_id都会被存入数据库中。

进一步的，所述步骤S3进一步具体为：步骤S31、终端负责监听接收服务端下发的请求，判断是否有命令下发；

步骤S32、接到服务端下发的记录record_id，终端会发起一次请求查阅该记录record_id上所配置的信息，解析出当前终端执行所需要的相关参数，所述相关参数包括：测试的移动端设备列表、对应的测试框架、对应的task_id；

步骤S33、通过解析出来的移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本；

步骤S34、框架脚本通过task_id查询该task_id下的所有配置信息，包括初始化的数据及需要执行的用例、行为；

步骤S35、终端会遍历执行每一个用例及每个用例下的action行为；

步骤S36、执行的过程中会记录当前的执行进度，在脚本全部执行完成的时候，会将当前的测试结果反馈给服务器，并通知对应的测试人员，能查阅对应的测试报告；能查阅该任务的测试结果；当某个用例执行错误的时候，能具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。

进一步的，所述测试结果的信息包括用例通过率、每个用例的行为通过概率、稳定性错误记录、行为执行错误日志、以及截图信息。

本发明的有益效果在于：

1、通过本发明提供的方式进行自动化测试，可以单独写一份脚本，即可完成多台设备的自动化测试。

2、通过本发明提供的方式进行配置操作，可以无需自动化脚本编写经验，即可完成自动化测试任务的实施。

3、通过本发明提供的方式进行自动化测试，可以获得一份清晰明了的测试报告，可以方便工程师对自动化测试过程中的问题分析。

4、通过本发明提供的方式进行自动化测试，可以同时执行多台设备进行自动化测试，有效的提高的自动化测试的效率。

5、通过本发明提供的方式进行自动化测试，可以避免不同设备之间由于账号等问题导致的冲突。

6、通过本发明提供的方式进行自动化测试，直接使用配置的方式可以降低由于框架升级导致的脚本复工，降低脚本编写的投入。

7、通过本发明提供的方式进行自动化测试，可以实现版本发布迭代的自动化运维构建，自动化发起测试。

附图说明

图1是本发明的系统框架原理图。

图2是本发明后台管理模块中任务创建的原理图。

图3是本发明后台管理模块中脚本配置的原理图。

图4是本发明任务调度模块的操作原理图。

图5是本发明终端执行模块的操作原理图。

图6是本发明的方法流程示意图。

具体实施方式

下面结合附图对本发明做进一步说明。

请参阅图1所示，本发明的一种移动端UI自动化测试系统，所述系统包括后台管理模块、任务调度模块、以及终端执行模块；所述后台管理模块负责数据上的管理，所述任务调度模块配置任务的执行参数，并下发给终端，所述终端执行模块将执行的结果进行反馈操作；

所述系统通过后台管理模块来实现UI自动化测试任务的创建、及脚本的配置；再通过任务调度模块配置任务的执行参数，并下发到终端进行具体的执行；最后由终端执行模块执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给后台管理模块。

其中，如图2和图3所示，所述后台管理模块进一步具体为：后台管理模块提供一用户操作管理的界面，通过界面创建对应的测试任务，创建一个测试任务后，后台管理模块会默认生成一个任务ID，并以此选择操作平台和操作平台对应的测试框架；再进行脚本的配置，界面提供自定义脚本操作或者非自定义脚本操作，自定义脚本操作即用户自定义测试用例的脚本，用户按照对应测试框架提供的模板接入编写测试用例的脚本并上传脚本即完成任务的创建；非自定义脚本操作即提供一脚本配置页面，通过脚本配置页面将测试数据导入，并进行新增用例，每个用例都会生成唯一值用例ID，并配置用例执行的具体行为，每个行为都会生成唯一值行为ID，该行为配置分为两类，一类是通用行为配置，通用行为包含但不局限于：保存截图、等待时间、上下左右滑动；另外一类是基于控件的行为配置。

如图4所示，所述任务调度模块进一步具体为：任务配置后，针对任务发起执行，上传对应需要测试的测试包；则任务调度模块提供一个restful api，通过输入对应的任务ID即task_id和测试包下载链接，即能通过restful api发起对应测试；

上传完安装包之后系统会列出当前能使用的移动端设备列表，供用户进行挑选；

当选中需要测试的移动端设备，点击开始执行后，任务调度模块就会创建一条执行记录，并生成唯一值标识记录record_id，并将该记录record_id下发给终端进行执行；同时，任务调度所上传的测试包、所选择的测试的移动端设备及对应的task_id都会被存入数据库中。

如图5所示，所述终端执行模块进一步具体为：终端执行模块负责监听接收服务端下发的请求，判断是否有命令下发；

接到服务端下发的记录record_id，终端会发起一次请求查阅该记录record_id上所配置的信息，解析出当前终端执行所需要的相关参数，所述相关参数包括：测试的移动端设备列表、对应的测试框架、对应的task_id；

通过解析出来的移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本；

框架脚本通过task_id查询该task_id下的所有配置信息，包括初始化的数据及需要执行的用例、行为；

终端会遍历执行每一个用例及每个用例下的action行为；

执行的过程中会记录当前的执行进度，在脚本全部执行完成的时候，会将当前的测试结果反馈给服务器，并通知对应的测试人员，能查阅对应的测试报告；

在后台管理模块上能查阅该任务的测试结果；当某个用例执行错误的时候，能具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。其中，所述测试结果的信息包括用例通过率、每个用例的行为通过概率、稳定性错误记录、行为执行错误日志、以及截图信息。

下面结合一具体实施例对本发明作进一步说明：

所述系统通过后台管理模块来实现UI自动化测试任务的创建、及脚本的配置；再通过任务调度模块配置任务的执行参数，并下发到终端进行具体的执行；最后由终端执行模块执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给后台管理模块。

一、后台管理模块

所述后台管理模块一方面提供用户操作管理的界面，同时也负责数据管理及存储。包含如下内容：

1、用户可以通过后台管理模块创建对应的测试任务。以下均以自动化验证“登陆”操作为例进行介绍；

2、首先创建一个任务，名称为【登陆测试】，系统会默认生成一个任务ID(task_id)，并以此选择平台为安卓，测试框架为appium(此处仅为举例，本专利支持安卓、IOS平台，并支持包含但不局限于appium、calabash、ios ui automation、robotium等框架)；

3、继2选择自定义脚本，进入到自定义脚本上传页面，此处可以由用户自定义testcase(测试用例)的脚本，只需要用户按照对应测试框架的提供的模板接入编写即可，上传完脚本即完成任务的创建；

4、继2，选择的是非自定义脚本，则进入到脚本配置页面；

5、在脚本配置页面，系统提供一个测试数据导入功能(非必选，如果没有数据配置要求，可以直接到下一环节)，用于配置动态数据(例如：每台设备需要登陆使用的用户(User)、密码(Password))，支持excel模板导入，类似如下表1：

表1

6、继上，点击新增用例(每个用例都会生成唯一值ID：case_id)，进入到用例编辑页面。在用例编辑页面可以配置用例执行的具体行为；

7、继上，进行行为配置(每个行为都会生成唯一值ID：action_id)。行为配置可选的内容是基于步骤2中所选择的框架appium终端执行脚本所支持能力所对应匹配的。行为分为两类，一种是通用行为(Type为0)，包含但不局限于：保存截图、等待时间、上下左右滑动等(只要对应框架终端执行脚本支持就可以，举例，终端执行脚本新增了一个方法save_screenshot(用于保存截图)，后台就可以对应配置一个行为(保存截图)与之匹配，终端执行的时候会通过switch的方式选择定位到对应的方法执行)；一种是基于控件的行为(Type为1)，该行为配置具体分为对象选择和对象能力配置两个步骤；

8、继上，对象选择步骤：即首先选择对象的方式，方式包含但不局限于：id定位、name定位、classname定位、xpath定位、AccessibilityId定位、AndroidUiAutomator定位。假设登陆所使用到的【账号】、【密码】两个输入控件(input)及【登陆】按钮(button)都有id属性。用户只需要选择【id定位】，并输入对应的id值即绑定了该对象。

9、继上，绑定完对象，系统列出该对象的可操作功能。其可操作功能包含两类，一类是框架自带的所有操作方法，举例包含但不局限于：click(点击)、clear(清除)、set_value(输入内容)等；一类是用于辅助脚本执行的通用能力，包含但不局限于：元素检测(可以设置一段时间的元素检测是否存在)、异常捕获(捕获异常，并继续执行下一个行为)。对象能力配置步骤：即当选择了某个能力，即需要输入对应的能力的内容补充，至此就完成了该行为的配置。比如：输入账号、密码、点击登陆这一系列的操作可以通过配置如下内容来实现：

9.1、选择对象方式配置为id(id定位)，输入参数(id_user)。选择能力为set_value(输入内容)，输入参数(10001)；

9.2、选择对象方式配置为id(id定位)，输入参数(id_password)。选择能力为set_value(输入内容)，输入参数(123456)；

9.3、选择对象方式配置为id(id定位)，输入参数(id_login)。选择能力为click。截止目前，配置一部设备模拟登陆的配置已完成，但上文描述的账号密码是配置死的，不适合于多设备执行。所以本专利更优的提供了一个配置方式，即输入的内容引用步骤5中所导入的数据的key，具体配置如下内容来实现：

9.4、选择对象方式配置为id(id定位)，输入参数(id_user)。选择能力为set_value(输入内容)，输入参数(User)；

9.5、选择对象方式配置为id(id定位)，输入参数(id_password)。选择能力为set_value(输入内容)，输入参数(Password)；

9.6、选择对象方式配置为id(id定位)，输入参数(id_login)。选择能力为click。通过上述的配置，终端执行的时候会独立读取对应的账号、密码。当然其他的数据配置也可以通过类似的配置来实现(配置之后字段包含但不局限如下主要字段存储)参见表2；

表2

10、继上，登陆这个用例已经配置完毕，如果有其他用例，可以选择新增一个用例。继续6)-9)的操作。

二、任务调度模块，包含如下内容：

1、当完成任务配置之后，可以针对任务发起执行，首先需要上传对应需要测试的安装包(即测试包)。此处更优的是，提供一个restful api，可以通过输入对应的task_id和测试包下载链接，即可发起对应测试，此方式可以用户版本迭代发布时候的自动化构建；

2、继上，上传完安卓包之后系统会列出当前可使用的移动端设备列表，供用户进行挑选；

3、继上，当选中完测试移动端设备，点击开始执行后，就会在后台创建一条执行记录，并生成唯一值标识record_id，并将该record_id下发给终端进行执行。与此同时，本次任务调度所上传的测试包、所选择的测试移动端设备及对应的task_id都会被存入数据库中。

三、终端执行模块，包含如下内容：

1、终端负责监听接收服务端下发的请求，判断是否有命令下发；

2、继上，接到服务端下发的record_id，终端会发起一次请求查阅该record_id上所配置的相关信息，解析出当前终端执行所需要的相关参数，主要包含：1)测试的移动端设备列表、2)对应的测试框架、3)对应的task_id；

3、继上，通过解析出来的测试移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本。以上述appium为例，系统会以端口为C+N(C为用户自定义的一个固定数值，比如5000，N为目前的第N部设备，第一部就是0，)来启动一个appium服务器，并将该appium服务器地址和该设备的序列号及task_id(任务的ID)和N(传N的目的是为了让每部设备初始化的时候可以读取到独立的数据)作为参数，执行appium脚本。与此同时，更优的，会启动对应设备的logcat进行错误日志捕获。

4、继上，上述appium脚本是指一个通用的appium执行脚本，其会在初始化的时候，通过task_id查询该task_id下的所有配置信息，包括初始化的数据(初始化数据是一个list，每个脚本会根据步骤3所提供的N，读取独立的那一组数据，比如第1部设备读取的是list[0]，即初始化数据date＝list[0])及需要执行的用例、行为。更优的，初始化的时候，会发起设备占用的状态为修改该请求，标志当前设备正在使用中。

5、继上，终端会遍历执行每一个用例case及每个case下的action行为。当执行第一个行为的时候，就会根据配置的内容，获取选择find_element_by_id这个方法，并输入id_user这个参数获取到对象，并执行set_value这个方法，输入date[“User”]；当执行第二个行为的时候，就会根据配置的内容，获取选择find_element_by_id这个方法，并输入id_password这个参数获取到对象，并执行set_value这个方法，输入date[“Password”]；当执行第三个行为的时候，就会根据配置的内容，获取选择find_element_by_id这个方法，并输入id_login这个参数获取到对象，并执行click这个方法；

6、继上，执行的过程中会记录当前的执行进度，以登陆配置的3个行为来执行，如果全部执行通过，则该case_pass_rate和action_pass_rate分别为1/1和3/3。并在脚本全部执行完成的时候，会将其当前的测试结果反馈给服务器，并通知对应的测试人员，可以到后台查阅对应的测试报告，此时对应的设备占用的信息也会被取消。

7、继上，在后台管理上查阅该任务的测试结果，可以清晰的查看到目前的一个结果，其中包含以下信息：1)用例通过率；2)每个case的行为通过概率；3)稳定性错误记录；4)行为执行错误日志；5)截图信息。当某个用例执行错误的时候，可以具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。如果出现崩溃日志的话，还可以在稳定性错误记录上查阅到具体的客户端日志。

8、上述仅仅以appium为例，但同样以后台配置实现的动态数据调用执行的均属于本专利范畴。

如图6所示，本发明还提供了一种移动端UI自动化测试方法，所述方法包括如下步骤：

步骤S1、首先实现移动端UI自动化测试任务的创建、及脚本的配置；

步骤S2、配置任务的执行参数，并下发到终端进行具体的执行；

步骤S3、终端执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给服务器。

所述步骤S1进一步具体为：提供一用户操作管理的界面，通过界面创建对应的测试任务，创建一个测试任务后，默认生成一个任务ID，并以此选择操作平台和操作平台对应的测试框架；再进行脚本的配置，界面提供自定义脚本操作或者非自定义脚本操作，自定义脚本操作即用户自定义测试用例的脚本，用户按照对应测试框架提供的模板接入编写测试用例的脚本并上传脚本即完成任务的创建；非自定义脚本操作即提供一脚本配置页面，通过脚本配置页面将测试数据导入，并进行新增用例，每个用例都会生成唯一值用例ID，并配置用例执行的具体行为，每个行为都会生成唯一值行为ID，该行为配置分为两类，一类是通用行为配置，通用行为包含但不局限于：保存截图、等待时间、上下左右滑动；另外一类是基于控件的行为配置。

所述步骤S2进一步具体为：步骤S21、任务配置后，针对任务发起执行，上传对应需要测试的测试包；同时提供一个restful api，通过输入对应的任务ID即task_id和测试包下载链接，即能通过restful api发起对应测试；

步骤S22、上传完安装包之后系统会列出当前能使用的移动端设备列表，供用户进行挑选；

步骤S23、当选中需要测试的移动端设备，点击开始执行后，会创建一条执行记录，并生成唯一值标识记录record_id，并将该记录record_id下发给终端进行执行；同时，任务调度所上传的测试包、所选择的测试的移动端设备及对应的task_id都会被存入数据库中。

所述步骤S3进一步具体为：步骤S31、终端负责监听接收服务端下发的请求，判断是否有命令下发；

步骤S32、接到服务端下发的记录record_id，终端会发起一次请求查阅该记录record_id上所配置的信息，解析出当前终端执行所需要的相关参数，所述相关参数包括：测试的移动端设备列表、对应的测试框架、对应的task_id；

步骤S33、通过解析出来的移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本；

步骤S34、框架脚本通过task_id查询该task_id下的所有配置信息，包括初始化的数据及需要执行的用例、行为；

步骤S35、终端会遍历执行每一个用例及每个用例下的action行为；

步骤S36、执行的过程中会记录当前的执行进度，在脚本全部执行完成的时候，会将当前的测试结果反馈给服务器，并通知对应的测试人员，能查阅对应的测试报告；能查阅该任务的测试结果；当某个用例执行错误的时候，能具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。另外，所述测试结果的信息包括用例通过率、每个用例的行为通过概率、稳定性错误记录、行为执行错误日志、以及截图信息。

本发明的应用场景如下：

场景一：

同学小A的公司开始研发一款会议沟通软件，小A是负责该会议沟通软件的测试工程师。在前期的测试过程中，小A只能通过自己手上的几部设备完成对应的功能测试。由于会议沟通软件要支持100个以内的人员参会，小A需要模拟100个人参会的场景测试，但是手上并没有那么多的设备，所以小A只能把测试包发给公司的其他人员，邀请其他人帮忙登陆到同一个会议室中，以便于小A模拟测试多人会议的场景。由于多人会议的测试结果不理想，需要往返修复，甚至配合开发复现也需要其他人的配合才能模拟，这影响到了其他人的工作，最终导致在该场景验证的人力成本非常大。

通过本专利的方案，小A可以在本专利提供的后台进行测试任务的创建、执行，通过UI自动化的方式完成多人参会的测试场景模拟。以安卓设备为例，具体操作为：1)小A在后台创建一个名为“会议测试”的任务，并以此选择平台类型为安卓，测试框架为appium；2)小A选择脚本配置的方式进行创建脚本，并按照导入数据的模板要求导入对应所需要用到的100个账号、密码、会议号等相关信息；3)点击创建一个用例名为“登陆会议”，并根据进行会议的步骤对应的新增、配置UI自动化行为。4)最后保存任务配置，并上传对应的测试包，选中98台设备，并点击开始执行。这时候小A只需要用自己的安卓和IOS设备提前登陆到会议室中，就可以观察到自动化脚本所控制的98台设备陆续进入到会议过程中的一系列响应情况，此过程只需要小A一人即可完成。

场景二：

同学小B是一个新入职测试行业的萌新，主要负责移动端软件的测试执行，其中经常需要完成的任务就包括设备的适配，但是适配的工作极为的枯燥。小B考虑通过UI自动化的方式去完成适配工作，但是由于没有相关的经验，需要从0学习对应的自动化框架的API及对应的编程语言。

通过本专利的方案，同学小B只需要根据本专利提供的后台要求进行对应的配置管理即可完成对应的自动化测试，而不需要从新学习对应的编程语言。以一个登陆功能的验证为例，小明可以通过如下的简单操作来实现多台设备的自动化测试。1)创建一个名为(登陆验证)的任务，选择安卓平台，选择脚本配置。2)导入一份账号数据如表1，然后点击新增用例。在用例中新增行为，选择对象方式配置为id(id定位)，输入参数(id_user)。选择能力为set_value(输入内容)，输入参数(User)；然后选择对象方式配置为id(id定位)，输入参数(id_password)。选择能力为set_value(输入内容)，输入参数(Password)；最后选择对象方式配置为id(id定位)，输入参数(id_login)。选择能力为click，然后选择保存该任务。3)点击该任务进行执行，上传对应的测试包，选择需要测试的设备，然后点击下发任务。通过上述的操作，小B就可以静静等待测试结果的返回。

场景三：

同学小D、小E、小F都是一个自动化测试工程师，负责编写手机软件的自动化测试脚本，用于业务主流程上的验证。在编写脚本的过程中，小D和小E及小F都碰到了很多脚本不稳定的地方，对此各自针对性的去做了一些通用方法的封装，包括控件等待、异常捕获等操作。后来部门需要统一化，要对编写的方式进行统一规范化，发现大家的写法五花八门。统一的过程中，小D、小E等都费了不少时间进行维护。

通过本专利的方案，同学小D、小E、小F等只需要调用本专利提供的通用方法进行操作即可，当出现系统当前不满足的能力或者方法，只需要有一个人进行系统功能的新增或者维护，所有的同学就都可以使用上对应的能力。这样小D、小E、小F等就大大减少了重复性的脚本开发工作。

以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。

Claims (8)

1.一种移动端UI自动化测试系统，其特征在于：所述系统包括后台管理模块、任务调度模块、以及终端执行模块；所述后台管理模块负责数据上的管理，所述任务调度模块将数据打包为可执行的任务下发给终端，所述终端执行模块将执行的结果进行反馈操作；

所述系统通过后台管理模块来实现UI自动化测试任务的创建、及脚本的配置；再通过任务调度模块配置任务的执行参数，并下发到终端进行具体的执行；最后由终端执行模块执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给后台管理模块；

所述后台管理模块进一步具体为：后台管理模块提供一用户操作管理的界面，通过界面创建对应的测试任务，创建一个测试任务后，后台管理模块会默认生成一个任务ID，并以此选择操作平台和操作平台对应的测试框架；再进行脚本的配置，界面提供自定义脚本操作或者非自定义脚本操作，自定义脚本操作即用户自定义测试用例的脚本，用户按照对应测试框架提供的模板接入编写测试用例的脚本并上传脚本即完成任务的创建；非自定义脚本操作即提供一脚本配置页面，通过脚本配置页面将测试数据导入，并进行新增用例，每个用例都会生成唯一值用例ID，并配置用例执行的具体行为，每个行为都会生成唯一值行为ID，该行为配置分为两类，一类是通用行为配置，通用行为包含但不局限于：保存截图、等待时间、上下左右滑动；另外一类是基于控件的行为配置。

2.根据权利要求1所述的一种移动端UI自动化测试系统，其特征在于：所述任务调度模块进一步具体为：任务配置后，针对任务发起执行，上传对应需要测试的测试包；则任务调度模块提供一个restfulapi，通过输入对应的任务ID即task_id和测试包下载链接，即能通过restful api发起对应测试；

上传完安装包之后系统会列出当前能使用的移动端设备列表，供用户进行挑选；

当选中需要测试的移动端设备，点击开始执行后，任务调度模块就会创建一条执行记录，并生成唯一值标识记录record_id，并将该记录record_id下发给终端进行执行；同时，任务调度所上传的测试包、所选择的测试的移动端设备及对应的task_id都会被存入数据库中。

3.根据权利要求1所述的一种移动端UI自动化测试系统，其特征在于：所述终端执行模块进一步具体为：终端执行模块负责监听接收服务端下发的请求，判断是否有命令下发；

接到服务端下发的记录record_id，终端会发起一次请求查阅该记录record_id上所配置的信息，解析出当前终端执行所需要的相关参数，所述相关参数包括：测试的移动端设备列表、对应的测试框架、对应的task_id；

通过解析出来的移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本；

框架脚本通过task_id查询该task_id下的所有配置信息，包括初始化的数据及需要执行的用例、行为；

终端会遍历执行每一个用例及每个用例下的action行为；

执行的过程中会记录当前的执行进度，在脚本全部执行完成的时候，会将当前的测试结果反馈给服务器，并通知对应的测试人员，能查阅对应的测试报告；

在后台管理模块上能查阅该任务的测试结果；当某个用例执行错误的时候，能具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。

4.根据权利要求3所述的一种移动端UI自动化测试系统，其特征在于：所述测试结果的信息包括用例通过率、每个用例的行为通过概率、稳定性错误记录、行为执行错误日志、以及截图信息。

5.一种移动端UI自动化测试方法，其特征在于：所述方法包括如下步骤：

步骤S1、首先实现移动端UI自动化测试任务的创建、及脚本的配置；

步骤S2、配置任务的执行参数，并下发到终端进行具体的执行；

步骤S3、终端执行下发的请求，完成一系列执行的过程中进行对应的数据收集，并反馈给服务器；

所述步骤S1进一步具体为：提供一用户操作管理的界面，通过界面创建对应的测试任务，创建一个测试任务后，默认生成一个任务ID，并以此选择操作平台和操作平台对应的测试框架；再进行脚本的配置，界面提供自定义脚本操作或者非自定义脚本操作，自定义脚本操作即用户自定义测试用例的脚本，用户按照对应测试框架提供的模板接入编写测试用例的脚本并上传脚本即完成任务的创建；非自定义脚本操作即提供一脚本配置页面，通过脚本配置页面将测试数据导入，并进行新增用例，每个用例都会生成唯一值用例ID，并配置用例执行的具体行为，每个行为都会生成唯一值行为ID，该行为配置分为两类，一类是通用行为配置，通用行为包含但不局限于：保存截图、等待时间、上下左右滑动；另外一类是基于控件的行为配置。

6.根据权利要求5所述的一种移动端UI自动化测试方法，其特征在于：所述步骤S2进一步具体为：步骤S21、任务配置后，针对任务发起执行，上传对应需要测试的测试包；同时提供一个restful api，通过输入对应的任务ID即task_id和测试包下载链接，即能通过restful api发起对应测试；

步骤S22、上传完安装包之后系统会列出当前能使用的移动端设备列表，供用户进行挑选；

步骤S23、当选中需要测试的移动端设备，点击开始执行后，会创建一条执行记录，并生成唯一值标识记录record_id，并将该记录record_id下发给终端进行执行；同时，任务调度所上传的测试包、所选择的测试的移动端设备及对应的task_id都会被存入数据库中。

7.根据权利要求5所述的一种移动端UI自动化测试方法，其特征在于：所述步骤S3进一步具体为：步骤S31、终端负责监听接收服务端下发的请求，判断是否有命令下发；

步骤S32、接到服务端下发的记录record_id，终端会发起一次请求查阅该记录record_id上所配置的信息，解析出当前终端执行所需要的相关参数，所述相关参数包括：测试的移动端设备列表、对应的测试框架、对应的task_id；

步骤S33、通过解析出来的移动端设备列表，依次发起对应测试移动端设备的调用，执行对应的框架脚本；

步骤S34、框架脚本通过task_id查询该task_id下的所有配置信息，包括初始化的数据及需要执行的用例、行为；

步骤S35、终端会遍历执行每一个用例及每个用例下的action行为；

步骤S36、执行的过程中会记录当前的执行进度，在脚本全部执行完成的时候，会将当前的测试结果反馈给服务器，并通知对应的测试人员，能查阅对应的测试报告；能查阅该任务的测试结果；当某个用例执行错误的时候，能具体定位到是哪个用例的哪个行为操作错误，并查阅到对应的行为执行错误日志。

8.根据权利要求7所述的一种移动端UI自动化测试方法，其特征在于：所述测试结果的信息包括用例通过率、每个用例的行为通过概率、稳定性错误记录、行为执行错误日志、以及截图信息。

Images