Customizable Enterprise Automation Testing Framework

Abstract

Embodiments provide systems and methods for implementing a customizable enterprise automation testing framework. A workflow definition, a page structure definition, and a function definition for automated testing of an enterprise website can be received. A hybrid script parser can parse the workflow definition, the page structure definition, and the function definition to generate a hybrid script for automated testing. An automated tool parser can parse the hybrid script to generate an output of the automated tool. Based on the output from the automated tool parser, a runtime script can be generated, and the runtime script is executed by the automated tool to generate the results of the automated test, where the automated tool implements steps of one or more workflows on multiple web pages of the enterprise website to generate the results of the automated test.

Description

[0001] Cross - reference to related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 376,484, filed on April 5, 2019, the disclosure of which is incorporated herein by reference. Technical Field

[0003] Embodiments of the present disclosure generally relate to a customizable enterprise web application automated testing framework. Background Art

[0004] The web presence of enterprise entities has become increasingly important. For example, e - commerce has grown exponentially over the years, and other enterprise activities have increasingly shifted online. Additionally, with the advancement of web technologies, web applications and websites have acquired complex functionality. These trends have changed the expectations of enterprise system clients, customers, and / or users. For example, far - from - seamless online transactions, integrations, and / or workflows may lead to complaints about usability issues. Thus, an enterprise web presence may often be changed or updated with new functionality or content, but still expects to maintain or enhance usability. Consequently, a framework that can automate the testing of a customizable and productivity - enabling web presence can greatly improve enterprise websites or web applications. Summary of the Invention

[0005] Embodiments of the present disclosure generally relate to systems and methods for implementing a customizable enterprise automated testing framework, which represent a substantial improvement over the prior art. A workflow definition, a page structure definition, and a function definition for automated testing of an enterprise website can be received, where the workflow definition defines one or more workflows for one or more test cases including a series of steps, the page structure definition defines web elements including multiple web pages of the enterprise website, and the function definition defines enterprise - website - specific functions referenced by the steps of one or more workflows. A hybrid script parser can parse the workflow definition, the page structure definition, and the function definition to generate a hybrid script for automated testing. An automated tool parser can parse the hybrid script to generate an output of the automated tool. Based on the output from the automated tool parser, a runtime script can be generated, which is executed by the automated tool to generate the results of the automated test, where the automated tool implements the steps of one or more workflows on multiple web pages of the enterprise website to generate the results of the automated test.

[0006] The features and advantages of the embodiments are set forth in the following description, or will be apparent from the description, or may be learned by practice of the present disclosure. Brief Description of the Drawings

[0007] Other embodiments, details, advantages, and modifications will become apparent from the following detailed description of the preferred embodiments in conjunction with the accompanying drawings.

[0008] Figure 1 Illustrated is a system for implementing a customizable enterprise automation testing framework according to an example embodiment.

[0009] Figure 2 Illustrated is a block diagram of a computing device operatively coupled to the system according to an example embodiment.

[0010] Figure 3 Illustrated is another system for implementing a customizable enterprise automation testing framework according to an example embodiment.

[0011] Figure 4A 、 4B Figures 5A and 5B illustrate versions of an enterprise web application according to an example embodiment.

[0012] Figure 6A Illustrated is an example workflow definition according to an example embodiment.

[0013] Figure 6B Illustrated is an example workflow for searching for flights according to an example embodiment.

[0014] Figure 6C Illustrated is an example page structure definition according to an example embodiment.

[0015] Figure 6D Illustrated is an example function definition according to an example embodiment.

[0016] Figure 7A 、 7B Figures 7C and 7D illustrate a user interface for configuring hybrid script generation for customized automated testing according to an example embodiment.

[0017] Figure 8 Illustrated is a generated hybrid script according to an embodiment.

[0018] Figure 9A Illustrated is an example implementation framework configuration according to an example embodiment.

[0019] Figure 9B Illustrated are example implementation framework features according to an example embodiment.

[0020] Figure 9C Illustrated are an example suite file and suite results according to an example embodiment.

[0021] Figure 9D Illustrated is an example customized automated test result according to an example embodiment.

[0022] Figure 10A Illustrates a suite-level results web page according to an example embodiment.

[0023] Figure 10B Illustrates a detailed test-level results web page according to an example embodiment.

[0024] Figure 10C Illustrates an example test result with a failure status according to an example embodiment.

[0025] Figure 11A , 11B , 11C, and 11D illustrate a user interface for generating a hybrid script for another customized automated test configuration according to an example embodiment.

[0026] Figure 12 Illustrates a flowchart for implementing a customizable enterprise automation test framework according to an example embodiment. Detailed Description

[0027] Embodiments implement a customizable enterprise automation test framework. For example, an enterprise may have a web presence, such as a web application or a website. It may be beneficial to test the web presence from time to time, such as to ensure that various parts of the web application or website functions execute as expected. For example, the web presence may be tested when changes are implemented (e.g., updates, patches, etc.) or at any other suitable time.

[0028] Such testing may be time-consuming and costly if done manually. Thus, automated tools may be used to improve test efficiency. However, such automated tools also require configuration, which itself may be very time-consuming. For example, different versions of the web presence may require customized tests, or for various reasons, tests may be customized for different versions. Configuring the automated tools to run such customized tests may result in repetitive manual work.

[0029] Embodiments implement a customizable enterprise automation test framework that improves the efficiency and flexibility of performing automated tests on a web presence (e.g., a web application or a website). For example, the definition of an enterprise website can be used to generate a hybrid script, the hybrid script can be parsed to generate a runtime script, and an automated tool can use the runtime script to implement automated tests on the enterprise website.

[0030] In some embodiments, the definitions can include workflow definitions, page structure definitions, and function definitions. For example, a workflow definition can define a workflow that includes a series of steps to be executed for testing. A page structure definition can define web elements for the web pages of an enterprise website. A function definition can define enterprise website-specific functions for performing tests on the enterprise website (e.g., functions called by the steps of a workflow). In some embodiments, these definitions are stored in a markup language document (e.g., an Extensible Markup Language (“XML”) document).

[0031] Embodiments can parse the definitions (e.g., using a hybrid script parser) to generate a hybrid script for enterprise website testing. The hybrid script can represent a customized version of an automated test (e.g., customized based on the received definitions). In some embodiments, the hybrid script can then be parsed by an automated tool parser. For example, the hybrid script can be configured to work with any number of automated tools (e.g., web presence test automation tools available to those of ordinary skill in the art). A given automated tool parser can be configured to generate an output that can be used by a specific automated tool. Thus, the hybrid script can be combined with different automated tool parsers, and these various combinations can be used to achieve customized tests through various different automated tools.

[0032] In some embodiments, the output of the automated tool parser can be used to generate a runtime script (e.g., used by an automated tool associated with the automated tool parser to achieve a customized test). For example, the runtime script can be received by an automated tool (e.g., a cloud-based automated tool), and then the automated tool implements the customized test represented in the runtime script on the enterprise website. This implementation generates test results that can be received and / or displayed in a user interface. For example, the test results can include the status of the workflows defined in the workflow definition and / or the individual steps of one of these workflows (e.g., Pass, Fail, Skip).

[0033] In many cases, the embodiments of the present disclosure can be beneficial. For example, in an enterprise-packaged web application, the product is typically delivered to enterprise customers through a number of customizations (e.g., implemented according to each customer request). Additionally, there can be many variations in an enterprise web presence, so one enterprise website or web application may be similar to another but different due to customizations.

[0034] For example, customization may include one or more of the following: (1) themes, colors, fonts, style sheets for reflecting the brand; (2) the navigation to access the function may be different, so the navigation may involve traversing more or different web pages / screens to access the function; (3) the elements visible on the web page / screen may vary in number and / or order (e.g., due to geographical restrictions, for some implementations, some fields may be required fields, while for some other implementations, these fields may not be displayed in the application); (4) the element types may change according to the implementation scenario (e.g., in one variant, the element type may correspond to a freely editable field, while in another variant, it may be a single-selection combo list, radio button, or some other element); (5) generally speaking, although the two variants may have a similar number of fields / elements visually, due to customization, the functions may be slightly different between them. As described in various embodiments, many other situations can similarly benefit from a framework that efficiently implements customizable automated web testing.

[0035] Considering conventional test automation frameworks, the embodiments provide benefits. For example, web automation scripts that are typically based on a graphical user interface (“GUI”) have the following functions:

[0036] · Browser-based navigation to a desired web page / web section;

[0037] · Identifying elements on which actions need to be performed (e.g., the actions can be operations that we expect the script to perform on the web elements); and

[0038] · Assertion checks to ensure that the script has performed the expected operations.

[0039] For many automation scripts, the above three parameters are usually considered, but when one or more of these parameters change, the script may fail. For example, in a conventional implementation, automation scripts (code) are usually written to traverse web pages / web frameworks, perform actions on elements in the web page, assert, and finally report. Although this may work for vanilla-based implementations (e.g., without user interface or function customization), for variants where the user interface and / or function change from one implementation to another, these conventional scripts usually fail because they are not extensible.

[0040] Another challenge is that these automated scripts are typically tightly coupled to the underlying automation tools, and in some implementations, the scripts cannot be reused when different automation tools are used (e.g., by different customers or across product development organizations, implementation organizations, and customers). However, in many cases, customer automation tools are different, and there is no standardized automation tool for cross-customer use. In the case of such a wide variety of tools, it would be very cumbersome to use each automation tool (e.g., used by all customers) to certify customized implementations of enterprise-packaged web applications or websites, or at least it would require unnecessary work.

[0041] Embodiments implement a framework topology that is not tightly integrated with the underlying automation tools. For example, the underlying automation tool will be used for execution, but can be swapped by replacing a loosely coupled automation-tool-specific framework parser with a framework parser that is loosely coupled to a different automation tool. In cases where different commercial or open-source automation tools are used by different customers, conventional automation scripts become unavailable.

[0042] Embodiments implement a customizable framework design topology that mitigates existing problems through one or more of the following design principles.

[0043] · The framework can be implemented, for example, using different underlying automation tools (commercial or open-source) based on the disclosed hybrid script concept and runtime script composition.

[0044] · The generated hybrid scripts do not include navigation / assertion / action information hard-coded within the script. For example, these can be generated (e.g., based on external definitions) and can be modified, such as just before execution.

[0045] · The logical function flow can be published in a data format (e.g., workflow definition). For example, a logical workflow can be defined in XML format, and the ordering of function steps can be easily modified in any text editor, which can then produce a customized version of the script.

[0046] · Elements (e.g., web elements) on which actions / navigation / assertions can be performed and that can be published in another data structure (e.g., page structure definition).

[0047] These elements can be classified as pages and sections.

[0048] · The web interface components of the framework can read these files (e.g., XML files),

[0049] And provide the user with the option to customize the steps for an implementation-specific script. Additionally, embodiments of the web interface allow the user to enter test ware data (e.g., input data) to generate a customized implementation.

[0050] · Actions / assertions / navigations can be published as hybrid functions. For example, instead of using traditional code, references to elements and data for which function operations are defined (e.g., in a markup language document) can be used. These functions can be defined in a file (e.g., function definitions). In some embodiments, the runtime functions can be specific to the automation tool and can be generated based on these hybrid functions.

[0051] · Variations of the implementation of an enterprise-packaged web application or website can have their own copies of data files for customized testing (e.g., workflow definitions, page structure definitions, and function definitions).

[0052] · The hybrid script generator can read these files along with the steps and test data entered from the web interface to generate a hybrid script.

[0053] · The hybrid script can be in text format, which enables easy and quick modification of these scripts before execution for data modification, step order change, enabling / disabling step execution, etc.

[0054] disabling step execution, etc.

[0055] · The reporting engine for the framework can generate suite and test level result files (e.g., XML files). In some embodiments, the web dashboard can transform the XML (e.g., into HTML) and display it in the web reporting interface.

[0056] Based on one or more of these features, embodiments of the customizable framework provide the following improvements. Given the hybrid script and the automation tool-specific parser, embodiments can work with multiple underlying automation tools (e.g., commercial or open source). For example, some implementations utilize two script layers (hybrid and runtime) to easily couple with the underlying automation tools. Additionally, the generated hybrid script can be shared with the customer without sharing the code that generated it.

[0057] In some embodiments, the hybrid script layer is text-based and can be modified by various users (e.g., users without coding experience). In several cases, the hybrid script can be generated before creating runtime functions. In some embodiments, web page elements, function workflows, and functions can be defined in a metadata format (e.g., in a data file such as a markup language file), resulting in easier management and more robust scripts. For example, in the case of changes to element attributes or the Document Object Model ("DOM"), no code changes are required (e.g., modifying a definition file or an XML file in some embodiments is sufficient). To test different scenarios in the case of enabling / disabling some mandatory and optional fields, no code modification is required; modifying the generated hybrid script is sufficient.

[0058] In some embodiments, in the case of a change in the visual sorting of web elements in a customized web page, changing the sorting of the function workflow (e.g., the workflow XML file) will be sufficient. In some embodiments, the framework can be adjusted to automatically perform pre-requisite activities based on what action is selected. This can be achieved through the parent_page attribute and the dependent_action attribute (e.g., in the function library XML).

[0059] In some embodiments, although the functions to be executed are customized, the function names for different customized tests (e.g., tests customized for different versions of an enterprise website) can remain the same in the hybrid script. In such cases, customization can be implemented at the runtime script level. In such an implementation, the hybrid script maintains readability and simplifies its management.

[0060] Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Whenever possible, the same reference numerals will be used for the same elements.

[0061] Figure 1Illustrated is a system for implementing a customizable enterprise automation testing framework according to an example embodiment. System 100 includes implementation-specific definitions 102, a parser and script generator 104, and an automation tool 106. In some embodiments, the implementation-specific definitions 102 may provide definitions for customized tests to be implemented by the automation tool 106, such as definitions for a workflow including steps for testing, definitions for the page structure of a web page (e.g., a web page of an enterprise website or web application) on which the customized test is to be run, and definitions for functions called by the steps of the workflow.

[0062] In some embodiments, the parser and script generator 104 may parse the implementation-specific definitions 102 to generate a hybrid script. Then, the hybrid script can be used to generate a runtime script that the automation tool 106 uses to implement the customized test. In various embodiments, a given test can be customized based on the implementation-specific definitions 102. For example, a given set of definitions can be used to generate a hybrid script that configures the performance of the customized test. When this set of definitions changes (e.g., is edited by a user), the generated hybrid script may also change, and thus the automation tool 106 implements a different customized test. In some embodiments, a user interface may also be used to customize the implementation of the test based on received edits to the workflow / steps defined in the implementation-specific definitions 102 and / or edits to the generated hybrid script.

[0063] Figure 2 is a block diagram of a computer server / system 200 according to an embodiment. All or part of system 200 can be used to implement Figure 1 any of the elements shown in Figure 2 As shown in

[0064] For example, the communication device 220 may include a network interface card configured to provide wireless network communication. Various wireless communication technologies can be used, including infrared, radio, Bluetooth Wi-Fi, and / or cellular communication. Alternatively, the communication device 220 may be configured to provide a (one or more) wired network connection, such as an Ethernet connection.

[0065] The processor 222 may include one or more general-purpose or special-purpose processors to perform the computing and control functions of the system 200. The processor 222 may include a single integrated circuit, such as a microprocessing device, or may include multiple integrated circuit devices and / or circuit boards that work together to perform the functions of the processor 222. Additionally, the processor 222 may execute computer programs stored in the memory 214, such as the operating system 215, the test framework 216, and additional functions 218.

[0066] The system 200 may include a memory 214 for storing information and instructions to be executed by the processor 222. The memory 214 may include various components for retrieving, presenting, modifying, and storing data. For example, the memory 214 may store software modules that provide functions when executed by the processor 222. These modules may include an operating system 215 that provides operating system functions for the system 200. These modules may include the operating system 215, a test framework 216 configured to implement the customized automated testing and other functions disclosed herein, and additional functions 218. The operating system 215 provides operating system functions for the system 200. In some cases, the test framework 216 may be implemented as configured in the memory. In some implementations, when the system 200 executes the functions of the test framework 216, it implements an unconventional special-purpose computer system that executes the functions disclosed herein.

[0067] The non-transitory memory 214 may include various computer-readable media that can be accessed by the processor 222. For example, the memory 214 may include any combination of random access memory (“RAM”), dynamic RAM (“DRAM”), static RAM (“SRAM”), read-only memory (“ROM”), flash memory, cache memory, and / or any other type of non-transitory computer-readable media. The processor 222 is also coupled to a display 224, such as a liquid crystal display (“LCD”), via a bus 212. A keyboard 226 and a cursor control device 228, such as a computer mouse, are also coupled to the communication device 220 to enable a user to interface with the system 200.

[0068] In some embodiments, the system 200 may be part of a larger system. Thus, the system 200 may include one or more additional functions 218 to include additional functionality. The additional functions 218 may include, for example cloud infrastructure, cloud platform, various modules of cloud applications. The test framework 216, the additional functions 218, and any other suitable components of the system 200 may include various Java modules and / or modules of MySQL, as well as other suitable frameworks / services.

[0069] The database 217 is coupled to the bus 212 to provide centralized storage for the modules 216 and 218 and store data such as data for the test framework 216 or other data sources. The database 217 may store data in an integrated collection of logically related records or files. The database 217 may be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigation database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, a non-relational database, a NoSQL database, a distributed file system (“HFDS”), or any other database known in the art.

[0070] Although shown as a single system, the functions of the system 200 may be implemented as a distributed system. For example, the memory 214 and the processor 222 may be distributed across multiple different computers that together represent the system 200. In one embodiment, the system 200 may be part of a device (e.g., a smart phone, a tablet computer, a computer, etc.). In an embodiment, the system 200 may be separate from the device and may remotely provide the disclosed functions to the device. Additionally, one or more components of the system 200 may be excluded. For example, for the functions of a user or consumer device, the system 200 may be a smart phone or include a processor, a memory, and a display, excluding Figure 2 one or more of the other components shown in Figure 2 and including additional components (such as antennas, transceivers, or any other suitable wireless device components) not shown in

[0071] Figure 3 Another system for implementing a customizable enterprise automation test framework according to an example embodiment is illustrated. Figure 3 The system shown includes a workflow definition 302, a page structure definition 304, an implementation function library 306, an implementation framework feature 308, an implementation framework configuration 310, a framework module 312, an automation tool 314, a framework interface 316, a parser 318, a reporting engine 320, an execution engine 322, a hybrid script parser 324, an automation-tool-specific parser 326, a runtime script generator 328, external test data 330, a general function library 332, an implementation suite file 334, a web automation tool 336, a test execution module 338, a suite result 340, and a test result 342. In some embodiments, Figure 3 the components of the system shown may be used to implement customized automated testing for enterprise web applications (e.g., enterprise websites) and / or different versions of enterprise web applications.

[0072] For example, Figure 4A , 4B , 5A and 5B illustrate versions of an enterprise web application. Figure 4A The user interface 402 of depicts the landing page of a first airline web application for booking flights, and Figure 5A The user interface 502 of depicts the landing page of a second airline web application for booking flights. For example, the user interfaces 402 and 502 can be used to search for flights using the parameters input into the depicted web elements. Similarly, Figure 4B The user interface 406 of depicts the flight results page of the first airline web application, while Figure 5B The user interface 506 of depicts the flight results page of the second airline web application.

[0073] In some embodiments, the first airline web application and the second airline web application can be different variants of a common airline web application. For example, a web application provider / host can maintain a common airline web application that can be customized, and the first airline web application and the second airline web application can be different customized versions of the common airline web application. However, this is merely an example, and the first airline web application and the second airline web application may not share this commonality (e.g., do not share a common web application). Embodiments demonstrate how the framework can efficiently implement customized and automated testing for these two customized enterprise applications.

[0074] Figure 4A The user interface 402 of depicts an example login page where, by default, the flight tab is enabled. In this example, there are radio buttons for selecting a one-way / round-trip itinerary, and by default it is set to one-way, and there are six fields, namely the departure city, arrival city, departure date of web element 404, passengers, and currency. In this example, the passengers field is default set to "1 adult", and the currency field is default set to "INR". When the search icon is clicked, the enterprise web application retrieves flights based on the matching criteria. At Figure 4B At the user interface 406 of , the user can select a flight number and flight class, and click continue to log in to the passenger details page.

[0075] Figure 5A The user interface 502 of depicts a landing page where, by default, a booked flight is displayed. In this example, there are three radio buttons: one-way / round-trip / multi-city (instead of Figure 4A the two radio buttons shown in the user interface 402 of ), and by default it is set to one-way. As compared to Figure 4Ais similar to user interface 402, user interface 502 has six fields, namely departure city, arrival city, passenger, departure date, and currency. However, there are several deviations (e.g., customization changes) that prevent a typical automation script written for one implementation from running successfully for another implementation (and in some cases, scripts for variants will be written from scratch). For example, when comparing Figure 4A user interface 402 with Figure 5A user interface 502, the following changes can be seen:

[0076] · The passenger field is displayed before the departure date field.

[0077] · Timing data is automatically entered into one field, and the content of the next field is displayed as follows.

[0078] · There are differences in web element types (e.g., the passenger field in user interface 402 is a simple radio dropdown list, while it is a complex widget as shown by widget 504 in user interface 502).

[0079] · The internal DOM characteristics of the elements can also be different. For example, for user interface 402, the "id" attribute can be used to identify web elements. Meanwhile, for user interface 502, the "xpath" attribute can be used to identify many web elements.

[0080] Similar to Figure 4B user interface 406, on Figure 5B user interface 506, the user can select a flight number and a flight class, and click continue to log in to the passenger details page. The embodiments use Figure 3 the elements of the system shown to implement customized automated tests for these variants of the web application.

[0081] In some embodiments, workflow definition 302 defines one or more workflows, which can be a series of steps that together generate test cases / workflows for an enterprise web application. Figure 6A Illustrates an example workflow definition 602.

[0082] In some embodiments, each customized version of the enterprise web application will have its own version of workflow definition 602 (although several definitions can be shared). This file (e.g., metadata, markup language, and / or XML file) defines the details of the functional workflow of the test cases and the steps involved in each workflow.

[0083] In some embodiments, each step tag in the workflow definition 602 has an attribute named "action_method" that lists the relative name of the function that will be called to execute that step. As further disclosed herein, the detailed arguments that the function takes can be listed in an implementation-specific function definition. The "action_on_elem" attribute is another attribute that refers to the web element on which the action is to be performed. In this example, the web element is at <page> . <section>listed in the nomenclature of <element name>.

[0084] In some embodiments, details about web elements can be found in implementation-specific page structure definitions, as disclosed herein. The "desc" attribute can list a description of the step, which can be displayed in the web interface (e.g., for creating a hybrid script). As disclosed herein, the functionality listed in workflow definition 602 can be displayed as steps that a user can select to create a hybrid script in a framework web interface.

[0085] Figure 6B An example workflow 604 for searching for flights is illustrated. For example, workflow 604 can be Figure 6A part of the workflow definition 602 of, i.e., the "search for a one-way flight for one passenger without selecting any additional items" workflow. In this example, seven steps are listed:

[0086] Step 1: Select the itinerary type option "one-way or round-trip"

[0087] Step 2: Select / enter the flight "from" location

[0088] Step 3: Select / enter the flight "to" location

[0089] Step 4: Select the departure date from the web calendar

[0090] Step 5: Select the number of passengers to fly

[0091] Step 6: Select the currency for purchasing the ticket

[0092] Step 7: Click the flight search button to get a list of available flights based on these parameters.

[0093] Figure 6C A page structure definition 606 is illustrated (e.g., Figure 3 the page structure definition 304 of). The page structure definition 606 (e.g., metadata, markup language, and / or XML file) can define web elements on a customized enterprise web application (e.g., where customized automated tests will perform navigation, actions, and assertions). In this example, web pages and sections are used to construct the elements.

[0094] In some embodiments, each variant (e.g., a customized implementation) may include its own version of the page structure definition 606. A web element may have a "name" attribute, which may be unique and, in some examples, may be referenced by a workflow definition file and / or a function definition file. An example "locator_type" attribute may define the DOM characteristic of the web element by which the element can be uniquely identified in the page. An example "locator_value" attribute may list the value of the "locator_type" attribute.

[0095] For a web element referenced when implementing automated customization testing, the hybrid script generator may refer to the page structure definition 606 to obtain details of the web element. It can then be passed to the underlying automation tool for identification. In some embodiments, if a new automation tool is envisioned (e.g., an automation tool that looks for unique characteristics of the DOM to identify elements), then that characteristic can be added as an attribute to the page structure definition 606, and the corresponding value can be provided.

[0096] Figure 6D An example function definition 610 (e.g., Figure 3 of the function library 306) is illustrated. The function definition 610 (e.g., metadata, markup language, and / or XML file) may define implementation-specific functions for a customized version of implementing automated testing (e.g., called by workflow steps during test execution). For example, actions, navigations, and assertions can be converted into functions, and the details can be defined in the function definition 610. For example, the function 612 defines the function select_depart_date.

[0097] In some embodiments, the function may also be configured for pages and sections for identification, addition, and / or modification. In this example, the function tag may have a "desc_name" attribute, which may be the name of the function. An example "type" attribute may identify the type of the function such as navigation / assertion, etc. An example "signature" attribute may specify the arguments accepted by the function. For example, consider the signature of the "navigation" function "select_depart_date" in the function definition 608.

[0098] 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')

[0099]

[0100] In this example, the first argument is 'ps:landing_page.default.depart'. Here, 'ps' can represent 'page structure', and 'landing_page.default.depart' can be the unique identifier of a web element. Details of the web element 'landing_page.default.depart' can be obtained from the page structure definition (e.g., Figure 6C page structure definition 606), and the details will be:

[0101] <element elem_name = "depart" locator_type = "id"

[0102] locator_value = "ctl00_mainContent_view_date1" img = ""

[0103] visible_label = "DEPART DATE" type = "static"

[0104] action_supported = "click,calendar_select()"

[0105] default_visibility = "true">

[0106] ​In this example, the independent variable "data_user_form:fw:search_one_way_flight.deptart_date” has two parts. The first part, "data_user_form”, can indicate that the function accepts test data from a framework web page (e.g., from a widget "Create automated test” as disclosed herein). In this example, in the second part, "fw:search_one_way_flight.depart_date”, "fw” refers to a workflow definition (e.g., Figure 6A workflow definition 602), and the string after ":" can indicate the name of the web element "depart_date” found under the function name "search_one_way_flight” in the workflow definition (as shown in Figure 6A workflow definition 602).

[0107] Examples of frameworks include forms, web pages, websites, web applications, dashboards, or any other suitable web entity, such as Figure 3 framework interface 316, which can be used to configure hybrid scripts based on the disclosed definitions (e.g., workflow definitions, page structure definitions, and function definitions). Figure 7A 、 7B Figures 7C and 7D illustrate user interfaces for configuring hybrid script generation for customized automated testing. The user interface 702 can include a web element 704 that can be used to select a workflow, a web element 706 that can display the steps of the selected workflow as web elements, and a web element 708 that can be an editable field for entering a test departure date for the selected workflow.

[0108] Examples include the user interface 702 as a web interface for configuring and creating hybrid scripts based on customized automated test definitions and inputs received through the user interface. In some examples, a customized automated test name, URL, and hybrid script path can be provided to generate the interface.

[0109] Figure 7B Figure 7E illustrates the web element 704, which is depicted as a drop-down menu that is populated by workflows based on a workflow definition (e.g., Figure 6A The workflow definition 602) is populated. For example, the web framework can automatically retrieve the corresponding workflow definition, parse the file, and list the workflow as an option in the "Business Use Case" drop-down list. After selecting the workflow, the steps (as defined in the workflow definition) can be displayed in the user interface 702. In some embodiments, the web interface can perform an AJAX call to retrieve / display the relevant steps of the selected workflow. For example, returning to Figure 7A , the web element 706 displays the steps of the selected workflow (e.g., searching for a one-way flight for a passenger without selecting any additional items) as separate web elements.

[0110] In some embodiments, the steps can be displayed in the order represented by the workflow definition, and certain fields are editable when the step corresponding to the field is a step that receives input. For those steps for which the user of the user interface 702 has not provided input data, non-editable web elements are displayed. For those steps that expect the user to enter input data, editable web elements such as web element 708 are displayed. For example, when the step where the "action_method" function has arguments starting with "data_user_form" is entered / displayed, an edit box can be dynamically presented in the user interface 702 to capture user input for the hybrid script.

[0111] For example, the interface 702 illustrates seven example fields corresponding to the selected workflow step. These seven example fields are displayed by Figure 7C the web element 706. Among these seven fields, "Click One-Way" and "Click Search" are displayed as read-only. For the remaining five fields, namely "From", "To", "Departure Date", "Number of Passengers", and "Currency", the user is allowed to enter data. Values of "MUMBAI", "DELHI", "September 29, 2018", and "INR" are entered in these fields. In this example, no value is entered in the passenger field because the corresponding enterprise web application being tested will automatically select the default passenger as 1.

[0112] In an embodiment, the steps of the workflow configured to generate the hybrid script can be considered steps of hybrid script generation. Once the first selected workflow is configured, another workflow can be selected using the "Add Step" button of the user interface 702 (e.g., as Figure 7B shown, from the drop-down menu). Figure 7D Illustrates the steps of the second selected workflow, namely "Select a flight based on flight number and class".

[0113] Figure 7D The web element 710 of Figure 6A 4 steps defined for the selected workflow definition 602 in the workflow definition. In this example, the first two fields can be used to enter the flight number and flight class, and the remaining two fields are non - editable. Using Figure 7A , 7B , 7C, 7D, the above - described action sequence can create two script steps for the hybrid script generation component (e.g., corresponding to two selected workflows and input information corresponding to the steps of the workflow).

[0114] In some embodiments, after configuring the hybrid script using the interface 702, the hybrid script can be generated by a web framework. Figure 8 Illustrates a generated hybrid script according to an embodiment. For example, the user interface 802 displays a hybrid script 804, which can include a representation of a customizable automated test configured using the user interface 702 (e.g., the selected workflow and the configuration steps of the workflow).

[0115] In some embodiments, a hybrid script generator / parser (e.g., Figure 3 the hybrid script parser 324) can parse relevant definitions (e.g., Figure 6A the workflow definition 602, Figure 6C the page structure definition 606, and Figure 6D the function definition 610) to generate hybrid script content. For example, the hybrid script parser 324 can be responsible for parsing implementation - specific definition files and generating a hybrid script (e.g., based on data selected by the user from web interface and framework configurations). The hybrid script is generated specifically for the customized implementation of an enterprise - packaged web application.

[0116] In some embodiments, the hybrid script parser can be a unique parser algorithm (e.g., developed using JAVA). For example, the hybrid script parser can generate an implementation - specific hybrid script. In some embodiments, the hybrid script parser can parse definition files (e.g., Figure 6A the workflow definition 602, Figure 6C the page structure definition 606, and Figure 6D the function definition 610). These definitions can be designed in such a way that they can be cross - referenced so that the framework can have a comprehensive understanding of the implementation. For example, cross - references can be implemented using tags and attributes (e.g., marking definition files).

[0117] In some embodiments, hybrid script generation is performed using a web interface (e.g., as shown in Figure 7A , 7B , 7C, and 7D). For example, once the user (e.g., using Figure 7B Once the workflow (element 704) is selected, the hybrid script parser can be initiated. The hybrid script parser can parse the workflow definition to retrieve the steps of the selected workflow. To obtain detailed information about the elements encountered in the steps, it can parse the page structure definition. Then, for actions (e.g., action_method within the definition), the parser can reference the function definition to obtain the detailed function call.

[0118] In Figure 8 the example shown, the prefix "EXEC_LINE" indicates whether a line is to be executed when implementing the script. By default, the lines in the hybrid script content can be set to "TRUE". If set to "FALSE", the corresponding line will be skipped during execution.

[0119] The hybrid script 804 includes method calls that are standard methods and can be used across various implementations (e.g., starting from the language "default_"). For example, a common library (e.g., common function library 332) that can work across multiple customizations / implementations can be maintained. For example, these common methods can be different from the specific methods defined in a function definition (e.g., Figure 6D the function definition 610). In some embodiments, the function definitions are separate and maintained for each customization to include customized methods / functions.

[0120] For example, in the hybrid script 804, line 806 includes the function "Select departure date", which is a specific function defined in the function definition for a specific customization associated with this hybrid script / customized automated test. The hybrid script 804 also includes the function "select_preferred_flight", which can be different for different enterprise web applications / customizations. For example, Figure 4A and 5A depict different enterprise web applications, so each application can have its own set of definitions that are parsed to generate the hybrid script (and subsequent runtime script). Thus, although the same method names can be used in the hybrid script for these two implementations, at runtime, the "select_preferred_flight" method corresponding to the implementation / customization in the function library will be used.

[0121] In some embodiments, for the parameters in a function call that includes "data_user_form", the framework expects the data that the user enters from the web interface form (e.g., such as Figure 7A elements 706 and 708). In some embodiments, the parsing function can be repeated by a hybrid script parser for various workflow steps entered in a web interface. Then, the hybrid script parser can generate a customized text-based nomenclature (e.g., Figure 8 as shown in hybrid script 804).

[0122] In some embodiments, for forms where users are expected to manually enter data, the data can be obtained from an external test data repository (e.g., Figure 3 external test data 330). In this case, instead of entering data, a nomenclature such as "db:<sql_file_name>" that the hybrid script parser can interpret can be entered. For example, the hybrid script parser can determine to execute a query (e.g., an SQL query) on a database, and the result set can be the data to be used (e.g., form values). Similar configurations can also be made to retrieve data from other formats (e.g., worksheets such as Excel worksheets, XML formats, etc.).

[0123] In some embodiments, for each implementation / customization, there is an implementation-specific framework configuration file (e.g., Figure 3 implementation framework configuration 310). Figure 9A An example implementation framework configuration 902 is illustrated. For example, the implementation framework configuration 902 can include details such as the suites to run, the automation tools to use, etc. As shown, the automation tool (e.g., Figure 3 automation tool 314) in the shown example is Selenium. However, since the framework is loosely coupled with the underlying automation tool, any open-source, commercial, or any other suitable automation tool can be defined. The example "suite_to_exec" tag has details of the implementation-specific suite to be executed.

[0124] In some embodiments, for each implementation / customization, there is an implementation-specific framework parameter file (e.g., Figure 3 implementation framework characteristics 308). Figure 9B An example implementation framework characteristics 904 is illustrated. For example, the implementation framework characteristics 904 can include details about defining / customizing the implementations to be supported. The framework can refer to this file for implementation-specific details. For example, Figure 4A and 5A the enterprise web applications shown in are listed in the implementation framework characteristics 904. Figure 9C An example implementation suite file 334 is illustrated. The implementation suite file 334 can include details of the hybrid scripts to be executed. Multiple scripts can be listed in this file.

[0125] Referring again to Figure 3 , the generated hybrid script can then be processed (e.g., by the automation tool-specific parser 326 and the runtime script generator 328) to generate a runtime script. For example, the automation tool-specific parser 326 parses the automation tool-specific native methods and the hybrid script to generate a temporary format to be used by the runtime script generator. The runtime script generator 328 takes the temporary format (passed by the automation tool-specific parser 326) and the customization business-specific automation methods defined in the function library and generates a runtime script that can be executed using the specific automation tool.

[0126] In some embodiments, the automation tool-specific parser 326 operates in tandem with a function definition (e.g., Figure 6D the function definition 610) to come up with a temporary runtime script format. For example, the hybrid script can have a method name such as "default_click", and the framework can understand that the prefix "default" indicates that the standard native click method of any automation tool should be used for that action. Then, the automation tool-specific parser 326 can convert the default_click method into a tool-specific click format. In the example where the automation tool is Selenium, the hybrid script line: "default_click(id:ct100_mainContent_rbtnl_Trip_0" can be converted into Selenium-specific code "driver.findElement(By.id("ct100_mainContent_rbtnl_Trip_0")).click();".

[0127] In some embodiments, when the method is not a native method, the framework can look at the function definition to determine if the method is declared and use it for runtime execution. Using this information, the automation tool-specific parser 326 can generate a structured script in a programming language (e.g., supported by the automation tool) to be executed using the specific tool. In some embodiments, the runtime script generator allows for a final level of customization and a final level of hardening of the script before it is executed.

[0128] Return reference Figure 3 , in some embodiments, the automation tool 314 communicates with the execution engine 322 and executes the generated runtime script (e.g., using the web automation tool 336 and the test execution module 338) to generate results from the execution of the customized automation test. The results can include suite results, individual workflow results, and / or individual steps in the workflow results, where the results can indicate the relevant status (e.g., pass, fail, skip, etc.). In some embodiments, the results can be generated as files (e.g., markup language and / or XML files) that can be processed and rendered in a web format (e.g., HTML) (e.g., from the automation tool).

[0129] For example, Figure 9C illustrates an example suite result 906 (e.g., Figure 3 the suite result 340). The suite result 906 shows the execution status at the suite level. For example, if all the tests in the suite pass, then the suite execution status is "PASS". Embodiments also include results at a finer-grained level (e.g., test results 342).

[0130] For example, Figure 9D illustrates an example test result 908. The test result 908 shows the execution status and event level of each step (e.g., sub-steps within the step) of (e.g., a workflow). For example, events can be specified at the function library code level. In some embodiments, if all the events in a step pass, then the step execution status is set to "PASS". In some embodiments, when the execution status of all steps (except skipped steps) is set to "PASS", the test execution status is set to "PASS".

[0131] In some embodiments, the framework web reporting engine (e.g., Figure 3 the reporting engine 320) parses the suite and test results and displays them in HTML format. In some embodiments, the framework web layer can be implemented in a Linux platform, while the test execution can be performed in a Windows platform. Here, the suite and test result files can be generated in Windows and then can be uploaded to Linux (e.g., using the framework web interface "upload report"). For example, once the report is uploaded, the results can be viewed by clicking "view report". In some embodiments, in the "enter result file path" field, the Linux folder where the report is uploaded is specified. The reporting engine can check the folder and identify the result file (e.g., XML file).

[0132] Figure 10A Illustrates the suite-level results web page. The user interface 1002 displays the suite results 1004 (e.g., the displayed test is "passed"). The illustrated radio buttons can be selected to further explore the results. Figure 10B Illustrates the detailed test-level results web page. The user interface 1006 includes a web element 1008 that displays the results of relevant steps (e.g., the workflow for the test), and one or more of these steps can be selected such that the web element 1010 shows the event-level execution status in the selected steps.

[0133] Figure 10C Illustrates an example test result with a failure status. The user interface 1012 includes a web element 1014 that includes multiple steps with a failure status (e.g., step 8 in the selected preferred flight). The log file can also indicate the reason for the failure, e.g., the step and subsequent steps failed due to the failure to render the page on time.

[0134] In some embodiments, the framework can be configured to automatically execute prerequisite activities depending on what action is selected. This can be achieved through the parent_page property and the dependent_action property (e.g., in the function library XML). For example, from a web interface (e.g., for generating a hybrid script), if the user adds details for the step of selecting a flight from search results instead of adding details for the step of searching for a flight, then the following example line can be generated in the hybrid script:

[0135] "EXEC_LINE=TRUE##select_preferred_flight(id:availabilityTable0,xpath:ControlGroupSelectView_AvailabilityInputSelectionView_RadioButtonMkt1Fare,DA

[0136] 158,DAMAX)"

[0137] When parsing this line, the framework can reference the function library definition, and here it can find that the dependent action of select_preferred_flight is "fw:search_one_way_flight" (as Figure 6D shown). In some embodiments, the framework recognizes that some prerequisite actions are to be performed, and for this the framework can reference the function workflow definition (as Figure 6B as shown). For example, a workflow definition can include steps of the search_one_way_flight workflow and these steps can be executed using default data included in the definition before invoking the "select_preferred_flight" action.

[0138] Embodiments include customized automated testing for multiple web applications. Here, Figure 6A , 6B , 6C, 6D, 7A, 7B, 7C, 7D, 8, 9A, 9B, 9C, 9D, 10A, 10B, and 10C illustrate customized test implementations for the Figure 4A web applications shown in Figure 11A , 11B , 11C, and 11D illustrate user interfaces for configuring hybrid script generation for another customized automated test (i.e., a test customized for the enterprise web application shown in Figure 5A ).

[0139] For example, due to the improved design of the framework, embodiments of these customized tests can be similar. However, each customized automated test can have its own set of definitions (e.g., workflow definition, page structure definition, and function definition). Customizations present in these definitions can result in hybrid scripts, function libraries, and ultimately runtime scripts customized for a given implementation.

[0140] For example, Figure 11A illustrates user interface 1102, which can be used to specify an implementation name, URL, and script path specific to a customized automated test. Figure 11B User interface 1104 of

[0141] illustrates the steps of the selected workflow, i.e., "search for a one-way flight for one passenger without selecting any additional items" (e.g., a workflow similar to the workflow discussed with reference to the customization of the previous enterprise web application test). Figure 11C illustrates hybrid scripts 1108 and 1010 generated by user configuration.

[0142] In some embodiments, the generated hybrid script can be edited, for example, to adjust the generated runtime script and change the execution of the automated test. In the example, line 1 (where the radio button is selected as "one-way" by default) and line 6 (since the currency is also set to INR by default) can be skipped. To skip these two steps, the EXEC_LINE flag can be set to "FALSE", as shown in the hybrid script 1108.

[0143] In some embodiments, a test scenario can be requested that checks the flight availability for the next day based on default settings. In this case, the hybrid script can be modified to set EXEC_LINE = FALSE for step 5, as shown in the hybrid script 1110. Figure 11D The test level results of this modification are illustrated. As is obvious from the report shown in the user interface 1112, the test has passed, and steps 5 and 6 have been skipped since EXEC_LINE was set to FALSE.

[0144] Figure 12 The flowchart for implementing a customizable enterprise automation test framework according to an example embodiment is illustrated. In one embodiment, Figure 12 the functionality is implemented by software stored in a memory or other computer-readable or tangible medium and executed by a processor. In other embodiments, each functionality can be executed by hardware (e.g., by using an application-specific integrated circuit ("ASIC"), programmable gate array ("PGA"), field-programmable gate array ("FPGA"), etc.), or by any combination of hardware and software. In an embodiment, Figure 12 the functionality of Figure 2 can be executed by one or more elements of the system 200 of

[0145] At 1202, a workflow definition, a page structure definition, and a function definition for the automated test of an enterprise website are received. For example, the workflow definition can define one or more workflows for one or more test cases including a series of steps, the page structure definition can define web elements including multiple web pages of the enterprise website, and the function definition can define enterprise website-specific functions referenced by the steps of one or more workflows. For example, the workflow definition, page structure definition, and function definition can be markup language documents, such as XML documents. In an embodiment, the steps of one or more workflows include default functions shared between different enterprise websites and enterprise website-specific functions defined in the function definition specific to the enterprise website associated with the function definition.

[0146] At 1204, a user interface can be displayed based on a definition. For example, a user interface for configuring the generation of a hybrid script can be displayed. In some embodiments, one or more workflows can be selected such that customized automated tests can be generated for an enterprise website.

[0147] At 1206, input for the customized automated test can be received from a user via the user interface. In an embodiment, the user can select one or more workflows for testing. One or more steps of the workflows can be configured, such as by receiving input values in fields corresponding to the steps, where these values are used in the execution of the test.

[0148] In an embodiment, a user interface configured by the workflow definition for the selected workflow can be displayed, where a plurality of interface elements can be dynamically displayed in the configured user interface based on the steps of the selected workflow. For example, input data used by one of the functions specific to the enterprise website can be received, where when the automation tool implements one or more steps of the workflow, the implementation includes at least one of the steps of calling a function specific to the enterprise website and using the input data to generate the result of the automated test. In an embodiment, the user interface element for a step displayed on the user interface is configured to receive input data from the user. In an embodiment, the user interface is configured based on an Asynchronous JavaScript and XML (AJAX) call for the workflow definition.

[0149] At 1208, a hybrid script parser parses the workflow definition, page structure definition, and function definition to generate a hybrid script for the automated test. For example, the hybrid script can be generated based on the workflow selection and input received via the user interface. In an embodiment, the hybrid script generated by the hybrid script parser uses one of the functions specific to the enterprise website and the input data to implement the steps.

[0150] In an embodiment, the hybrid script is configured to be parsed by a plurality of automation tool parsers to generate outputs, each automation tool parser being associated with a different automation tool, and the runtime script based on the outputs from each automation tool parser is configured to be used by the different automation tools to generate the result of the automated test.

[0151] In an embodiment, the steps of one or more workflows include default functions shared between different enterprise websites and functions specific to the enterprise website specific to the enterprise website defined in the function definition. In this example, the hybrid script can include default functions shared between different enterprise websites and functions specific to the enterprise website specific to the enterprise website defined in the function definition.

[0152] At 1210, edits to the generated hybrid script can be received. For example, edits can be received via a user interface for the hybrid script that change the runtime script and ultimately change the execution of the automated test. The edits can include edits to flags indicating to skip one or more steps of a workflow.

[0153] At 1212, an automation tool parser can parse the hybrid script to generate an output of the automation tool. In an embodiment, the parsing performed by the automation tool parser can include parsing the edited hybrid script to generate the output.

[0154] At 1214, based on the output of the automation tool parser, a runtime script can be generated, which is executed by the automation tool to generate the results of the automated test. For example, the automation tool can implement steps of one or more workflows on multiple web pages of an enterprise website to generate the results of the automated test.

[0155] In an embodiment, generating a runtime script based on the output from the automation tool parser can include generating a runtime script that is executed by the automation tool to generate the results of the automated test, and the automation tool can implement steps of one or more workflows on multiple web pages of the enterprise website based on edits to the hybrid script to generate the results of the automated test. For example, the edited hybrid script can result in a customized automated test for the enterprise website.

[0156] Embodiments implement a customizable enterprise automation testing framework that improves the efficiency and flexibility of performing automated tests on a web presence (e.g., a web application or website). For example, a definition of an enterprise website can be used to generate a hybrid script, the hybrid script can be parsed to generate a runtime script, and the automation tool can use the runtime script to implement an automated test on the enterprise website.

[0157] In some embodiments, the definition can include a workflow definition, a page structure definition, and a function definition. For example, the workflow definition can define a workflow including a series of steps to be performed for a test. The page structure definition can define web elements for a web page of the enterprise website. The function definition can define enterprise website-specific functions for performing tests on the enterprise website (e.g., functions called by steps of the workflow). In some embodiments, these definitions are stored in a markup language document (e.g., an XML document).

[0158] An embodiment can parse a definition (e.g., using a hybrid script parser) to generate a hybrid script for enterprise website testing. The hybrid script can represent a customized version of an automated test (e.g., customized based on the received definition). In some embodiments, the hybrid script can then be parsed by an automated tool parser. For example, the hybrid script can be configured to work with any number of automated tools (e.g., web presence testing automated tools available to those of ordinary skill in the art). A given automated tool parser can be configured to generate an output that can be used by a specific automated tool. Thus, the hybrid script can be combined with different automated tool parsers, and these various combinations can be used to implement customized tests via various different automated tools.

[0159] In some embodiments, the output of the automated tool parser can be used to generate a runtime script (e.g., used by an automated tool associated with the automated tool parser to implement a customized test). For example, the runtime script can be received by an automated tool (e.g., a cloud-based automated tool), and then the automated tool implements the customized test represented in the runtime script on the enterprise website. This implementation generates test results, which can be received and / or displayed in a user interface. For example, the test results can include the workflows defined in the workflow definition and / or the status of the individual steps of one of these workflows (e.g., passed, failed, skipped).

[0160] The features, structures, or characteristics of the present disclosure described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, throughout the specification, the use of the phrases "one embodiment", "some embodiments", "an embodiment", "certain embodiments", or other similar language means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present disclosure. Thus, the phrases "one embodiment", "some embodiments", "an embodiment", "certain embodiments", or other similar language that appear throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0161] Those of ordinary skill in the art will readily understand that the embodiments discussed above can be practiced with steps in a different order and / or with elements different from those disclosed in the configuration. Thus, while the present disclosure contemplates the embodiments outlined, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructs will be obvious while remaining within the spirit and scope of the present disclosure. Accordingly, reference should be made to the appended claims to determine the scope and bounds of the present disclosure.< / section> < / page>

Claims

1. A method for implementing a customizable enterprise automation testing framework, the method comprises: Receiving a workflow definition, a page structure definition, and a function definition for automated testing of an enterprise website, wherein the workflow definition defines one or more workflows including a series of steps for one or more test cases, the page structure definition defines web elements including multiple web pages of the enterprise website, and the function definition defines enterprise website-specific functions referenced by steps of the one or more workflows; Parsing the workflow definition, the page structure definition, and the function definition by a hybrid script parser to generate a hybrid script for automated testing; Parsing the hybrid script by an automation tool parser to generate an output of the automation tool; and Generating a runtime script based on the output from the automation tool parser, the runtime script being executed by the automation tool to generate an automated testing result, wherein the automation tool implements steps of the one or more workflows on the multiple web pages of the enterprise website to generate an automated testing result.

2. The method according to claim 1, further comprises: Receiving from a user a selection of one or more workflows in the workflow, wherein the hybrid script parser generates a hybrid script based on the selection of the workflow.

3. The method according to claim 2, wherein the workflow definition, the page structure definition, and the function definition each comprise a markup language document.

4. The method according to claim 3, wherein the markup language document is an Extensible Markup Language (XML) document.

5. The method according to claim 2, further comprises: Receiving from a user input data used by a first enterprise website-specific function among enterprise website-specific functions, wherein when the automation tool implements steps of the one or more workflows, at least one of the implementation steps includes invoking the first enterprise website-specific function and using the input data to generate an automated testing result.

6. The method according to claim 5, wherein the hybrid script generated by the hybrid script parser uses the first enterprise website-specific function and the input data to implement the at least one step.

7. The method according to claim 2, further comprises: Displaying a user interface of the selected workflow configured by the workflow definition, wherein a plurality of interface elements are dynamically displayed in the configured user interface based on steps of the selected workflow.

8. The method according to claim 7, wherein a user interface element for one step displayed on the user interface is configured to receive input data from a user.

9. The method according to claim 8, wherein the user interface is configured based on an Asynchronous JavaScript and XML (AJAX) call for the workflow definition.

10. The method according to claim 2, wherein the hybrid script is configured to be parsed by a plurality of automated tool parsers to generate an output, each automated tool parser being associated with a different automated tool, and a runtime script based on the output from each automated tool parser is configured to be used by the different automated tools to generate the results of the automated test.

11. The method according to claim 2, wherein the steps of the one or more workflows include default functions shared between different enterprise websites and enterprise-website-specific functions specific to the enterprise website associated with the function definition defined in the function definition.

12. The method according to claim 2, wherein the hybrid script includes default functions shared between different enterprise websites and enterprise-website-specific functions specific to the enterprise website associated with the function definition defined in the function definition.

13. The method according to claim 2, further comprising: receiving, via a user interface, an edit to the hybrid script from a user, wherein the parsing performed by the automated tool parser includes parsing the edited hybrid script to generate an output, and generating a runtime script based on the output from the automated tool parser includes generating a runtime script that is executed by the automated tool to generate the results of the automated test, the automated tool implementing the steps of the one or more workflows on the plurality of web pages of the enterprise website based on the edit to the hybrid script to generate the results of the automated test.

14. The method according to claim 13, wherein the edited hybrid script results in a customized automated test for the enterprise website.

15. A system for implementing a customizable enterprise automation test framework, the system comprising: a processor; and a memory storing instructions executed by the processor, the instructions configuring the processor to: receive a workflow definition, a page structure definition, and a function definition for an automated test of an enterprise website, wherein the workflow definition defines one or more workflows for one or more test cases comprising a series of steps, the page structure definition defines web elements including a plurality of web pages of the enterprise website, and the function definition defines enterprise-website-specific functions referenced by the steps of the one or more workflows; parse the workflow definition, the page structure definition, and the function definition by a hybrid script parser to generate a hybrid script for the automated test; parse the hybrid script by an automated tool parser to generate an output of the automated tool; and generate a runtime script based on the output from the automated tool parser, the runtime script being executed by the automated tool to generate the results of the automated test, wherein the automated tool implements the steps of the one or more workflows on the plurality of web pages of the enterprise website to generate the results of the automated test.

16. The system according to claim 15, wherein the instructions further configure the processor to: Receive a selection of one or more workflows in a workflow from a user, wherein the hybrid script parser generates a hybrid script based on the selection of the workflow.

17. The system of claim 16, wherein the instructions further configure the processor to: Receive input data used by a first enterprise website-specific function among functions specific to an enterprise website from the user, wherein when the automation tool implements steps of the one or more workflows, implementing at least one of the steps includes invoking the first enterprise website-specific function and using the input data to generate a result of an automated test.

18. The system of claim 17, wherein the hybrid script generated by the hybrid script parser uses the first enterprise website-specific function and the input data to implement the at least one step.

19. The system of claim 16, wherein the instructions further configure the processor to: Display a user interface of the selected workflow configured by the workflow definition, wherein a plurality of interface elements are dynamically displayed in the configured user interface based on steps of the selected workflow.

20. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to implement a customizable enterprise automation test framework, wherein the instructions, when executed, cause the processor to: Receive a workflow definition, a page structure definition, and a function definition for an automated test of an enterprise website, wherein the workflow definition defines one or more workflows for one or more test cases including a series of steps, the page structure definition defines web elements including a plurality of web pages of the enterprise website, and the function definition defines enterprise website-specific functions referenced by steps of the one or more workflows; Parse the workflow definition, the page structure definition, and the function definition by a hybrid script parser to generate a hybrid script for an automated test; Parse the hybrid script by an automation tool parser to generate an output of the automation tool; And Generate a runtime script based on the output from the automation tool parser, the runtime script being executed by the automation tool to generate a result of an automated test, wherein the automation tool implements steps of the one or more workflows on the plurality of web pages of the enterprise website to generate a result of an automated test.

21. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to implement a customizable enterprise automation test framework, wherein the instructions, when executed, cause the processor to perform the method according to any one of claims 2-12.

22. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1-12.

Images