CN112368685A - 可定制的企业自动化测试框架 - Google Patents

Abstract

实施例提供了用于实现可定制的企业自动化测试框架的系统和方法。可以接收用于企业网站的自动化测试的工作流定义、页面结构定义和函数定义。混合脚本解析器可以解析工作流定义、页面结构定义和函数定义，以生成用于自动化测试的混合脚本。自动化工具解析器可以解析混合脚本以生成自动化工具的输出。基于来自自动化工具解析器的输出，可以生成运行时脚本，该运行时脚本由自动化工具执行以生成自动化测试的结果，其中自动化工具在企业网站的多个网页上实现一个或多个工作流的步骤，以生成自动化测试的结果。

Description

可定制的企业自动化测试框架

相关申请的交叉引用

本申请要求于2019年4月5日提交的编号为16/376,484的美国专利申请的优先权，其公开内容通过引用并入本文。

技术领域

本公开的实施例一般而言涉及可定制的企业web应用自动化测试框架。

背景技术

企业实体的web存在已变得越来越重要。例如，这些年来电子商务已成倍增长，而其它企业活动也越来越向线上转移。另外，随着web技术的进步，web应用和网站已经获得了复杂的功能。这些趋势已经改变了企业系统客户端、客户和/或用户的期望。例如，远非无缝的在线交易、集成和/或工作流可能导致对可用性问题的抱怨。因此，企业web存在(webpresence)可能经常会用新的功能或内容进行更改或更新，但仍期望维持或增强可用性。因而，可以自动化测试可定制的和实现工作效率的web存在的框架可以极大地改善企业网站或web应用。

发明内容

本公开的实施例一般而言针对用于实现可定制的企业自动化测试框架的系统和方法，该系统和方法对现有技术进行了实质性的改进。可以接收用于企业网站的自动化测试的工作流定义、页面结构定义和函数定义，其中工作流定义为包括一系列步骤的一个或多个测试用例定义一个或多个工作流，页面结构定义定义包括企业网站的多个网页的web元素，以及函数定义定义由一个或多个工作流的步骤引用的特定于企业网站的函数。混合脚本解析器可以解析工作流定义、页面结构定义和函数定义，以生成用于自动化测试的混合脚本。自动化工具解析器可以解析混合脚本以生成自动化工具的输出。基于来自自动化工具解析器的输出，可以生成运行时脚本，该运行时脚本由自动化工具执行以生成自动化测试的结果，其中自动化工具在企业网站的多个网页上实现一个或多个工作流的步骤，以生成自动化测试的结果。

实施例的特征和优点在下面的描述中阐述，或者从描述中显而易见，或者可以通过本公开的实践而获知。

附图说明

通过结合附图对优选实施例的以下具体实施方式，其它实施例、细节、优点和修改将变得显而易见。

图1图示了根据示例实施例的用于实现可定制的企业自动化测试框架的系统。

图2图示了根据示例实施例的可操作地耦合到系统的计算设备的框图。

图3图示了根据示例实施例的用于实现可定制的企业自动化测试框架的另一个系统。

图4A、4B、5A和5B图示了根据示例实施例的企业web应用的版本。

图6A图示了根据示例实施例的示例工作流定义。

图6B图示了根据示例实施例的用于搜索航班的示例工作流。

图6C图示了根据示例实施例的示例页面结构定义。

图6D图示了根据示例实施例的示例函数定义。

图7A、7B、7C和7D图示了根据示例实施例的用于配置用于定制的自动化测试的混合脚本生成的用户界面。

图8图示了根据实施例的生成的混合脚本。

图9A图示了根据示例实施例的示例实现框架配置。

图9B图示了根据示例实施例的示例实现框架特性。

图9C图示了根据示例实施例的示例套件文件和套件结果。

图9D图示了根据示例实施例的示例定制的自动化测试结果。

图10A图示了根据示例实施例的套件级别结果网页。

图10B图示了根据示例实施例的详细的测试级别结果网页。

图10C图示了根据示例实施例的具有失败状态的示例测试结果。

图11A、11B、11C和11D图示了根据示例实施例的用于为另一个定制的自动化测试配置混合脚本生成的用户界面。

图12图示了根据示例实施例的用于实现可定制的企业自动化测试框架的流程图。

具体实施方式

实施例实现可定制的企业自动化测试框架。例如，企业可以具有web存在，诸如web应用或网站。不时地测试web存在可能是有益的，诸如以确保web应用或网站函数的各个部分均按预期执行。例如，可以在实现更改(例如，更新、加补丁等)时或者在任何其它合适的时间测试web存在。

这种测试在手动完成的情况下可能既费时又费钱。因而，可以使用自动化工具来提高测试效率。但是，此类自动化工具也需要配置，这本身可能会非常耗时。例如，不同版本的web存在可能要求进行定制的测试，或者出于各种原因，测试可能被定制为不同的版本。配置自动化工具来运行此类定制的测试可能导致重复的人工工作。

实施例实现了可定制的企业自动化测试框架，该框架提高了对web存在(例如，web应用或网站)执行自动化测试的效率和灵活性。例如，企业网站的定义可以用于生成混合脚本，可以对混合脚本进行解析以生成运行时脚本，并且自动化工具可以使用运行时脚本在企业网站上实现自动化测试。

在一些实施例中，定义可以包括工作流定义、页面结构定义和函数定义。例如，工作流定义可以定义包括要针对测试执行的一系列步骤的工作流。页面结构定义可以为企业网站的网页定义web元素。函数定义可以定义用于执行企业网站测试的特定于企业网站的函数(例如，由工作流的步骤调用的函数)。在一些实施例中，这些定义被存储在标记语言文档(例如，可扩展标记语言(“XML”)文档)中。

实施例可以(例如，使用混合脚本解析器)解析定义，以生成用于企业网站测试的混合脚本。混合脚本可以表示自动化测试的定制版本(例如，基于接收到的定义进行定制)。在一些实施例中，然后可以由自动化工具解析器解析混合脚本。例如，混合脚本可以被配置为与任何数量的自动化工具(例如，本领域普通技术人员可用的web存在测试自动化工具)一起工作。给定的自动化工具解析器可以被配置为生成可由特定自动化工具使用的输出。由此，混合脚本可以与不同的自动化工具解析器组合，并且这些各种组合可以用于通过各种不同的自动化工具来实现定制的测试。

在一些实施例中，自动化工具解析器的输出可以用于生成运行时脚本(例如，由与自动化工具解析器相关联的自动化工具使用以实现定制的测试)。例如，运行时脚本可以由自动化工具(例如，基于云的自动化工具)接收，然后该自动化工具在企业网站上实现运行时脚本中表示的定制的测试。这种实现生成可以在用户界面中接收和/或显示的测试结果。例如，测试结果可以包括工作流定义中定义的工作流和/或这些工作流之一的各个步骤的状态(例如，通过(Pass)、失败(Fail)、跳过(Skip))。

在许多情况下，本公开的实施例可以是有益的。例如，在企业打包的web应用中，通常会通过若干个定制(例如，根据每个客户请求实现)将产品交付给企业客户。另外，企业web存在可以有很多变体，因此一个企业网站或web应用可能与另一个相似，但由于定制而有所不同。

例如，定制可以包括以下中的一项或多项：(1)用于反映品牌的主题、颜色、字体、样式表；(2)访问功能的导航可能不同，因此导航可能涉及遍历更多或不同的网页/屏幕，以便访问该功能；(3)网页/屏幕上可见的元素可能在数量和/或次序上变化(例如，由于地理限制，对于一些实现，一些字段可能是必填字段，而对于一些其它实现，这些字段可能不显示在应用中)；(4)元素类型可能因实现方案而改变(例如，在一种变体中，元素类型可能对应于可自由编辑的字段，而在另一种变体中，它可能是单个选择组合列表、单选按钮或某种其它元素)；(5)一般而言，虽然在视觉上两个变体可能具有相似数量的字段/元素，但是由于定制，功能在两者之间可能略有不同。如各种实施例中所描述的，许多其它情况可以类似地受益于高效地实现可定制的自动化web测试的框架。

考虑常规测试自动化框架，实施例提供了益处。例如，通常基于图形用户界面(“GUI”)的web自动化脚本具有以下功能：

·基于浏览器的导航到期望的网页/web区段(section)；

·识别需要在其上执行动作的元素(例如，动作可以是我们预期脚本在web元素上执行的操作)；以及

·断言检查，以便确保脚本执行了预期的操作。

对于许多自动化脚本，通常考虑上述三个参数，但是当这些参数中的一个或多个改变时，脚本可能会失败。例如，在常规的实现中，通常编写自动化脚本(代码)来遍历网页/web框架、对网页中的元素执行动作、断言并最终报告。虽然这对于基于vanilla的实现(例如，没有用户界面或功能定制)可以工作，但是对于用户界面和/或功能从一种实现改变为另一种实现的变体，这些常规脚本通常会失败，因为它们不可扩展。

另一个挑战是这些自动化脚本通常与底层自动化工具紧密耦合，并且在一些实现中，当使用不同的自动化工具(例如，由不同的客户使用或在产品开发组织、实现组织和客户之间使用)时，无法重复使用脚本。但是，在许多情况下，客户自动化工具是不同的，并且没有跨客户使用的标准化自动化工具。在如此多种多样的工具的情况下，使用(例如，由所有客户使用的)每一个自动化工具来认证企业打包的web应用或网站的定制的实现将非常繁琐，或者至少将需要不必要的工作。

实施例实现未与底层自动化工具紧密集成的框架拓扑。例如，底层自动化工具将用于执行，但是可以通过将松散耦合的特定于自动化工具的框架解析器替换为与不同的自动化工具松散耦合的框架解析器来进行交换。在不同客户使用不同商业或开源自动化工具的情况下，常规自动化脚本变得不可用。

实施例实现了可定制的框架设计拓扑，该框架设计拓扑通过以下设计原理中的一个或多个减轻了现有问题。

·该框架可以例如基于公开的混合脚本概念和运行时脚本组合使用不同的底层自动化工具(商业或开源)来实现。

·生成的混合脚本不包括在脚本内硬编码的导航/断言/动作信息。例如，这些可以(例如，基于外部定义)生成并且可以诸如刚好在执行之前被修改。

·逻辑函数流可以以数据格式(例如，工作流定义)发布。例如，可以以XML格式来定义逻辑工作流，并且可以在任何文本编辑器中轻松修改函数步骤的排序，这然后可以产生脚本的定制版本。

·可以在其上执行动作/导航/断言并且可以在另一个数据结构(例如，页面结构定义)中发布的元素(例如，web元素)。这些元素可以被归类为页面和区段。

·框架的web界面组件可以读取这些文件(例如，XML文件)，并为用户提供为特定于实现的脚本选择定制的步骤的选项。另外，web界面的实施例允许用户录入测试件(testware)数据(例如，输入数据)以生成定制的实现。

·动作/断言/导航可以作为混合函数发布。例如，可以使用(例如，在标记语言文档中)对其定义函数操作的元素和数据的引用，而不是使用传统代码。这些函数可以在文件中定义(例如，函数定义)。在一些实施例中，运行时函数可以是特定于自动化工具的，并且可以基于这些混合函数来生成。

·企业打包的web应用或网站的实现的变体可以具有其自己的数据文件副本来定制的测试(例如，工作流定义、页面结构定义和函数定义)。

·混合脚本生成器可以读取这些文件以及从web界面输入的步骤和测试数据，以生成混合脚本。

·混合脚本可以是文本格式，其使得能够在执行之前轻松且快速地修改这些脚本，以进行数据修改、步骤次序更改、启用/禁用步骤执行等。

·用于该框架的报告引擎可以生成套件和测试级别结果文件(例如，XML文件)。在一些实施例中，web仪表板(dashboard)可以转换XML(例如，转换成HTML)并将其显示在web报告界面中。

基于这些特征中的一个或多个，可定制框架的实施例提供以下改进。鉴于混合脚本和特定于自动化工具的解析器，实施例可以与多个底层自动化工具(例如，商业或开源)一起工作。例如，一些实现利用两个脚本层(混合和运行时)，以便与底层自动化工具轻松耦合。另外，生成的混合脚本可以与客户共享，而无需共享生成它的代码。

在一些实施例中，混合脚本层是基于文本的，并且各种用户可以对其进行修改(例如，没有编码经验的用户)。在若干种情况下，可以在创建运行时函数之前生成混合脚本。在一些实施例中，网页元素、函数工作流和函数可以被定义为元数据格式(例如，在诸如标记语言文件的数据文件中)，从而导致更容易管理和鲁棒的脚本。例如，在元素特性或文档对象模型(“DOM”)改变的情况下，无需进行代码更改(例如，修改定义文件或在一些实施例中的XML文件就足够)。为了在一些必填字段和可选字段启用/禁用的情况下测试不同的场景，无需进行代码修改，修改生成的混合脚本就足够。

在一些实施例中，在定制的网页中的web元素的视觉排序改变的情况下，改变函数工作流(例如，工作流XML文件)的排序将足够。在一些实施例中，可以对框架进行调整以根据选择了什么动作来自动执行前提(pre-requisite)活动。这可以通过parent_page属性和dependent_action属性来实现(例如，在函数库XML中)。

在一些实施例中，虽然要执行的功能是定制的，但是用于不同定制测试(例如，针对企业网站的不同版本定制的测试)的函数名称在混合脚本中可以保持相同。在这种情况下，可以在运行时脚本级别实现定制。在这样的实现中，混合脚本维持可读性并且简化了其管理。

现在将详细参考本公开的实施例，其示例在附图中示出。在下面的详细描述中，阐述了许多具体细节以便提供对本公开的透彻理解。但是，对于本领域的普通技术人员将显而易见的是，可以在没有这些具体细节的情况下实践本公开。在其它情况下，未详细描述众所周知的方法、过程、组件和电路，以免不必要地混淆实施例的各个方面。只要有可能，相同的附图标记将用于相同的元素。

图1图示了根据示例实施例的用于实现可定制的企业自动化测试框架的系统。系统100包括特定于实现的定义102、解析器和脚本生成器104以及自动化工具106。在一些实施例中，特定于实现的定义102可以为将由自动化工具106实现的定制的测试提供定义，诸如针对包括用于测试的步骤的工作流的定义、针对要在其上运行定制测试的网页(例如，企业网站或web应用的网页)的页面结构的定义，以及由工作流的步骤调用的函数的定义。

在一些实施例中，解析器和脚本生成器104可以解析特定于实现的定义102以生成混合脚本。然后，可以使用混合脚本来生成运行时脚本，自动化工具106使用该运行时脚本来实现定制的测试。在各种实施例中，可以基于特定于实现的定义102来定制给定的测试。例如，一组给定的定义可以用于生成配置定制的测试的性能的混合脚本。当这组定义改变(例如，由用户编辑)时，生成的混合脚本也可能改变，因此自动化工具106实现了不同的定制的测试。在一些实施例中，用户界面还可以用于基于接收到的对在特定于实现的定义102中定义的工作流/步骤的编辑和/或对所生成的混合脚本的编辑来定制测试的实现。

图2是根据实施例的计算机服务器/系统200的框图。系统200的全部或部分可以用于实现图1中所示的任何元件。如图2中所示，系统200可以包括总线设备212和/或被配置为在系统200的各种组件(诸如处理器222和存储器214)之间传送信息的(一个或多个)其它通信机制。此外，通信设备220可以通过对要通过网络(未示出)从处理器222发送到另一个设备的数据进行编码以及通过网络从另一个系统接收的处理器222的数据进行解码来实现处理器222与其它设备之间的连接性。

例如，通信设备220可以包括被配置为提供无线网络通信的网络接口卡。可以使用各种无线通信技术，包括红外、无线电、蓝牙

Wi-Fi和/或蜂窝通信。替代地，通信设备220可以被配置为提供(一个或多个)有线网络连接，诸如以太网连接。

处理器222可以包括一个或多个通用或专用处理器，以执行系统200的计算和控制功能。处理器222可以包括单个集成电路，诸如微处理设备，或者可以包括协同工作以完成处理器222的功能的多个集成电路设备和/或电路板。此外，处理器222可以执行存储在存储器214内的计算机程序，诸如操作系统215、测试框架216和其它应用218。

系统200可以包括用于存储信息和由处理器222执行的指令的存储器214。存储器214可以包含用于检索、呈现、修改和存储数据的各种组件。例如，存储器214可以存储在由处理器222执行时提供功能的软件模块。这些模块可以包括为系统200提供操作系统功能的操作系统215。这些模块可以包括操作系统215、被配置为实现本文公开的定制的自动化测试和其它功能的测试框架216、以及其它应用模块218。操作系统215为系统200提供操作系统功能。在一些情况下，测试框架216可以被实现为存储器中配置。在一些实现中，当系统200执行测试框架216的功能时，它实现执行本文公开的功能的非常规专用计算机系统。

非暂态存储器214可以包括可以由处理器222访问的各种计算机可读介质。例如，存储器214可以包括随机存取存储器(“RAM”)、动态RAM(“DRAM”)、静态RAM(“SRAM”)、只读存储器(“ROM”)、闪存、高速缓存存储器和/或任何其它类型的非瞬态计算机可读介质的任何组合。处理器222还经由总线212耦合到显示器224，诸如液晶显示器(“LCD”)。键盘226和光标控件设备228(诸如计算机鼠标)还耦合到通信设备212以使用户能够与系统200对接。

在一些实施例中，系统200可以是较大系统的一部分。因此，系统200可以包括一个或多个附加函数模块218以包括附加功能。其它应用模块218可以包括例如

云基础设施、

云平台、

云应用的各种模块。测试框架216、其它应用模块218和系统200的任何其它合适的组件可以包括各种Java模块和/或MySQL的模块以及其它合适的框架/服务。

数据库217耦合到总线212，以便为模块216和218提供集中存储，并存储例如用于测试框架216的数据或其它数据源。数据库217可以将数据存储在逻辑上相关的记录或文件的集成集合中。数据库217可以是操作数据库、分析数据库、数据仓库、分布式数据库、最终用户数据库、外部数据库、导航数据库、存储器中数据库、面向文档的数据库、实时数据库、关系数据库、面向对象的数据库、非关系数据库、NoSQL数据库、

分布式文件系统(“HFDS”)或本领域已知的任何其它数据库。

虽然被示出为单个系统，但系统200的功能可以被实现为分布式系统。例如，存储器214和处理器222可以分布在共同表示系统200的多个不同计算机上。在一个实施例中，系统200可以是设备(例如，智能电话、平板电脑、计算机等)的一部分。在实施例中，系统200可以与设备分离，并且可以远程地为设备提供所公开的功能。另外，可以不包括系统200的一个或多个组件。例如，对于作为用户或消费者设备的功能，系统200可以是智能电话或包括处理器、存储器和显示器，不包括图2中所示的一个或多个其它组件，以及包括图2中未示出的附加组件(诸如天线、收发器或任何其它合适的无线设备组件)的其他无线设备。另外，当被实现为执行本文中公开的功能时，系统200是专门适于提供定制的和自动化的测试功能的专用计算机。

图3图示了根据示例实施例的用于实现可定制的企业自动化测试框架的另一个系统。图3所示的系统包括工作流定义302、页面结构定义304、实现函数库306、实现框架特性308、实现框架配置310、框架模块312、自动化工具314、框架接口316、解析器318、报告引擎320、执行引擎322、混合脚本解析器324、特定于自动化工具的解析器326、运行时脚本生成器328、外部测试数据330、通用函数库332、实现套件文件334、web自动化工具336、测试执行模块338、套件结果340和测试结果342。在一些实施例中，图3所示的系统的组件可以用于为企业web应用(例如，企业网站)和/或企业web应用的不同版本实现定制的自动化的测试。

例如，图4A、4B、5A和5B图示了企业web应用的版本。图4A的用户界面402描绘了用于预订航班的第一航空公司web应用的登陆页面，并且图5A的用户界面502描绘了用于预订航班的第二航空公司web应用的登陆页面。例如，用户界面402和502可以用于使用输入到所描绘的web元素中的参数来搜索航班。类似地，图4B的用户界面406描绘了第一航空公司web应用的航班结果页面，而图5B的用户界面506描绘了第二航空公司web应用的航班结果页面。

在一些实施例中，第一航空公司web应用和第二航空公司web应用可以是公共航空公司web应用的不同变体。例如，web应用提供商/主机可以维护可以被定制的公共航空公司web应用，并且第一航空公司web应用和第二航空公司web应用可以是该公共航空公司web应用的不同定制版本。但是，这仅仅是示例，并且第一航空公司web应用和第二航空公司web应用也可以不共享该公共性(例如，不共享公共web应用)。实施例演示了框架如何能够高效地为这两个定制的企业应用实施定制的和自动化的测试。

图4A的用户界面402描绘了示例登录页面，其中默认情况下，航班标签被启用。在这个示例中，有单选按钮用于选择单程/往返行程，并且默认情况下它被设置为单程，并且有六个字段，即出发城市、到达城市、web元素404出发日期、乘客和货币。在这个示例中，乘客字段默认被设置为“1个成人”，并且货币字段默认被设置为“INR”。当点击搜索图标时，企业web应用基于匹配标准来检索航班。在图4B的用户界面406处，用户可以选择航班号和航班等级，并且点击继续以登录到乘客详细信息页面上。

图5A的用户界面502描绘了登陆页面，其中默认情况下，显示预定航班。在这个示例中，有三个单选按钮：单程/往返/多城市(代替图4A的用户界面402中所示的两个单选按钮)，并且默认情况下设置为单程。与图4A的用户界面402相似，用户界面502具有六个字段，即出发城市、到达城市、乘客、出发日期和货币。但是，存在若干个偏差(例如，定制的改变)，这些偏差使得不允许为一种实现编写的典型自动化脚本对于另一种实现成功运行(并且在一些情况下，用于变体的脚本将从头开始编写)。例如，当将图4A的用户界面402与图5A的用户界面502进行比较时，可以看到以下变化：

·乘客字段被显示在出发日期字段之前。

·时刻数据被自动录入到一个字段中，下一个字段的内容显示如下。

·存在web元素类型差异(例如，用户界面402中的乘客字段是简单的单选下拉列表，而它是如用户界面502的小部件504所示的复杂的小部件)。

·元素的内部DOM特性也可以不同。例如，对于用户界面402，可以使用“id”属性来识别web元素。同时，对于用户界面502，可以使用“xpath”属性来识别许多web元素。

与图4B的用户界面406相似，在图5B的用户界面506上，用户可以选择航班号和航班等级，并且点击继续以登录到乘客详细信息页面上。实施例使用图3所示的系统的元素针对web应用的这些变体实现定制的自动化测试。

在一些实施例中，工作流定义302定义一个或多个工作流，其可以是一系列步骤，这些步骤一起生成用于企业web应用的测试用例/工作流。图6A图示了示例工作流定义602。

在一些实施例中，企业web应用的每个定制的版本将具有其自己的工作流定义602的版本(虽然可以共享若干个定义)。该文件(例如，元数据、标记语言和/或XML文件)定义了测试用例的函数工作流的详细信息以及每个工作流中涉及的步骤。

在一些实施例中，工作流定义602中的每个步骤标签具有名为“action_method”的属性，该属性列出了将被调用以执行该步骤的函数的相对名称。如本文进一步公开的，可以在特定于实现的函数定义中列出该函数采用的详细自变量。“action_on_elem”属性是另一个属性，它是指要对其执行动作的web元素。在这个示例中，web元素在作为<page>.<section>.<element name>的命名法(nomenclature)中列出。

在一些实施例中，关于web元素的详细信息可以在特定于实现的页面结构定义中找到，如本文所公开的。“desc”属性可以列出步骤的描述，该步骤的描述可以显示在web界面中(例如，用于创建混合脚本)。如本文所公开的，工作流定义602中列出的功能可以作为用户可以选择以创建混合脚本的步骤而显示在框架web界面中。

图6B图示了用于搜索航班的示例工作流604。例如，工作流604可以是图6A的工作流定义602的一部分，即“搜索一个乘客的单程航班而不选择任何附加项”工作流。在这个示例中，列出了七个步骤：

步骤1：选择行程类型选项“单程或往返”

步骤2：选择/录入飞行“来自(from)”地点

步骤3：选择/录入飞行“去往(to)”地点

步骤4：从web日历中选择出发日期

步骤5：选择要飞行的乘客数量

步骤6：选择用于购买机票的货币

步骤7：点击航班搜索按钮以基于这些参数获取可用航班的列表。

图6C图示了页面结构定义606(例如，图3的页面结构定义304)。页面结构定义606(例如，元数据、标记语言和/或XML文件)可以在定制的企业web应用上定义web元素(例如，定制的自动化测试将在其上进行导航、动作和断言)。在这个示例中，使用网页和区段来构造元素。

在一些实施例中，每个变体(例如，定制的实现)可以包括其自己的页面结构定义606的版本。web元素可以具有“name(名称)”属性，该属性可以是唯一的，并且在一些示例中，可以由工作流定义文件和/或函数定义文件引用。示例“locator_type”属性可以定义web元素的DOM特性，通过该特性可以在页面中唯一识别该元素。示例“locator_value”属性可以列出“locator_type”属性的值。

对于在实现自动化定制测试时引用的web元素，混合脚本生成器可以参考页面结构定义606以获取web元素的详细信息。然后可以将其传递给底层自动化工具以进行识别。在一些实施例中，如果设想了新的自动化工具(例如，寻找DOM的唯一特性以识别元素的自动化工具)，那么可以将该特性作为属性添加到页面结构定义606，并且可以提供对应的值。

图6D图示了示例函数定义610(例如，图3的函数定义306)。函数定义610(例如，元数据、标记语言和/或XML文件)可以定义用于实现自动化测试的定制版本的特定于实现的函数(例如，在执行测试中由工作流步骤调用)。例如，可以将动作、导航和断言转换成函数，并且可以在函数定义610中定义详细信息。例如，函数612定义函数select_depart_date。

在一些实施例中，函数还可以被构造成用于识别、添加和/或修改的页面和区段。在这个示例中，函数标签可以具有“desc_name”属性，该属性可以是函数的名称。示例“type(类型)”属性可以识别函数导航/断言等的类型。示例“signature(签名)”属性可以指定函数接受的自变量。例如，考虑函数定义608中“导航”函数“select_depart_date”的签名。

signature＝"select_depart_date('ps:landing_page.default.depart','ps:landing_page.default.depart_calendar_month_label','ps:landing_page.default.depart_calendar_year_label','ps:landing_page.default.depart_calendar_table','ps:landing_page.default.depart_calendar_next_month','data_user_form:fw:search_one_way_flight.deptart_date')

在这个示例中，第一个自变量是“ps:landing_page.default.depart”。这里，“ps”可以表示“页面结构”，并且“landing_page.default.depart”可以是web元素的唯一标识符。可以从页面结构定义(例如，图6C的页面结构定义606)中获得web元素“landing_page.default.depart”的详细信息，该详细信息将为：

<element elem_name＝"depart"locator_type＝"id"

locator_value＝"ctl00_mainContent_view_date1"img＝""

visible_label＝"DEPART DATE"type＝"static"

action_supported＝"click,calendar_select()"

default_visibility＝"true"></element>

在这个示例中，自变量“data_user_form:fw:search_one_way_flight.deptart_date”具有两个部分。第一部分“data_user_form”可以指示该函数接受来自框架网页(例如，如本文所公开的，来自小部件“创建自动化测试”)的测试数据。在这个示例中，在第二部分“fw:search_one_way_flight.depart_date”中，“fw”是指工作流定义(例如，图6A的工作流定义602)，并且“:”之后的字符串可以指示如在工作流定义中的函数名称“search_one_way_flight”下找到的web元素“depart_date”的名称(如图6A的工作流定义602中所示)。

框架的实施例包括表单、网页、网站、web应用、仪表板或任何其它合适的web实体，诸如图3的框架界面316，其可以用于基于所公开的定义(例如，工作流定义、页面结构定义和函数定义)配置混合脚本。图7A、7B、7C和7D图示了用于为定制的自动化测试配置混合脚本生成的用户界面。用户界面702可以包括可以用于选择工作流的web元素704、可以将所选择的工作流的步骤显示为web元素的web元素706、以及可以作为用于为所选择的工作流录入测试出发日期的可编辑字段的web元素708。

实施例包括作为web界面的用户界面702，用于根据定制的自动化测试定义和通过用户界面接收到的输入来配置和创建混合脚本。在一些实施例中，可以提供定制的自动化测试名称、URL和混合脚本路径以便生成界面。

图7B图示了web元素704，该web元素704被描绘为下拉菜单，该下拉菜单由工作流根据工作流定义(例如，图6A的工作流定义602)填充。例如，web框架可以自动检索对应的工作流定义、解析文件并在“业务用例”下拉列表中将工作流作为选项列出。在选择工作流之后，可以在用户界面702中显示步骤(如在工作流定义中定义的)。在一些实施例中，web界面可以执行AJAX调用以便检索/显示所选择的工作流的相关步骤。例如，返回到图7A，web元素706将所选择的工作流的步骤(例如，搜索一个乘客的单程航班而不选择任何附加项)显示为单独的web元素。

在一些实施例中，可以按照工作流定义所表示的顺序来显示步骤，并且当与字段对应的步骤是接收输入的步骤时，某些字段是可编辑的。对于用户界面702的用户未提供输入数据的那些步骤，显示不可编辑的web元素。对于期望用户录入输入数据的那些步骤，显示可编辑的web元素，诸如web元素708。例如，当录入/显示“action_method”函数具有以“data_user_form”开头的自变量的步骤时，可以在用户界面702中动态地呈现编辑框，以捕获针对混合脚本的用户输入。

例如，界面702图示了与所选择的工作流步骤对应的七个示例字段。这七个示例字段通过图7C的web元素706显示。在这七个字段中，“点击单程”和“点击搜索”被显示为只读。其余五个字段，即“来自”、“去往”、“出发日期”、“乘客数量”和“货币”，允许用户录入数据。在这些字段中录入了“MUMBAI”、“DELHI”、“2018年9月29日”和“INR”的值。在这个示例中，没有在乘客字段中录入值，因为正在测试的对应企业web应用将自动选择默认乘客为1个。

在实施例中，配置用于生成混合脚本的工作流的步骤可以被认为是混合脚本生成的步骤。一旦配置了第一所选择的工作流，就可以使用用户界面702的“添加步骤”按钮(例如，如图7B所示，从下拉菜单中)选择另一个工作流。图7D图示了第二所选择的工作流的步骤，即“基于航班号和等级来选择航班”。

图7D的web元素710描绘了四个字段(例如，对应于在图6A的工作流定义602中为所选择的工作流定义的4个步骤)。在这个示例中，前两个字段可以用于录入航班号和航班等级，并且其余两个字段是不可编辑的。使用图7A、7B、7C、7D中所描绘的上述动作序列，可以为混合脚本生成组件创建两个脚本步骤(例如，对应于两个所选择的工作流以及根据工作流的步骤所对应的输入信息)。

在一些实施例中，在使用界面702配置混合脚本之后，混合脚本可以由web框架生成。图8图示了根据实施例的生成的混合脚本。例如，用户界面802显示混合脚本804，该混合脚本804可以包括使用用户界面702配置的可定制的自动化测试的表示(例如，所选择的工作流和工作流的配置步骤)。

在一些实施例中，混合脚本生成器/解析器(例如，图3的混合脚本解析器324)可以解析相关定义(例如，图6A的工作流定义602、图6C的页面结构定义606和图6D的函数定义610)以生成混合脚本内容。例如，混合脚本解析器324可以负责解析特定于实现的定义文件并生成混合脚本(例如，基于用户从web界面和框架配置中选择的数据)。混合脚本是专门针对企业打包的web应用的定制的实现而生成的。

在一些实施例中，混合脚本解析器可以是唯一的解析器算法(例如，使用JAVA开发的)。例如，混合脚本解析器可以生成特定于实现的混合脚本。在一些实施例中，混合脚本解析器可以解析定义文件(例如，图6A的工作流定义602、图6C的页面结构定义606以及图6D的函数定义610)。可以以这种方式设计这些定义，使得可以交叉引用它们，以使框架可以对实现进行全面的了解。例如，可以使用(例如，标记定义文件的)标签和属性来实现交叉引用。

在一些实施例中，使用web界面(例如，如图7A、7B、7C和7D所示)执行混合脚本生成。例如，一旦用户(例如，使用图7B的元素704)选择了工作流，就可以发起混合脚本解析器。混合脚本解析器可以解析工作流定义以检索所选择的工作流的步骤。为了获取步骤中遇到的元素的详细信息，它可以解析页面结构定义。然后，对于动作(例如，定义内的action_method)，解析器可以引用函数定义以获取详细的函数调用。

在图8所示的示例中，前缀“EXEC_LINE”指示在实现脚本时是否要执行行(line)。默认情况下，混合脚本内容中的行可以设置为“TRUE(真)”。如果设置为“FALSE(假)”，那么在执行时将跳过对应的行。

混合脚本804包括方法调用，这些方法调用是标准方法，并且可以跨各种实现使用(例如，从语言“default_”开始)。例如，可以维护可以跨多个定制/实现工作的公共库(例如，公共函数库332)。例如，这些公共方法可以与在函数定义(例如，图6D的函数定义610)中定义的特定方法不同。在一些实施例中，函数定义是分开的，并且针对各个定制进行维护以包括定制的方法/函数。

例如，在混合脚本804中，行806包括函数“选择出发日期”，这是在函数定义中为与该混合脚本/定制的自动化测试相关联的特定定制定义的特定函数。混合脚本804还包括函数“select_preferred_flight”，该函数对于不同的企业web应用/定制可以不同。例如，图4A和5A描绘了不同的企业web应用，因此每个应用可以具有其自己的一组定义，该组定义被解析以生成混合脚本(以及后续的运行时脚本)。因此，虽然这两种实现可以在混合脚本中使用相同的方法名称，但是在运行时，将使用函数库中与实现/定制对应的“select_preferred_flight”方法。

在一些实施例中，对于包括“data_user_form”的函数调用中的参数，它们框架期望用户从web界面表单录入的数据(例如，诸如图7A的元素706和708)。在一些实施例中，可以由混合脚本解析器针对在web界面中录入的各种工作流步骤重复该解析功能。然后，混合脚本解析器可以生成基于定制的文本的命名法(例如，图8的混合脚本804所示)。

在一些实施例中，对于期望用户手动录入数据的表单，可以从外部测试数据储存库(例如，图3的外部测试数据330)获得该数据。在这种情况下，代替录入数据，可以录入混合脚本解析器可以解释的“db:<sql_file_name>”之类的命名法。例如，混合脚本解析器可以确定对数据库执行查询(例如，SQL查询)，并且结果集可以是要使用的数据(例如，表单值)。还可以进行类似的配置以从其它格式(例如，工作表，诸如Excel工作表、XML格式等)检索数据。

在一些实施例中，对于每个实现/定制，存在特定于实现的框架配置文件(例如，图3的实现框架配置310)。图9A图示了示例实现框架配置902。例如，实现框架配置902可以包括要运行的套件、要使用的自动化工具等的详细信息。如所显示的，所示示例中的自动化工具(例如，图3的自动化工具314)是Selenium，但是，由于框架与底层的自动化工具松散耦合，因此可以定义任何开源、商业或任何其它合适的自动化工具。示例“suite_to_exec”标签具有特定于实现的要执行套件的详细信息。

在一些实施例中，对于每个实现/定制，存在特定于实现的框架参数文件(例如，图3的实现框架特性308)。图9B图示了示例实现框架特性904。例如，实现框架特性904可以包括关于定义/定制将支持的实现的详细信息。框架可以参考该文件以获取特定于实现的详细信息。例如，图4A和5A中所示的企业web应用都在实现框架特性904中列出。图9C图示了示例实现套件文件334。实现套件文件334可以包括要执行的混合脚本的详细信息。该文件中可以列出多个脚本。

再次参考图3，然后可以处理所生成的混合脚本(例如，通过特定于自动化工具的解析器326和运行时脚本生成器328)以生成运行时脚本。例如，特定于自动化工具的解析器326解析特定于自动化工具的本机方法和混合脚本，以便生成要由运行时脚本生成器使用的临时格式。运行时脚本生成器328采用临时格式(由特定于自动化工具的解析器326传递)以及函数库中定义的特定于定制业务的自动化方法，并生成可以使用特定自动化工具执行的运行时脚本。

在一些实施例中，特定于自动化工具的解析器326与函数定义(例如，图6D的函数定义610)串联操作，以便提出临时运行时脚本格式。例如，混合脚本可以具有方法名称，诸如“default_click”，并且框架可以理解前缀“default”指示任何自动化工具的标准本机点击方法都应当用于该动作。然后，特定于自动化工具的解析器326可以将该default_click方法转换成特定于工具的点击格式。在自动化工具为Selenium的示例中，混合脚本行:“default_click(id:ct100_mainContent_rbtnl_Trip_0”可以被转换成特定于Selenium的代码“driver.findElement(By.id(“ct100_mainContent_rbtnl_Trip_0”)).click()；”。

在一些实施例中，当方法不是本机方法时，框架可以查看函数定义以确定该方法是否被声明并将其用于运行时执行。使用该信息，特定于自动化工具的解析器326可以生成特定于要使用特定工具执行的(例如，自动化工具所支持的)编程语言的结构化脚本。在一些实施例中，运行时脚本生成器允许在脚本被执行之前对脚本进行最后一级的定制和最后一级的加强。

返回参考图3，在一些实施例中，自动化工具314和执行引擎322进行通信并执行所生成的运行时脚本(例如，使用web自动化工具336和测试执行模块338)，以从定制的自动化测试的执行中生成结果。结果可以包括套件结果、各个工作流结果和/或工作流结果中的各个步骤，其中结果可以指示相关状态(例如，通过、失败、跳过等)。在一些实施例中，结果可以作为可以以web格式(例如，HTML)处理和渲染的文件(例如，标记语言和/或XML文件)(例如，从自动化工具)生成。

例如，图9C图示了示例套件结果906(例如，图3的套件结果340)。套件结果906示出了套件级别的执行状态。例如，如果套件中的所有测试均通过，那么套件执行状态为“PASS(通过)”。实施例还包括更细粒度级别的结果(例如，测试结果342)。

例如，图9D图示了示例测试结果908。测试结果908示出了(例如，工作流)的每个步骤的执行状态和事件级别(例如，步骤内的子步骤)。例如，可以在函数库代码级别指定事件。在一些实施例中，如果步骤中的所有事件都通过，那么步骤执行状态被设置为“PASS”。在一些实施例中，当所有步骤的执行状态(除跳过的步骤外)都被设置为“PASS”时，将测试执行状态设置为“PASS”。

在一些实施例中，框架web报告引擎(例如，图3的报告引擎320)解析套件和测试结果，并以HTML格式显示它们。在一些实施例中，框架web层可以在Linux平台中实现，而测试执行可以在Windows平台中进行。这里，套件和测试结果文件可以在Windows中生成，然后可以(例如，使用框架web界面“上传报告”)被上传到Linux。例如，一旦报告被上传，就可以通过点击“查看报告”来查看结果。在一些实施例中，在“录入结果文件路径”字段中，指定报告被上传到的Linux文件夹。报告引擎可以检查文件夹并识别结果文件(例如，XML文件)。

图10A图示了套件级别结果网页。用户界面1002显示套件结果1004(例如，显示的测试为“通过”)。可以选择图示的单选按钮以进一步探索结果。图10B图示了详细的测试级别结果网页。用户界面1006包括显示(例如，用于测试的工作流)的相关步骤的结果的web元素1008，并且可以选择这些步骤中的一个或多个，使得web元素1010在所选择的步骤中示出事件级别执行状态。

图10C图示了具有失败状态的示例测试结果。用户界面1012包括web元素1014，该web元素1014包括具有失败状态的多个步骤(例如，在选择的优选飞行中，步骤8)。日志文件还可以指示发生失败的原因，例如由于未能按时渲染页面而导致该步骤和后续步骤失败。

在一些实施例中，框架可以被配置为取决于选择了什么动作来自动执行前提活动。这可以通过parent_page属性和dependent_action属性来实现(例如，在函数库XML中)。例如，从(例如，用于生成混合脚本的)web界面中，如果用户不是添加搜索航班的步骤详细信息，而是添加用于从搜索结果中选择航班的步骤详细信息，那么在混合脚本中可以生成以下示例行：

“EXEC_LINE＝TRUE##select_preferred_flight(id:availabilityTable0,xpath:ControlGroupSelectView_AvailabilityInputSelectionView_RadioButtonMkt1Fare,DA158,DAMAX)”

当解析该行时，框架可以引用函数库定义，并且在这里它可以找到select_preferred_flight的依赖动作是“fw:search_one_way_flight”(如图6D所示)。在一些实施例中，框架认识到将要执行一些前提动作，并且为此框架可以引用函数工作流定义(如图6B所示)。例如，工作流定义可以包括search_one_way_flight工作流的步骤，并且可以在调用“select_preferred_flight”动作之前使用定义中包含的默认数据来执行这些步骤。

实施例包括针对多个web应用的定制的自动化测试。这里，图6A、6B、6C、6d、7A、7B、7C、7D、8、9A、9B、9C、9D、10A、10B和10C图示了针对图4A中所示的web应用的定制的测试实现。图11A、11B、11C和11D图示了用于配置用于另一个定制的自动化测试(即为图5A中所示的企业web应用定制的测试)的混合脚本生成的用户界面。

例如，由于框架的改进设计，这些定制测试的实施例可以是相似的。但是，每个定制的自动化测试都可以具有其自己的一组定义(例如，工作流定义、页面结构定义和函数定义)。这些定义中存在的定制可以产生混合脚本、函数库，并最终产生针对给定实现进行定制的运行时脚本。

例如，图11A图示了用户界面1102，该用户界面1102可以用于指定特定于定制的自动化测试的实现名称、URL和脚本路径。图11B的用户界面1104图示了所选择的工作流的步骤，即“搜索一个乘客的单程航班而不选择任何附加项”(例如，与参考先前企业web应用的定制的测试所讨论的工作流相似的工作流)。

但是，web元素1106图示了当前工作流的步骤，并且基于该企业web应用的定义(例如，工作流定义)，录入了乘客计数。实际上，基于工作流定义中的差异，这些步骤可能看起来与该类似工作流的先前实现不同。图11C图示了由用户配置产生的混合脚本1108和1010。

在一些实施例中，可以对生成的混合脚本进行编辑，例如以调整所生成的运行时脚本并改变自动化测试的执行。在示例中，可以跳过行1(默认情况下单选按钮选择为“单向”)和行6(因为默认情况下货币也设置为INR)。为了跳过这两个步骤，可以将EXEC_LINE标志设置为“FALSE”，如混合脚本1108中所示。

在一些实施例中，可以请求测试场景，其基于默认设置检查第二天的航班可用性。在这种情况下，可以修改混合脚本以设置步骤5的EXEC_LINE＝FALSE，如混合脚本1110所示。图11D图示了这种修改的测试级别结果。如从显示在用户界面1112中的报告显而易见的，测试已通过，并且由于EXEC_LINE被设置为FALSE，因此跳过了步骤5和6。

图12图示了根据示例实施例的用于实现可定制的企业自动化测试框架的流程图。在一个实施例中，图12的功能由存储在存储器或其它计算机可读或有形介质中的软件实现，并由处理器执行。在其它实施例中，每个功能可以由硬件执行(例如，通过使用专用集成电路(“ASIC”)、可编程门阵列(“PGA”)、现场可编程门阵列(“FPGA”)等)，或者由硬件和软件的任何组合执行。在实施例中，图12的功能可以由图2的系统200的一个或多个元件执行。

在1202处，接收用于企业网站的自动化测试的工作流定义、页面结构定义和函数定义。例如，工作流定义可以为包括一系列步骤的一个或多个测试用例定义一个或多个工作流，页面结构定义可以定义包括企业网站的多个网页的web元素，并且函数定义可以定义由一个或多个工作流的步骤引用的特定于企业网站的函数。例如，工作流定义、页面结构定义和函数定义可以是标记语言文档，诸如XML文档。在实施例中，一个或多个工作流的步骤包括在不同企业网站之间共享的默认函数以及在函数定义中定义的特定于与函数定义相关联的企业网站的特定于企业网站的函数。

在1204处，可以基于定义来显示用户界面。例如，可以显示用于配置混合脚本的生成的用户界面。在一些实施例中，可以选择一个或多个工作流，使得可以为企业网站生成定制的自动化测试。

在1206处，可以经由用户界面从用户接收用于定制的自动化测试的输入。在实施例中，用户可以选择用于测试的一个或多个工作流。可以诸如通过在与步骤对应的字段中接收输入的值来配置一个或多个工作流的步骤，其中这些值在测试的执行中使用。

在实施例中，可以显示由工作流定义配置的用于所选择的工作流的用户界面，其中可以基于所选择的工作流的步骤在配置的用户界面中动态显示多个界面元素。例如，可以接收由特定于企业网站的函数之一使用的输入数据，其中当自动化工具实现一个或多个工作流的步骤时，实现包括调用一个特定于企业网站的函数、以及使用输入数据生成自动化测试的结果的步骤中的至少一个。在实施例中，在用户界面上显示的用于一个步骤的用户界面元素被配置为从用户接收输入数据。在实施例中，基于用于工作流定义的异步JavaScript和XML(AJAX)调用来配置用户界面。

在1208处，混合脚本解析器解析工作流定义、页面结构定义和函数定义，以生成用于自动化测试的混合脚本。例如，可以基于经由用户界面接收的工作流选择和输入来生成混合脚本。在实施例中，由混合脚本解析器生成的混合脚本使用特定于企业网站的函数和输入数据中的一者来实现步骤。

在实施例中，混合脚本被配置为由多个自动化工具解析器解析以生成输出，每个自动化工具解析器与不同的自动化工具相关联，并且基于来自每个自动化工具解析器的输出的运行时脚本被配置为由不同的自动化工具使用，以生成自动化测试的结果。

在实施例中，一个或多个工作流的步骤包括在不同企业网站之间共享的默认函数以及在函数定义中定义的特定于与函数定义相关联的企业网站的特定于企业网站的函数。在这个示例中，混合脚本可以包括在不同企业网站之间共享的默认函数以及在函数定义中定义的特定于与函数定义相关联的企业网站的特定于企业网站的函数。

在1210处，可以接收对生成的混合脚本的编辑。例如，可以经由用户界面为混合脚本接收改变运行时脚本并最终改变自动化测试的执行的编辑。该编辑可以包括对指示跳过工作流的一个或多个步骤的标志的编辑。

在1212处，自动化工具解析器可以解析混合脚本以生成自动化工具的输出。在实施例中，由自动化工具解析器进行的解析可以包括解析经编辑的混合脚本以生成输出。

在1214处，基于自动化工具解析器的输出，可以生成运行时脚本，该运行时脚本由自动化工具执行以生成自动化测试的结果。例如，自动化工具可以在企业网站的多个网页上实现一个或多个工作流的步骤，以生成自动化测试的结果。

在实施例中，基于来自自动化工具解析器的输出生成运行时脚本可以包括生成运行时脚本，该运行时脚本由自动化工具执行以生成自动化测试的结果，并且自动化工具可以基于对混合脚本的编辑在企业网站的多个网页上实现一个或多个工作流的步骤，以生成自动化测试的结果。例如，经编辑的混合脚本可以导致针对企业网站的定制的自动化测试。

实施例实现了可定制的企业自动化测试框架，该框架提高了对web存在(例如，web应用或网站)执行自动化测试的效率和灵活性。例如，可以将企业网站的定义用于生成混合脚本、可以对混合脚本进行解析以生成运行时脚本，并且自动化工具可以使用运行时脚本在企业网站上实现自动化测试。

在一些实施例中，定义可以包括工作流定义、页面结构定义和函数定义。例如，工作流定义可以定义包括要针对测试执行的一系列步骤的工作流。页面结构定义可以为企业网站的网页定义web元素。函数定义可以定义用于执行企业网站测试的特定于企业网站的函数(例如，由工作流的步骤调用的函数)。在一些实施例中，这些定义存储在标记语言文档(例如，XML文档)中。

实施例可以解析定义(例如，使用混合脚本解析器)，以生成用于企业网站测试的混合脚本。混合脚本可以表示自动化测试的定制版本(例如，基于接收到的定义进行定制)。在一些实施例中，然后可以由自动化工具解析器来解析混合脚本。例如，可以将混合脚本配置为与任何数量的自动化工具(例如，本领域普通技术人员可用的web存在测试自动化工具)一起工作。可以将给定的自动化工具解析器配置为生成可由特定自动化工具使用的输出。由此，混合脚本可以与不同的自动化工具解析器组合，并且这些各种组合可以用于通过各种不同的自动化工具来实现定制的测试。

在一些实施例中，自动化工具解析器的输出可以用于生成运行时脚本(例如，由与自动化工具解析器相关联的自动化工具使用以实现定制的测试)。例如，运行时脚本可以由自动化工具(例如，基于云的自动化工具)接收，然后该自动化工具在企业网站上实现运行时脚本中表示的定制的测试。这种实现生成测试结果，该测试结果可以在用户界面中被接收和/或显示。例如，测试结果可以包括工作流定义中定义的工作流和/或这些工作流之一的各个步骤的状态(例如，通过、失败、跳过)。

贯穿本说明书描述的本公开的特征、结构或特性可以在一个或多个实施例中以任何合适的方式组合。例如，在整个说明书中，“一个实施例”、“一些实施例”、“某个实施例”、“某些实施例”或其它类似语言的使用是指结合实施例描述的特定特征、结构或特性可以被包括在本公开的至少一个实施例中的事实。因此，贯穿本说明书出现的短语“一个实施例”、“一些实施例”、“某个实施例”、“某些实施例”或其它类似语言不一定都指代相同的一组实施例，并且所描述的特征、结构或特性可以在一个或多个实施例中以任何合适的方式被组合。

本领域普通技术人员将容易理解，如上所讨论的实施例可以以不同顺序的步骤和/或在配置中用与所公开的元件不同的元件来实践。因此，虽然本公开考虑了概述的实施例，但是对于本领域技术人员显而易见的是，某些修改、变化和替代构造将是显而易见的，同时保持在本公开的精神和范围内。因此，为了确定本公开的范围和界限，应该参考所附权利要求。

Claims (20)

1.一种用于实现可定制的企业自动化测试框架的方法，所述方法包括：

接收用于企业网站的自动化测试的工作流定义、页面结构定义和函数定义，其中所述工作流定义为包括一系列步骤的一个或多个测试用例定义一个或多个工作流，所述页面结构定义定义包括企业网站的多个网页的web元素，并且所述函数定义定义由所述一个或多个工作流的步骤引用的特定于企业网站的函数；

由混合脚本解析器解析所述工作流定义、所述页面结构定义和所述函数定义，以生成用于自动化测试的混合脚本；

由自动化工具解析器解析混合脚本，以生成自动化工具的输出；以及

基于来自所述自动化工具解析器的输出来生成运行时脚本，所述运行时脚本由所述自动化工具执行以生成自动化测试的结果，其中所述自动化工具在企业网站的所述多个网页上实现所述一个或多个工作流的步骤，以生成自动化测试的结果。

2.如权利要求1所述的方法，还包括：

从用户接收对工作流中的一个或多个工作流的选择，其中所述混合脚本解析器基于工作流的选择来生成混合脚本。

3.如权利要求2所述的方法，其中所述工作流定义、所述页面结构定义和所述函数定义各自包括标记语言文档。

4.如权利要求3所述的方法，其中所述标记语言文档是可扩展标记语言(XML)文档。

5.如权利要求2所述的方法，还包括：

从用户接收由特定于企业网站的函数中的第一特定于企业网站的函数使用的输入数据，其中当所述自动化工具实现所述一个或多个工作流的步骤时，实现步骤中的至少一个步骤包括调用所述第一特定于企业网站的函数以及使用所述输入数据以生成自动化测试的结果。

6.如权利要求5所述的方法，其中由所述混合脚本解析器生成的混合脚本使用所述第一特定于企业网站的函数和所述输入数据来实现所述一个步骤。

7.如权利要求2所述的方法，还包括：

显示由所述工作流定义配置的所选择的工作流的用户界面，其中多个界面元素基于所选择的工作流的步骤而动态显示在所配置的用户界面中。

8.如权利要求7所述的方法，其中在所述用户界面上显示的用于所述一个步骤的用户界面元素被配置为从用户接收输入数据。

9.如权利要求8所述的方法，其中所述用户界面是基于针对所述工作流定义的异步JavaScript和XML(AJAX)调用而配置的。

10.如权利要求2所述的方法，其中所述混合脚本被配置为被多个自动化工具解析器解析以生成输出，每个自动化工具解析器与不同的自动化工具相关联，并且基于来自每个自动化工具解析器的输出的运行时脚本被配置为由不同的自动化工具使用，以生成自动化测试的结果。

11.如权利要求2所述的方法，其中所述一个或多个工作流的步骤包括在不同企业网站之间共享的默认函数以及在所述函数定义中定义的特定于与所述函数定义相关联的企业网站的特定于企业网站的函数。

12.如权利要求2所述的方法，其中所述混合脚本包括在不同企业网站之间共享的默认函数以及在所述函数定义中定义的特定于与所述函数定义相关联的企业网站的特定于企业网站的函数。

13.如权利要求2所述的方法，还包括：

通过用户界面从用户接收对混合脚本的编辑，其中

由所述自动化工具解析器进行的解析包括解析经编辑的混合脚本以生成输出，以及

基于来自所述自动化工具解析器的输出来生成运行时脚本包括生成由所述自动化工具执行以生成自动化测试的结果的运行时脚本，所述自动化工具基于对混合脚本的编辑在企业网站的所述多个网页上实现所述一个或多个工作流的步骤，以生成自动化测试的结果。

14.如权利要求13所述的方法，其中经编辑的混合脚本导致针对企业网站的定制的自动化测试。

15.一种用于实现可定制的企业自动化测试框架的系统，所述系统包括：

处理器；以及

存储器，存储由所述处理器执行的指令，所述指令将所述处理器配置为：

接收用于企业网站的自动化测试的工作流定义、页面结构定义和函数定义，其中所述工作流定义为包括一系列步骤的一个或多个测试用例定义一个或多个工作流，所述页面结构定义定义包括企业网站的多个网页的web元素，并且所述函数定义定义由所述一个或多个工作流的步骤引用的特定于企业网站的函数；

由混合脚本解析器解析所述工作流定义、所述页面结构定义和所述函数定义，以生成用于自动化测试的混合脚本；

由自动化工具解析器解析混合脚本，以生成自动化工具的输出；以及

基于来自所述自动化工具解析器的输出来生成运行时脚本，所述运行时脚本由所述自动化工具执行以生成自动化测试的结果，其中所述自动化工具在企业网站的所述多个网页上实现所述一个或多个工作流的步骤，以生成自动化测试的结果。

16.如权利要求15所述的系统，其中所述指令还将所述处理器配置为：

从用户接收对工作流中的一个或多个工作流的选择，其中所述混合脚本解析器基于工作流的选择来生成混合脚本。

17.如权利要求16所述的系统，其中所述指令还将所述处理器配置为：

从用户接收由特定于企业网站的函数中的第一特定于企业网站的函数使用的输入数据，其中当所述自动化工具实现所述一个或多个工作流的步骤时，实现步骤中的至少一个步骤包括调用所述第一特定于企业网站的函数以及使用所述输入数据以生成自动化测试的结果。

18.如权利要求17所述的系统，其中由所述混合脚本解析器生成的混合脚本使用所述第一特定于企业网站的函数和所述输入数据来实现所述一个步骤。

19.如权利要求16所述的系统，其中所述指令还将所述处理器配置为：

显示由所述工作流定义配置的所选择的工作流的用户界面，其中多个界面元素基于所选择的工作流的步骤而动态显示在所配置的用户界面中。

20.一种其上存储有指令的非暂态计算机可读介质，所述指令在由处理器执行时，使所述处理器实现可定制的企业自动化测试框架，其中所述指令在执行时，使所述处理器：

接收用于企业网站的自动化测试的工作流定义、页面结构定义和函数定义，其中所述工作流定义为包括一系列步骤的一个或多个测试用例定义一个或多个工作流，所述页面结构定义定义包括企业网站的多个网页的web元素，并且所述函数定义定义由所述一个或多个工作流的步骤引用的特定于企业网站的函数；

由混合脚本解析器解析所述工作流定义、所述页面结构定义和所述函数定义，以生成用于自动化测试的混合脚本；

由自动化工具解析器解析混合脚本，以生成自动化工具的输出；以及

基于来自所述自动化工具解析器的输出来生成运行时脚本，所述运行时脚本由所述自动化工具执行以生成自动化测试的结果，其中所述自动化工具在企业网站的所述多个网页上实现所述一个或多个工作流的步骤，以生成自动化测试的结果。

Images