CN109144856A - 一种ui自动化测试方法、计算设备及存储介质 - Google Patents

Abstract

本发明公开了一种UI自动化测试方法，在浏览器中执行，方法包括：配置与测试场景对应的结构化数据；将操作指令的指令行为映射为第一关键字；将断言操作的预期类型映射为第二关键字；基于结构化数据、第一关键字和第二关键字，在测试场景中执行操作指令；以及根据断言操作的预期类型，生成测试结果报告。本方案解决了基于UI层面的浏览器/服务器结构的web系统的自动化测试与监控问题。

Description

一种UI自动化测试方法、计算设备及存储介质

技术领域

本发明涉及互联网测试技术领域，尤其涉及一种UI自动化测试方法、计算设备及存储介质。

背景技术

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

其中，UI(用户界面)自动化测试是用户使用产品的入口，所有功能通过这一层提供给用户，测试工作大多集中在这一层，常见的测试工具有UFT、Robot Framework、Selenium、Appium等。

目前，UI自动化测试软件比较代表的是Selenium，该软件存在诸多不足，例如录制脚本对网页结构依赖较大，实际情况下，有较大机率会回放不成功；采用了通过javascript脚本来驱动浏览器动作的方法，该方式严重依赖各浏览器js的解析能力，会导致执行一次任务耗时较长；需要在执行机器上安装不同的浏览器以执行相应的任务，这种情况下，无法支持无界面的linux服务器；在实际情况下，由于系统升级迭代较快，页面结构频繁变动，导致脚本的复用率较低，每次改版需要技术人员重新录制脚本，工作较繁重；需要借助其它编程语言例如python来实现截图；网页内容大多都采用异步加载的方式，对于这类网页，selenium并没有与之相应的页面加载等待机制；采用类似基于DOM的定位策略，如：xpath、id、name、identifier等页面元素标识，然而，在实际情况下，页面的元素并非如预期般明确。在测试用户界面的时候，也需要像服务端接口一样，需要对页面元素进行mock(在测试中，对于某些不容易获取的对象，用一个虚拟的对象来创建以便测试的一种方法)，以此来快速模拟需要测试的场景，但selenium缺少这方面功能，导致进行自动测试的时候，测试人员需要提前在被测试系统中录入各种场景数据，这样不但增加了测试人员的工作量，还对测试数据有侵入；仅仅解决了测试的问题，并没有解决自动监控的需求，而实际业务中，线上系统的稳定运行，依赖各种中间件和第三方服务，不确定性较大，经常上线前的测试功能是正常的，但是在线上时常会发生功能错误，技术人员无法在第一时间知道，导致公司产生损失。

因此需要一种UI自动化测试方案，能够解决不同网页、不同业务的自动化测试与监控问题。

发明内容

为此，本发明提供了一种UI自动化测试方法，以力图解决或者至少缓解上面存在的至少一个问题。

根据本发明的一个方面，提供了一种UI自动化测试方法，在计算设备中执行，在该方法中，首先，配置与测试场景对应的结构化数据。然后将操作指令的指令行为映射为第一关键字，将断言操作的预期类型映射为第二关键字。就可以基于结构化数据、第一关键字和第二关键字，在测试场景中执行操作指令。最后根据断言操作的预期类型，生成测试结果报告。

该方案利用数据驱动的场景描述、关键字驱动的指令操作和预期断言，能够模拟人工测试的行为，解决适配不同网页、不同业务的自动化测试和监控问题。

可选地，在上述方法中，测试场景可以包括模拟设备类型、网页请求协议头、网页入口网址、用于服务器辨别身份的数据cookies、前置等待(文档对象模型)dom、后置等待、超时时间、拦截请求中的一种或多种。可以首先基于测试场景，创建浏览器实例，然后基于浏览器实例，创建浏览器标签，最后基于浏览器标签中的方法，配置与测试场景对应的结构化数据。

可选地，在上述方法中，可以将Click对应于点击页面、Tap对应于点击触发、Type对应于键盘输入、Reload对应于网页刷新、cookie对应于写入用于服务器辨别身份的数据、redirect对应于重定向、header对应于设置网页请求头、enterframe对应于指定子页面、goto对应于页面跳转、mock对应于拦截操作、script对应于脚本注入，以便将操作指令的指令行为映射为第一关键字。

可选地，在上述方法中，断言操作的预期类型可以包括指定dom值/属性/样式/位置检测、脚本检测、cookie检测、请求资源检测、响应头检测中的一种或多种。

可选地，在上述方法中，可以判断测试场景是否配置了前置等待dom或前置等待时长，如果是，则等待网页加载出指定的dom或暂停指定时长后，执行所述操作指令。然后，按顺序读取测试场景的操作指令，其中，操作指令可以包括指令名称、指令编号、指令行为和/或前置等待dom和/或后置等待。最后基于指令行为对应的第一关键字，依次执行操作指令。

可选地，在上述方法中，如果第一关键字是元素检查，则进行断言操作。或者，在依次执行完操作指令后，进行断言操作。

可选地，在上述方法中，还可以在执行完一条操作指令之后，判断测试场景是否配置了后置等待，如果是，则暂停指定时长再执行下一条操作指令。

可选地，在上述方法中，可以在执行完每一条操作指令后，进行现场截图，以便测试人员查看并进行问题定位。

可选地，在上述方法中，可以获取每一条操作指令的预期断言，其中，预期断言可以包括预期内容、目标dom、预期类型、预期值。然后，将每一条操作指令的测试值与预期值比较，生成测试结果报告。

根据本发明另一个方面，提供了一种计算设备，包括一个或多个处理器；和存储器；一个或多个程序，这一个或多个程序存储在存储器中并被配置为由一个或多个处理器执行，这里的一个或多个程序包括用于执行上述自动化测试方法的指令。

根据本发明另一个方面，提供一种存储一个或多个程序的计算机可读存储介质，这一个或多个程序包括指令，当指令由计算设备执行时，使得计算设备执行上述自动化测试方法。

上述方案利用场景的描述来控制每次的测试是在哪个页面工作的，利用操作流来执行不同的指令，其中，通过数据驱动来导航到相应的页面并执行指定指令，解决了适配不同网页、不同业务的自动化测试与监控问题。解决了执行完指令后，模拟人工来检查是否结果符合预期的问题。

附图说明

为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

图1示出了selenium远程代理服务器的示意性运行流程图；

图2示出了基于Selenium的JUnit的示意性测试容器架构图；

图3示出了根据本发明的一个实施例的计算设备300的构造示意图；

图4示出了根据本发明的一个实施例的UI自动化测试方法400的示意性流程图；

图5示出了根据本发明的一个实施例的场景定义的示意图；

图6示出了根据本发明的一个实施例的操作指令的示意图；

图7示出了根据本发明的一个实施例的预期断言的示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

目前用户界面UI自动化测试软件比较代表的是selenium，需要启动一个代理服务器来处理用户与测试服务器之间的通讯。Selenium引入远程控制服务器(Remote ControlServer)，JavaScript脚本注入和与测试服务器通讯都通过这个代理服务器来进行。图1示出了selenium远程代理服务器的示意性运行流程图(图1中所示的网页内容及流程图仅仅是示意性的，用户界面上的内容并不造成本方案的保护范围不清楚)。如图1所示，基本流程包括：1.客户端建立与Remote Control Server的连接。2.Remote Control Server启动一个浏览器(或是已经使用中)，并注入JS代码。3.将Selenese代码传到客户端的js类库Selenium-Core中。4.Selenium-Core翻译并解析执行用户录制的操作。5.让代理Server进行通讯。6.Remote Control Server负责跟远程Web应用服务器进行通讯。7.操作完成，显示结果，并执行下一指令。

另外测试录制工具selenium IDE支持录制用户操作，进行回放测试的功能。包括：1.点击selenium IDE工具中的录制按钮。2.录制过程中，登录用户界面，输入用户名密码。3.然后可以通过是否包含某些字符串来验证是否登录成功。4.回到登录IDE界面，查看已录制步骤。5.在IDE界面中可以验证录制的脚本，必要时可以回到第4步。6.在IDE中重运行录制的脚本通过就说明脚本没问题，就可以把测试脚本导出成Java语言的单元测试框架JUnit测试用例。

图2示出了基于Selenium的JUnit的示意性测试容器架构图(图2中所示的网页内容及流程图仅仅是示意性的，用户界面上的内容并不造成本方案的保护范围不清楚)。如图2所示，步骤1-步骤2需要测试人员完成，在步骤1中由测试人员录制脚本，生成并导出Junit测试用例。在步骤2中修改配置文件，将需要运行的测试用例写入测试套件中。步骤3-步骤6由自动化集成测试工具执行。在步骤3中测试框架定期检测配置的测试套件，读取所有需要运行的测试用例。在步骤4中动态加载这些测试用例。在步骤5中以测试套件为单位依次执行所有的测试用例。以及在步骤6中将测试套件的结果生成报表并发送邮件通知管理人员。这套框架的意义在于，它能自动识别测试用例，并读取配置文件以测试套件运行不同的测试用例。它还可以被合并到项目持续集成软件中，定期地持续进行基于Web的功能性测试，并将报告以邮件形式通知管理人员。

由此可见，Selenium提供了一套录制脚本进行自动测试的功能，但录制脚本对网页结构依赖较大，在实际情况下，由于bs结构系统，升级迭代较快，页面结构频繁变动，导致脚本的复用率较低，每次改版需要技术人员重新录制脚本，有较大机率会回放不成功。

本方案直接使用chrome浏览器内核，通过程序去操作chrome浏览器自动化操作，采用数据驱动、关键字驱动进行模拟人工操作。

图3示出了根据本发明的一个实施例的计算设备300的构造示意图。在基本的配置102中，计算设备300典型地包括系统存储器106和一个或者多个处理器104。存储器总线108可以用于在处理器104和系统存储器106之间的通信。

取决于期望的配置，处理器104可以是任何类型的处理，包括但不限于：微处理器(μP)、微控制器(μC)、数字信息处理器(DSP)或者它们的任何组合。处理器104可以包括诸如一级高速缓存110和二级高速缓存112之类的一个或者多个级别的高速缓存、处理器核心114和寄存器116。示例的处理器核心114可以包括运算逻辑单元(ALU)、浮点数单元(FPU)、数字信号处理核心(DSP核心)或者它们的任何组合。示例的存储器控制器118可以与处理器104一起使用，或者在一些实现中，存储器控制器118可以是处理器104的一个内部部分。

取决于期望的配置，系统存储器106可以是任意类型的存储器，包括但不限于：易失性存储器(诸如RAM)、非易失性存储器(诸如ROM、闪存等)或者它们的任何组合。系统存储器106可以包括操作系统120、一个或者多个程序122以及程序数据124。在一些实施方式中，程序122可以布置为在操作系统上利用程序数据124进行操作。

计算设备300还可以包括有助于从各种接口设备(例如，输出设备142、外设接口144和通信设备146)到基本配置102经由总线/接口控制器130的通信的接口总线140。示例的输出设备142包括图形处理单元148和音频处理单元150。它们可以被配置为有助于经由一个或者多个A/V端口152与诸如显示器或者扬声器之类的各种外部设备进行通信。示例外设接口144可以包括串行接口控制器154和并行接口控制器156，它们可以被配置为有助于经由一个或者多个I/O端口158和诸如输入设备(例如，键盘、鼠标、笔、语音输入设备、触摸输入设备)或者其他外设(例如打印机、扫描仪等)之类的外部设备进行通信。示例的通信设备146可以包括网络控制器160，其可以被布置为便于经由一个或者多个通信端口164与一个或者多个其他计算设备162通过网络通信链路的通信。

网络通信链路可以是通信介质的一个示例。通信介质通常可以体现为在诸如载波或者其他传输机制之类的调制数据信号中的计算机可读指令、数据结构、程序模块，并且可以包括任何信息递送介质。“调制数据信号”可以这样的信号，它的数据集中的一个或者多个或者它的改变可以在信号中编码信息的方式进行。作为非限制性的示例，通信介质可以包括诸如有线网络或者专线网络之类的有线介质，以及诸如声音、射频(RF)、微波、红外(IR)或者其它无线介质在内的各种无线介质。这里使用的术语计算机可读介质可以包括存储介质和通信介质二者。

计算设备300可以实现为服务器，例如文件服务器、数据库服务器、应用程序服务器和WEB服务器等，也可以是小尺寸便携(或者移动)电子设备的一部分，这些电子设备可以是诸如蜂窝电话、个人数字助理(PDA)、个人媒体播放器设备、无线网络浏览设备、个人头戴设备、应用专用设备、或者可以包括上面任何功能的混合设备。计算设备300还可以实现为包括桌面计算机和笔记本计算机配置的个人计算机。在一些实施例中，计算设备300可被配置为执行根据本发明的UI自动化测试方法。其中，计算设备300的一个或多个程序122包括用于执行根据本发明的UI自动化测试方法的指令。

本方案主要针对基于chrome浏览器的UI自动化测试，可以分为三步：场景定义、操作指令集定义和预期断言。由于不同的业务需要，导致每种测试的内容并不相同，为了使UI自动测试与监控软件通用性更大，采用数据驱动的设计思想。

图4示出了根据本发明的一个实施例的UI自动化测试方法400的示意性流程图。如图4所示，在步骤S410中，可以配置与测试场景对应的结构化数据。

由于Chrome浏览器的无界面模式很方便做自动化测试，无需注入js脚本，可以采用chrome浏览器底层开放的API来直接控制浏览器。

执行一个场景代表一次要测试的具体任务。可以由结构化的数据来描述不同的测试场景，进而实现控程序的执行逻辑，其中，结构化数据可以将无规律的文字描述，转化为一段标准(key-value)键值对的json格式数据，这样就可以将人类的意图告诉计算机，要执行怎样的操作。

根据本发明的一个实施例，可以基于测试场景，创建浏览器实例；基于浏览器实例，创建浏览器标签；以及基于浏览器标签中的方法，配置与测试场景对应的结构化数据。

图5示出了根据本发明的一个实施例的场景定义的示意图。如图5所示，测试场景可以包括要模拟的设备类型、网页请求协议头、网页入口网址、用于服务器辨别身份的数据cookies、前置等待dom、后置等待、超时时间、拦截请求等基本信息。例如设备类型可以包括iPhone、Android、iPad、pc等，mock拦截请求信息可以包括HTTP状态码和响应内容。

根据本发明的一个实施例，可以采用Nodejs编程语言进行开发，场景具体实现方法可以如下：

1)创建一个chrome浏览器内核对象puppeteer实例。其中，Puppeteer是一个控制无界面Chrome的Node库，可以通过Puppeteer的提供的API直接控制Chrome模拟大部分用户操作来进行UI自动化测试。

2)调用puppeteer实例的newPage方法创建一个浏览器标签page，调用page的setExtraHTTPHeaders方法，设置网页的请求协议头。其中，newPage方法可以打开一个新选项卡并返回选项卡的实例page，通过page上的各种方法可以对页面进行常用操作。

3)设置page的useragent、width、height、viewport等属性，来实现设备要模拟的硬件设备。其中，通过useragent，web服务器可以判断当前HTTP请求的客户端浏览器类别。例如配置如下：User-Agent：Mozilla/5.0(Windows；U；Windows NT 5.1；zh-CN；rv：1.8.1.11)Gecko/20071127 Firefox/2.0.0.11。

4)调用page的request方法，以实现针对网页发送的任何请求进行监控与重写，以此来实现场景配置中的mock拦截功能。

5)调用page的setCookie方法来写入场景配置中的cookie内容，以便针对需要登录的系统完成身份验证。其中，Cookie指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据。

6)调用page的goto方法，操作浏览器标签请求指场景配置的入口网址。

场景的定义确定了应该访问哪个网址，接下来，需要让软件知道进行什么样的操作。为了降低自动化测试软件脚本的维护成本，可以采用关键字驱动的方式。图6示出了根据本发明的一个实施例的操作指令的示意图。如图6所示，操作指令可以包括指令名称、指令编号、指令动作、前置等待dom、后置等待，其中，指令动作(行为)可以包括检查、点击页面、输入文字、刷新、跳转、重定向等。

在步骤S420中，可以将操作指令的指令行为映射为第一关键字。可以将UI测试中实际人为的不同行为映射到不同的关键字中，每一个关键字代表一种指令行为。例如，将Click对应于点击页面、Tap对应于点击触发、Type对应于键盘输入、Reload对应于网页刷新、cookie对应于写入cookie、redirect对应于重定向、header对应于设置网页请求头、enterframe对应于指定子页面、goto对应于页面跳转、mock对应于拦截操作、script对应于脚本注入等等。

与人工类似，在测试场景内执行每一步操作指令之后，都可以进行一系列的检查，以此来确定网页响应是否达到预期，网页功能是否正确无误。

图7示出了根据本发明的一个实施例的预期断言的示意图。如图7所示，预期断言可以包括预期内容、目标dom、预期类型、预期值。

和操作指令类似，为了解决预期结果不与具体业务紧密耦合，同样采用了关键字驱动的方式。在步骤S430中，可以将断言操作的预期类型映射为第二关键字。将实际人工测试中需要做出判断的种类，抽象成不同的关键字，每种关键字可以代表一大类的判断行为。

这样，与第一关键字相结合，可以组合成百上千种不同的自动化测试脚本，以满足日常UI自动化测试与监控需求。其中，第一关键字和第二关键字相结合可以是数学中的排列组合。例如：判断结果的类型有，检查字体的颜色、检查提示语的文字内容，检查指定网页区域是否隐藏起来了，检查按纽的可点击状态等等。而这些判断结果的类型，是可以放到操作指令中，例如是点击操作、还是跳转、还是输入表单等。

根据本发明的一个实施例，断言操作的预期类型可以包括指定dom的值判断、字体颜色判断、显示的文案判断、指定区域的html结构判断、字号判断、指定dom的样式判断、是否展现、判断浏览器是否请求的指定的资源、脚本检测、cookie检测、响应头检测等。

随后，在步骤S440中，可以基于步骤S410配置的结构化数据、步骤S420中与指令行为对应的第一关键字和步骤S430中与预期类型对应的第二关键字，在测试场景中执行操作指令。

根据本发明的一个实施例，可以首先判断测试场景是否配置了前置等待dom或前置等待时长，如果配置了前置等待dom，会调用page对象的waitForFunction来使浏览器等待网页加载出指定的dom后才正式进入操作指令的步骤。如果操作指令配置了前置等待，则调用setTimeout使系统暂停指定时长，再正式执行操作。其中，前置等待时长是指有时候网页加载已经完成了，但是界面上一些数据是异步加载出来的，这个时长会根据环境的不同而不一致，所以为了解决这个问题，设置了一个前置等待时长，当浏览器加载完成后，并不马上去执行自动化测试，而是等待指定的时长(给网页一定的时间去完成异步加载的数据)再去操作。

然后按顺序读取测试场景的操作指令，基于指令行为对应的第一关键字，依次执行操作指令。

当判断第一关键字是元素检查，则直接进入断言操作；

如果判断第一关键字是tap，则调用page对象的tap方法来实现页面tap操作；

如果判断第一关键字是goto，则调用page对象的goto方法来实现跳转。

如果判断第一关键字是click，则调用page对象的click方法来实现点击操作；

如果判断第一关键字是type，则调用page对象的type方法来实现键盘输入操作；

如果判断第一关键字是reload，则调用page对象的reload方法来实现网页刷新；

如果判断第一关键字是enterframe，则调用page对象的frames方法来进入指定子页面；

如果判断第一关键字是header，则调用page对象的setExtraHTTPHeaders方法来设置请求头；

如果判断第一关键字是mock，则在page进行onrequest的时候进行拦截操作；

如果判断第一关键字是script，则调用page对象的evaluate方法进行脚本注入操作。

根据本发明的一个实施例，在执行完一条操作指令后，可以判断测试场景是否配置了后置等待，如果是，则暂停指定时长再执行下一条操作指令。例如，通过调用setTimeout方法，使当前系统暂停指定时长。后置等待时长是指完成一次按纽的点击后等待的时长，例如，有时点击提交按纽，并不是马上就执行完，而有一定的服务器响应时间，这时后置等待时长就是完成点击后，可以等待一定的时间，再去操作下一步。

根据本发明的一个实施例，在执行完每一条操作指令后，可以进行现场截图。例如，通过调用page对象的screens方法进行现场截图。其中，现场截图是指在执行每一步指令的时候，将当时浏览器的界面保存下来，这样可以给报告查看人员更直观的每一步是怎样执行的，以及如果测试用例未通过的时候，例如：期望功能正常，但实际网页给出了错误提示，这样报告查看人员可以知道当时测试失败的实际现场状态，方便开发及测试人员定位问题。

当所有的操作指令执行完成，进入断言操作。在步骤S450中，可以根据断言操作的预期类型，生成测试结果报告。

可以获取每一条操作指令的预期断言，将每一条操作指令的测试值与预期值比较，生成测试结果报告。

例如，如果预期类型是dom属性检测，则根据配置的dom元素，自动生成脚本document.querySelector(″${assert.dom}″).${assert.key}。调用page对象的evaluate方法，将以上脚本作为参数传入，可得到浏览器中指定dom的属性值。之后与预期值进行对比，即可得到是否通过的结论。

如果预期的类型是请求资源的检测，则在当前实体的_request集合属性中查找是否包含指令网址，如果不存在指定网址，则预期失败。如果存在，则继续检测request.method请求类型get/post是否与预期一致，如果一致还需要检测请求的参数值request.postData是否与预期相一致。以上如果都一致，则预期通过，反之，则验证失败。

如果预期的类型是样式检测，则根据配置的dom元素，自动生成脚本window.getComputedStyle(document.querySelector(″${assert.dom}″)).${assert.key}调用page对象的evaluate方法，将以上脚本作为参数传入，可得到浏览器中指定dom的指定样式值，之后可与预期值进行对比，即可得到是否通过的结论。

如果预期的类型是脚本检测，则根据配置的脚本，调用page对象的evaluate方法，直接执行指定脚本，将返回值与预期的内容进行对比，如果一致，则预期通过，反之，则验证失败。

如果预期的类型是cookie检测，则调用page对象的cookies方法，获取到当前网页的所有cookie，之后从中匹配是否含有预期的cookie值，如果含有，则预期通过，反之，则验证失败。

在生成测试结果报告之后，可以根据软件中的设置，将相应报告以邮件的形式通知测试人员，以供技术人员第一时间知道自己提交的代码是否功能正常。

A9、如A5所述的方法，其中，所述基于所述结构化数据、所述第一关键字和所述第二关键字，在所述测试场景中执行所述操作指令的步骤还包括：在执行完每一条操作指令后，进行现场截图。

A10、如A1所述的方法，其中，所述根据断言操作的预期类型，生成测试结果报告的步骤包括：获取每一条操作指令的预期断言，所述预期断言包括预期内容、目标dom、预期类型、预期值；将每一条操作指令的测试值与预期值比较，生成测试结果报告。

上述方案利用场景描述、操作指令、预期断言的方式，来模拟人工测试UI系统的行为，解决了基于UI层面的BS结构web系统的自动化测试与监控问题。从面向对象的思想出发，将同样的操作指令，编写成一个类或者函数作为关键字来被不同场景的测试脚本所调用。这样，在以后要增加其他的操作指令的时候，不需要修改原有的程序代码，只需要添加一个相应的指令类文件或增加相应的判断函数，就可以增强原有的功能。根据实际业务情况，将人工测试过程需要的所有行为都提炼到不同的函数和类中，进而形成了一整套以关键字驱动的自动化测试软件。

测试人员可以根据不同的关键字创建一系列相关联的测试指令，由软件自动调用相关的动作来代替人工实现ui的自动化测试与监控，解决了软件开发中，UI测试人工效率低下且容易疏漏的问题。

与现有的自动化测试方法相比，本方案直接使用chrome浏览器内核，通过程序去操作chrome浏览器自动化操作，无需注入js脚本，采用chrome浏览器底层开放的api来直接控制浏览器，无中间传输损失，执行效率高。

本方案采用约定大于配置的方式，为html结构约定指定标记，即使下次改版，页面结构发生较大变化，之前的测试脚本依然可以很好的执行。大大降低了技术人员的维护的成本。

本方案将现场的快照集成到自动化任务中，同时支持常规快照、断言失败快照、指定元素快照、指定区域快照。大大提高工作效率以及软件的可用性。在发生问题的时候，为技术人员高效解决问题，提供了决策依据。

本方案设计了一种探测页面dom元素的机制，可以等待页面上出现了符合条件的dom后才开始执行任务的功能。解决了ajax异步页面加载页面时无法确定页面是否完成加载的问题。

本方案采用了一种主动查询的机制，网页在开发时，由开发者按约定在需要操作的元素上，绑定相应的指令，如：auto_test_click＝true，软件即可在网页加载完毕后自动去查找含有这类指令的所有元素。这类指令不属于w3c规范，不会与网页现有标准发生冲突，也不会在日后网页修改id、name、class时脚本失效，它不受限于特定的元素属性。在没有id、name值的情况下，它可以使用一些如“title、value”等属性，这些都是页面可见的属性，所见即所得。通过传入这些可见可识别的属性值，来按照软件预设的机制进行查询识别。另外可以允许使用者对每一种元素设置不同的属性和特定的查找顺序，包括那些自定义的属性名。所以，相对于selenium，本软件更灵活更开放。

本方案支持对浏览器指定的网络请求进行拦截和改写，因此，可以改变原本服务端的输出内容，对网页展示的内容进行定制化，从而可以在不影响测试数据库的前提下，任意模拟想要测试的场景，大大提高测试效率。

本方案支持部署在linux服务器上24小时无间断的模拟浏览器操作对线上业务实现全方位监控。在故障发生的第一时间可以报警通知技术人员及时处理。

应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如软盘、CD-ROM、硬盘驱动器或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践本发明的设备。

在程序代码在可编程计算机上执行的情况下，计算设备一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明所述的方法。

以示例而非限制的方式，计算机可读介质包括计算机存储介质和通信介质。计算机可读介质包括计算机存储介质和通信介质。计算机存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在计算机可读介质的范围之内。

此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。

尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (10)

1.一种UI自动化测试方法，在计算设备中执行，所述方法包括：

配置与测试场景对应的结构化数据；

将操作指令的指令行为映射为第一关键字；

将断言操作的预期类型映射为第二关键字；

基于所述结构化数据、所述第一关键字和所述第二关键字，在所述测试场景中执行所述操作指令；以及

根据断言操作的预期类型，生成测试结果报告。

2.如权利要求1所述的方法，其中，所述测试场景包括模拟设备类型、网页请求协议头、网页入口网址、用于服务器辨别身份的数据cookies、前置等待文档对象模型dom、后置等待、超时时间、拦截请求中的一种或多种，所述配置与测试场景对应的结构化数据的步骤包括：

基于测试场景，创建浏览器实例；

基于浏览器实例，创建浏览器标签；以及

基于浏览器标签中的方法，配置与测试场景对应的结构化数据。

3.如权利要求1所述的方法，其中，所述将操作指令的指令行为映射为第一关键字的步骤包括：

将Click对应于点击页面、Tap对应于点击触发、Type对应于键盘输入、Reload对应于网页刷新、cookie对应于写入用于服务器辨别身份的数据、redirect对应于重定向、header对应于设置网页请求头、enterframe对应于指定子页面、goto对应于页面跳转、mock对应于拦截操作、script对应于脚本注入。

4.如权利要求1所述的方法，其中，所述断言操作的预期类型包括指定dom值/属性/样式/位置检测、脚本检测、cookie检测、请求资源检测、响应头检测中的一种或多种。

5.如权利要求4所述的方法，其中，所述基于所述结构化数据、所述第一关键字和所述第二关键字，在所述测试场景中执行所述操作指令的步骤包括：

按顺序读取测试场景的操作指令，所述操作指令包括指令名称、指令编号、指令行为和/或前置等待dom和/或后置等待；

基于指令行为对应的第一关键字，依次执行所述操作指令。

6.如权利要求5所述的方法，其中，在所述按顺序读取测试场景的操作指令的步骤之前，还包括：

判断测试场景是否配置了前置等待dom或前置等待时长，如果是，则等待网页加载出指定的dom或暂停指定时长后，执行所述操作指令。

7.如权利要求5所述的方法，其中，所述基于指令行为对应的第一关键字，依次执行所述操作指令的步骤包括：

如果第一关键字是元素检查，则进行断言操作；以及/或者

在依次执行完所述操作指令后，进行断言操作。

8.如权利要求5所述的方法，其中，所述基于所述结构化数据、所述第一关键字和所述第二关键字，在所述测试场景中执行所述操作指令的步骤包括：

在执行完一条操作指令后，判断测试场景是否配置了后置等待，如果是，则暂停指定时长再执行下一条操作指令。

9.一种计算设备，包括：

一个或多个处理器；和

存储器；

一个或多个程序，其中所述一个或多个程序存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行根据权利要求1-8所述的方法中的任一方法的指令。

10.一种存储一个或多个程序的计算机可读存储介质，所述一个或多个程序包括指令，所述指令当计算设备执行时，使得所述计算设备执行根据权利要求1-8所述的方法中的任一方法。