Keyword-based UI automatic architecture and execution method

Abstract

The invention relates to the technical field of front-end computers, discloses a front-end automatic execution structure, and particularly relates to a keyword-based UI (User Interface) automatic architecture and an execution method. By following a keyword-driven model, parameterization and data driving are realized, templating and multiplexing are advocated, strict review and version control are implemented, a test team can compile a high-quality, easy-to-maintain and high-coverage test case, and smooth proceeding of an automatic test is effectively supported. Test case data management and maintenance are visual and convenient, a student with a good programming basis participates in underlying method packaging, a student with a weak programming basis participates in case data writing, and the overall automatic test efficiency of a team is improved.

Description

Technical Field

[0001] The present invention relates to the field of front-end computer technology, and is a front-end automation execution structure, and in particular to a keyword-based UI automation architecture and execution method. Background Art

[0002] In the existing open source UI automation frameworks, there are certain requirements for testers to program and there is a certain degree of learning difficulty. The following are some common UI automation frameworks.

[0003] Visual Basic+QTP Framework:

[0004] Testers are required to understand Visual Basic object-oriented syntax, the recording, modification, debugging, and playback of the QTP tool. There are certain requirements for testers' VB writing. In addition, QTP is commercial software that needs to be purchased, which is costly for medium and large companies.

[0005] Java+selenium+TestNG framework:

[0006] Testers are required to be familiar with Java syntax, object-oriented methods, and the TestNG framework. There are certain requirements for testers' Java programming. It is difficult to learn and start, and there is a certain degree of difficulty in promotion. Summary of the invention

[0007] In order to solve the above technical problems, the embodiment of the present application provides a keyword-based UI automation architecture and execution method, which is applied to computer testing. It can separate the test method and data, and the test case data management and maintenance are more intuitive and convenient, thereby improving the overall automated testing efficiency of the team.

[0008] In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0009] In a first aspect, a keyword-based UI automation architecture is provided, the architecture comprising: an encapsulation module, for encapsulating commonly used page element operation methods based on an encapsulation method, the encapsulation method comprising obtaining object properties, obtaining window size, and encapsulating based on an example assertion method; a control logic execution module, for reading a use case execution summary table, obtaining the use case number to be executed, saving the execution number in a list, and then reading the use case files one by one, reading the test case step data, assembling the execution parameters, calling the corresponding execution method to execute, and recording the execution log of each step and the execution result of each use case; a use case step writing module, for obtaining keywords and corresponding parameters for the use case steps based on a keyword-driven model, and writing based on the keywords and the parameters, specifically comprising writing parameters for each of the use case steps, and updating the use case execution summary table.

[0010] Furthermore, the execution result of each of the use cases includes a failure of the use case execution. When the use case execution fails, it is executed again based on a preset number of runs.

[0011] Furthermore, obtaining the use case number to be executed and saving the execution number in a list includes: traversing the use case master table data, filtering out the use cases to be executed according to the execution tags, storing the use case numbers of the load reduction conditions into the use case master table, and sorting the filtered use cases according to the execution priority field in the use case master table, and executing them in sequence based on the sorting results.

[0012] Furthermore, the assembly of execution parameters includes: based on the established mapping table between keywords and actual execution methods, searching the mapping table based on keywords to obtain corresponding execution methods; extracting parameter values, and performing type conversion on the parameter values ​​based on the execution method, and assembling the keywords, the converted parameter values, and the context information into the parameter structure required for the execution method.

[0013] Furthermore, the call to the corresponding execution method is executed to record the execution log of each step and the execution result of each use case, including: searching and calling the corresponding execution plan according to the keywords in the step data, and executing based on the assembled execution parameters. For each of the execution processes, the execution status, time-consuming data, and execution details are recorded and stored in the corresponding data structure.

[0014] Furthermore, the keyword-driven model defines multiple common and representative operation keywords according to business needs and usage scenarios, and defines unique parameters, parameter types and parameter quantities for each keyword, and the unique parameters, parameter types and parameter quantities are consistent with the requirements of the corresponding execution method.

[0015] Furthermore, the use case is composed of multiple keywords and parameters of the keywords, and a complete execution process is constructed through logical sequence and conditional statements.

[0016] Furthermore, when the use case fails to execute, it is executed again based on a preset number of reruns, including: when the use case fails to execute, if the number of reruns is greater than 0, entering the rerun process and updating the number of reruns based on the rerun interval; entering the rerun process and updating the number of reruns based on the rerun interval, including: pausing the rerun to a specified time based on the rerun interval before performing the next rerun; updating the final state of the use case according to the execution result of the use case after the rerun, when the rerun is successful and the original failed step state is updated, when the rerun fails, retaining the original failure information.

[0017] In a second aspect, a keyword-based UI automation execution method is provided, which is implemented based on the automation architecture described in any of the above items, and the method includes: reading the execution file master table, determining the execution scope and saving the use case number to be executed; reading the single use case file data, the use case step data in turn, and reading the parameters in each step; calling the encapsulated method to execute each step until all steps of the single use case are completed, and recording the execution log and execution results of the use case execution; based on the above processing process, all the use cases are executed.

[0018] Furthermore, when the execution of the step fails, it is determined whether repeated execution is required based on the set execution mechanism. If repeated execution is required, a second execution is performed. If repeated execution is not required, the execution is terminated and the execution log and execution results are recorded.

[0019] According to a third aspect, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the keyword-based UI automation execution method described in any one of the above items is implemented.

[0020] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the keyword-based UI automation execution method described in any one of the above is implemented.

[0021] In the technical solution provided by the embodiment of the present application, by following the keyword-driven model, implementing parameterization and data-driven, advocating templates and reuse, and implementing strict review and version control, the test team can write high-quality, easy-to-maintain, and high-coverage test cases, effectively supporting the smooth progress of automated testing. Test case data management and maintenance are relatively intuitive and convenient. Students with a good programming foundation participate in the encapsulation of the underlying methods, and students with a weaker programming foundation participate in the writing of use case data, thereby improving the overall automated testing efficiency of the team. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0023] The methods, systems and / or programs in the accompanying drawings will be further described according to exemplary embodiments. These exemplary embodiments will be described in detail with reference to the drawings. These exemplary embodiments are non-limiting exemplary embodiments, wherein example numbers represent similar mechanisms in the various views of the accompanying drawings.

[0024] Figure 1 It is a schematic diagram of the keyword-based UI automation architecture structure provided in an embodiment of the present application.

[0025] Figure 2 It is a flowchart of a keyword-based UI automation execution method provided in an embodiment of the present application.

[0026] Figure 3 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to better understand the above technical scheme, the technical scheme of the present application is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical scheme of the present application, rather than limitations on the technical scheme of the present application. In the absence of conflict, the embodiments of the present application and the technical features in the embodiments can be combined with each other.

[0028] In the following detailed description, numerous specific details are set forth by way of example in order to provide a comprehensive understanding of the relevant guidance. However, it will be apparent to those skilled in the art that the present application may be practiced without these details. In other cases, well-known methods, procedures, systems, compositions and / or circuits have been described at a relatively high level, without detail, in order to avoid unnecessarily obscuring aspects of the present application.

[0029] Flowcharts are used in the present application to illustrate the execution process performed by the system according to the embodiment of the present application. It should be clearly understood that the execution process of the flowchart may not be performed in order. On the contrary, these execution processes may be performed in reverse order or simultaneously. In addition, at least one other execution process may be added to the flowchart. One or more execution processes may be deleted from the flowchart.

[0030] Before further describing the embodiments of the present invention in detail, the nouns and terms involved in the embodiments of the present invention are described. The nouns and terms involved in the embodiments of the present invention are subject to the following interpretations.

[0031] (1) In response, it is used to indicate the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more operations executed may be in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations executed are executed.

[0032] (2) Based on is used to indicate the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more operations executed may be in real time or have a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations executed are executed.

[0033] See also Figure 1 The embodiment of the present application provides an automation architecture 100 suitable for testing, which can realize the separation of test methods and data. The architecture specifically includes a packaging module 110, a control logic execution module 120 and a use case step writing module 130.

[0034] Among them, the encapsulation module is used to encapsulate the commonly used page element operation methods based on the encapsulation method, and the encapsulation method includes obtaining object properties, obtaining window size, and encapsulating based on the example assertion method.

[0035] Specifically, the commonly used page element operation methods are encapsulated: such as single click, input, double click, right click, drag, scroll bar scroll, mouse hover, multiple window recognition, multiple window switching, multiple frame recognition, switching between multiple frame recognition, file upload, pop-up window processing. The encapsulation method is encapsulated using public methods, specifically obtaining object properties, obtaining window size, use case assertion method encapsulation, such as comparing whether the text attribute of an object is equal to the expected attribute value, comparing whether the clickable attribute of an object is consistent with the expected value, etc., and logging method encapsulation.

[0036] The following is a detailed description of the above page element operation method encapsulation.

[0037] When building a keyword-driven Python UI automated testing framework, encapsulating page element operation methods is the cornerstone for improving the readability and maintainability of test scripts and simplifying test case writing. The specific technical details of this link are as follows:

[0038] Regarding the click operation, its encapsulation purpose is to provide a unified click processing mechanism for various clickable elements (such as buttons, links, check boxes, radio buttons, etc.) in the browser or application. The algorithm description for this process is: Locate the element: Use the location strategy provided by SeleniumWebDriver (such as XPath, CSS selector, ID, etc.) to find the target element to be clicked. This step should ensure the uniqueness of the element to avoid runtime errors caused by locating multiple elements. Interactivity check: After successfully locating the element, call the `is_enabled()` and `is_displayed()` methods to determine whether the element is in a clickable state and visible in the current window. If the element is not interactive or invisible, an exception is thrown and relevant information is recorded. Execute the click: Call the `click()` method on the element that passes the above check to simulate a user click operation. During the execution process, possible exceptions (such as StaleElementReferenceException, ElementClickInterceptedException, etc.) should be monitored, and appropriate error handling and logging should be performed.

[0039] Regarding the input operation, the purpose of its encapsulation is to standardize the text input process of editable elements such as input boxes and text fields to ensure consistency across platforms and browsers. The algorithm is described as follows: The positioning element uses the same positioning strategy as the click operation to find the target element for the text to be entered to ensure the uniqueness of the element. Clear the original text: Decide whether to clear the existing text in the element first based on the needs. If you choose to clear, call the `clear()` method to complete the operation. Send text input: Use the `send_keys()` method to send the specified keyboard input to the located element. This method should be able to correctly handle complex input scenarios such as regular characters, special characters, and key combinations. Exception handling: Like the click operation, possible exceptions should also be monitored during the input operation, such as elements that are not interactive, input timeouts, etc., and corresponding error handling and logging should be performed.

[0040] The purpose of the double-click operation is to simulate a user double-clicking on a specific element. It is suitable for scenarios where a double-click event needs to be triggered, such as map zooming, table row selection, etc. The algorithm is described as follows: Locate the element: Use the same positioning strategy as the single-click operation to find the target element to be double-clicked. Execute double-click: Use the ActionChains class provided by Selenium WebDriver to build a double-click action chain. After creating an ActionChains instance, call its `double_click()` method to double-click the target element. During this process, attention should be paid to abnormal monitoring and handling.

[0041] The purpose of encapsulating the right-click operation is to simulate the user triggering the right-click menu on a specific element, so as to facilitate testing the functions or options associated with the right-click. Algorithm description: Locate the element: Use the same positioning strategy as the single-click operation to find the target element to be right-clicked. Execute the right-click: Also use the ActionChains class to build an action chain. After creating the instance, call the `context_click()` method to execute the right-click on the target element. This step needs to include exception monitoring and handling logic.

[0042] Regarding the drag operation, its encapsulation purpose is: to simulate the user performing a drag action on the page, which is used to test scenarios involving drag interactions such as drag sorting, file uploading, and map panning. Algorithm description: Locate the source element and the target element: Use the positioning strategy to find the source element and the target element of the drag operation respectively. Build a drag action chain: Use the ActionChains class to create an instance, and call the `click_and_hold()` (press the left mouse button on the source element), `move_to_element()` (move the mouse to the target element position), and `release()` (release the left mouse button) methods in sequence to build a complete drag action chain. Exception handling: During the entire drag process, monitor and handle possible exceptions, such as failure to locate elements, changes in element status during dragging, etc., to ensure the stability and traceability of the test process.

[0043] About the scroll bar The purpose of the scroll encapsulation is to realize the automatic control of the page scroll bar, so as to test the long pages, infinite scrolling lists and other interfaces that need to be scrolled. Algorithm description: Determine the scroll direction and distance: According to the test requirements, determine the scroll direction (up, down, to the top, to the bottom, etc.) and the scroll distance (pixel value or percentage). Perform the scroll operation: According to the scroll direction and distance, select the appropriate method to scroll. For vertical scrolling, you can use the `execute_script()` method to execute JavaScript code (such as `window.scrollTo()` or `element.scrollTop`) to achieve scrolling; for horizontal scrolling, you can adjust the `scrollLeft` attribute of the element. Ensure that the page status is updated after the scrolling operation is completed. Wait for the page to load and the element to appear: The scrolling operation may cause dynamic loading of content or the appearance of new elements. Therefore, a reasonable waiting strategy (such as explicit waiting, implicit waiting or expected conditions) should be set after scrolling to ensure that the page is loaded and the required elements are visible.

[0044] The purpose of the mouse hover encapsulation is to simulate the user hovering the mouse pointer over a specific element, triggering the relevant hover effect or pop-up menu. Algorithm description: Locate the element: Use the same positioning strategy as the click operation to find the target element to be hovered. Perform the hover operation: Use the ActionChains class to create an instance and call the `move_to_element()` method to move the mouse over the target element. To ensure that the hover effect is triggered, you can set an appropriate mouse hovering time as needed. Exception handling: Monitor and handle possible exceptions during the hover process, such as element positioning failure, hover effect failure, etc.

[0045] Regarding multi-window identification and switching, its encapsulation purpose: to support automated testing of multi-window environments, including identifying newly opened windows, switching back to the main window, and switching between multiple windows. Algorithm description: Window management: Use the `current_window_handle` attribute of WebDriver to obtain the handle of the currently active window, and the `window_handles` attribute to obtain the handle list of all opened windows. By comparing the handle information, newly opened windows, main windows, and other known windows can be identified. Window switching: Call the `switch_to.window()` method, pass in the target window handle, and switch between windows. The window handle information before and after the switch should be properly recorded to facilitate tracking and debugging of the test process.

[0046] About multi-frame identification and switching Its encapsulation purpose: Supports automated testing of web pages containing iframe (nested frame) structures, including identifying nested frames, switching to target frames, and returning to parent frames. Its algorithm description: Frame identification and management: Use the `driver.switch_to.frame()` method to pass in the iframe element or its handle, and switch to the target frame for operation. Call the `driver.switch_to.parent_frame()` method to return to the previous frame or parent frame. Return to the top-level document (root frame) through the `driver.switch_to.default_content()` method. Frame positioning: Use positioning strategies similar to ordinary elements (such as XPath, CSS selectors, etc.) to locate nested frame elements. After locating the iframe element, pass it as a parameter to the `switch_to.frame()` method for switching. Exception handling: During the frame switching process, possible exceptions should be monitored and handled, such as frame not found, frame switching failure, etc., to ensure the stability and traceability of the test process.

[0047] Regarding file upload, its encapsulation purpose is to automate the file upload operation, support the selection of local files and submit them to the file input control on the web page. Algorithm description: Locate the file input element: Use the conventional positioning strategy to find the file input (type="file") element. Simulate file selection: Directly set the `send_keys()` method of the file input element, pass in the local file path, and simulate the user's operation of selecting a file. Note that the path should meet the requirements of the operating system (such as Windows uses backslashes `\`, and Unix-like systems use forward slashes ` / `). Submit the file: After simulating the file selection, it is usually necessary to trigger the click event of the relevant submit button to complete the file upload process. Use the encapsulated click operation method to complete this step. Verify the upload result: According to business needs, verify the page status changes, file list updates, file content verification, etc. after the file is uploaded to ensure that the upload operation is successful.

[0048] Regarding pop-up window processing, its encapsulation purpose is to automatically identify and process various types of pop-up windows (such as alert, confirm, prompt), ensure that the test process is not disturbed by pop-up windows, and verify the content and behavior of pop-up windows. Algorithm description: Pop-up window identification: Use the `switch_to.alert()` method of WebDriver to obtain the currently activated pop-up window object. This method will throw NoAlertPresentException when there is no pop-up window, so exception handling is required. Pop-up window operation: Accept / confirm pop-up window: For pop-up windows that only need to be confirmed (such as alert, some confirm), call the `accept()` method of the pop-up window object to simulate the user clicking the "OK" or "Accept" button. Cancel pop-up window: For pop-up windows that allow cancellation (such as some confirm, prompt), call the `dismiss()` method of the pop-up window object to simulate the user clicking the "Cancel" button. Enter pop-up window text: For prompt type pop-up windows, call the `send_keys()` method of the pop-up window object, enter the specified text into the pop-up window, and then confirm the input through the `accept()` method. Pop-up content verification: Before or after processing a pop-up, you may need to verify the pop-up title (obtained through the `text` property) and message content (same as the `text` property). This information can be used to confirm that the pop-up content is consistent with expectations and ensure comprehensive test coverage. Exception handling: During the pop-up operation, possible exceptions should be monitored and handled, such as pop-up not found, pop-up operation failure, etc., to ensure the stability and traceability of the test process.

[0049] The control logic execution module is used to read the use case execution summary table, obtain the use case number to be executed, save the execution number in a list, read the use case files one by one, read the test case step data, assemble the execution parameters, call the corresponding execution method to execute, and record the execution log of each step and the execution result of each use case.

[0050] In the embodiment of the present application, the use case execution summary table is a test case execution summary table, wherein the test case execution summary table is a master control file for test execution, and is used to store information of all use cases to be executed, including use case number, name, keyword, parameter, execution priority, whether to execute flag, etc. The execution control logic needs to have the ability to read, parse and manage the summary table.

[0051] Read the execution summary table of use cases by using Python built-in or third-party libraries (such as pandas) to read the execution summary table stored in CSV, Excel, database tables, etc. Ensure that the data is loaded correctly and completely. Traverse the summary table data and filter out the use cases that should be executed in this test according to the "execution flag" (such as Y / N). Store the numbers of the use cases that meet the conditions in a list for use in subsequent steps. And sort the filtered use cases according to the execution priority field in the summary table to ensure that high-priority use cases are executed first. If necessary, support custom sorting rules.

[0052] For each use case to be executed, the execution control logic needs to load its detailed step data, including keywords, parameters, expected results, etc. This data is usually stored in a separate use case file and associated with the execution summary table.

[0053] Specifically, for the associated use case files, find the corresponding use case files (such as XML, JSON, and YAML formats) according to the use case numbers in the execution summary table. Ensure that the file path is correct and accessible. Use the corresponding Python library (such as xml.etree.ElementTree, json, and yaml) to load and parse the use case files and extract the detailed information of each step. Only load the step data whose "execution flag" is Y to achieve the reading and parsing of the step data. Perform necessary preprocessing on the loaded step data, such as variable replacement, parameter calculation, dependency checking, etc., to ensure that the data is ready for execution method calls.

[0054] Among them, for the assembly of execution parameters, according to the loaded use case step data, the execution control logic needs to assemble keywords, parameters and other information into a parameter list or dictionary that can be called by the execution method. The acquisition of keywords is implemented through the mapping method, by establishing a mapping relationship between keywords and actual execution methods. When encountering keywords in the use case steps, look up the mapping table to obtain the corresponding execution method. Regarding parameter extraction and conversion, by extracting parameter values ​​from the step data, type conversion (such as string to integer, floating point number, Boolean value, etc.) or formatting (such as date, timestamp, etc.) is performed according to the requirements of the execution method. After the above two processes are processed, the keywords, converted parameter values ​​and other necessary context information (such as global variables, test data, etc.) are assembled into the parameter structure (such as list, dictionary, etc.) required for the execution method.

[0055] Regarding calling the corresponding execution method, execute and record the execution log of each step and the execution result of each use case. For calling the execution method, find and call the corresponding execution method according to the keywords in the step data. Pass in the assembled parameters to perform page element operations or other test actions. For result verification and assertion, the result verification is performed inside the execution method or outside the execution control logic, and the encapsulated assertion method is used to compare the actual result with the expected result. The assertion method should support multiple comparison operations (such as equal, not equal, contain, match regular expressions, etc.). Among them, the step result record records the execution status (pass / fail / skip), time consumption, execution details (such as operation, parameters, actual result, expected result, assertion information, etc.) of each executed step, and any generated exception information. This information should be saved in a data structure (such as a list, dictionary, database record) that is easy to query and analyze. Then, based on the results of each step, summarize the execution result (pass / fail / skip) of the entire use case. Record the start time, end time, total time consumption, step details, and any global exception information of the use case.

[0056] The execution result of each use case includes the failure of the use case execution. When the use case execution fails, it is executed again based on the preset number of reruns. Check the execution result of the use case. If it fails and the number of reruns is greater than 0, enter the rerun process. Update the number of reruns. If the rerun interval is set, the execution control logic should pause for a specified time before executing the next rerun. Fixed intervals and random intervals are supported. Re-executing the entire use case includes loading step data, assembling parameters, calling execution methods, and recording results. During the rerun process, the original step failure information is maintained, and relevant records of the rerun attempt are added. Finally, according to the execution result of the use case after the rerun, the final status of the use case is updated. If the rerun is successful, the status of the original failed step is updated; if the rerun still fails, the original failure information is retained.

[0057] The log level setting in the log record supports at least four log levels (DEBUG, INFO, WARNING, ERROR), and the log output level can be configured according to the needs. And log information is recorded by using Python built-in or third-party logging libraries (such as logging). Each log should contain timestamp, log level, source (such as use case name, step number), message content and other information to achieve log output. For any exceptions that occur, complete stack trace information should be recorded to facilitate locating the source of the problem. Logs should be archived by date, test task and other dimensions, and support querying, filtering and analyzing log data through log viewing tools or interfaces.

[0058] The execution of the above architecture is implemented based on the use case step writing module, in which the use case step writing module is equipped with a keyword-driven model. The keyword-driven model is the core concept of the framework. By decomposing complex test logic into a series of easy-to-understand keywords and their parameters, the threshold for writing test cases is lowered and the reusability of test scripts is improved.

[0059] Specifically, for keywords, a series of common and representative operation keywords are defined according to business needs and test scenarios, such as "click_button", "input_text", "verify_element_text", etc. Each keyword should correspond to the encapsulated method in the framework. The keyword parameters define the necessary parameters for each keyword, and the parameter type and quantity should be consistent with the requirements of the corresponding execution method. The parameters should be concise and clear, reflecting the essence of the operation, such as element locators, input text, expected results, etc. The keyword combination is a test case composed of multiple keywords and their parameters, and a complete test process is constructed through logical sequence and conditional statements (such as if-else, for loops). The connection between keywords should be natural and smooth, and conform to the business operation logic.

[0060] Among them, the use case step description is the specific implementation of the test case, which organizes keywords and their parameters into orderly test steps, and details how to verify specific functions or scenarios. The algorithm process for this process includes: Step numbering: Give each test step a unique number for easy tracking and reference. The numbering rules should be consistent, such as consecutive numbers, alphabetical numbers, etc. Step description: Clearly describe the operations to be performed in each step, use defined keywords and fill in the corresponding parameters. The step description should be concise, accurate, and avoid redundant information. Expected results: For steps of verification nature, clearly describe the expected output or results. The expected results should correspond to the comparison logic of the assertion method to ensure the effectiveness of the test. Comments and documentation: Add necessary comments to key steps to explain the purpose of the operation, business background, precautions and other information. Maintaining good documentation habits is conducive to team collaboration and later maintenance. The above process is implemented using parameterization and data-driven methods. Parameterization and data-driven are effective means to improve the flexibility and coverage of test cases, and provide dynamic input for test steps through external data sources. The algorithm process includes: Parameterization: abstract the parts of the test steps that may change (such as user names, passwords, search keywords, etc.) into parameters and use placeholders (such as ${param_name}) to represent them. During execution, the execution control logic obtains the actual value from the data source (such as Excel, CSV, database) to replace the placeholder. Data-driven: associate one or more data sets with the test case, each of which contains a set of parameter values. During execution, the framework uses each row of data in the data set in turn to execute the entire use case, realizing batch execution and multi-scenario coverage of the use case. Dataset management: provides a convenient way to manage data sets, including creation, editing, import and export, version control, etc. Supports operations such as filtering, merging, and splitting of data sets to meet different testing needs.

[0061] In an embodiment of the present application, by defining a use case template and implementing step reuse, repetitive work is reduced and the efficiency of writing test cases is improved. Wherein the use case template creates a general test case template according to the business field or functional module. The template contains a typical sequence of operations and verification points, and a complete use case can be generated by filling in specific parameters. In step reuse, it supports referencing other defined steps in the use case to achieve step-level reuse. The reused steps can be within the same use case or across use cases. When referencing, parameters can be passed or some attributes can be overwritten. Modular design encourages the organization of associated test steps into modules (such as login modules, search modules), and the modules are highly encapsulated and reused internally, and only need to be called externally through interfaces. Modules should support configuration and expansion to adapt to business changes.

[0062] In the embodiment of the present application, the quality of the test case is ensured by the use case review, and the change history of the use case is tracked through version control to ensure the security and integrity of the test assets. Among them, the use case review formulates the use case review standards and processes, including format specifications, clear logic, and comprehensive coverage. Regularly organize review meetings, invite relevant personnel (such as testers, developers, and business personnel) to participate, and review and optimize the use cases. And use a version control system (such as Git) to manage the test case files, and record the author, time, reason, and other information of each modification. Support branch management, merge requests, and rollback operations of use cases to facilitate team collaboration and problem tracing. Also by incorporating test cases into the continuous integration process, whenever there is a new submission in the code base, the use case execution is automatically triggered, and the results are fed back to the relevant personnel. Timely discovery of regression problems ensures that code changes are updated synchronously with test cases.

[0063] In the embodiment of the present application, the test method and data are separated by the above architecture, and standardized, flexible and efficient automation operations on the elements of the browser or application interface are realized. These methods cover scenes from basic single-click, input, double-click, right-click operations to complex drag, scroll, hover, window / frame switching, file upload and pop-up window processing, providing testers with a rich and easy-to-use tool set, greatly improving the efficiency and quality of UI automation testing. In practical applications, these encapsulation methods are closely combined with execution control logic, test case step writing and other links, and together constitute a fully functional and highly customizable automation testing framework. As a key component of the automation testing framework, the execution control logic is responsible for the overall scheduling of the case execution, step data management, parameter assembly, result verification, re-run control and logging, etc., to ensure the efficient execution of the test process and the accurate recording of the results. Through the careful design and implementation of the execution control logic, the test team can better control complex test scenarios and improve the stability and credibility of the automated test. The test case step writing link plays a connecting role in the keyword-driven Python UI automation framework. It converts business requirements into specific test operations and guides the execution control logic to execute the test process. By following the keyword-driven model, implementing parameterization and data-driven, advocating templates and reuse, and implementing strict review and version control, the test team can write high-quality, easy-to-maintain, high-coverage test cases to effectively support the smooth progress of automated testing. Test case data management and maintenance are relatively intuitive and convenient. Students with a good programming foundation can participate in the encapsulation of underlying methods, and students with a weaker programming foundation can participate in the writing of test case data, which improves the overall efficiency of the team's automated testing.

[0064] Based on the above architecture, see Figure 2 , a specific automated execution method is proposed, which specifically includes the following steps:

[0065] Step S210. Read the execution file summary table, determine the execution scope and save the use case number to be executed.

[0066] Step S220. Read the single use case file data, use case step data in sequence, and read the parameters in each step.

[0067] Step S230: Call the encapsulated method to execute each step until all steps of the single use case are completed, and record the execution log and execution results of the use case.

[0068] Step S240: Complete the execution of all the use cases based on the above processing procedure.

[0069] See also Figure 3 , the above method can also be integrated into the provided electronic device 300. In view of the fact that the device may have relatively large differences due to different configurations or performances, it can include one or more processors 301 and memory 302, and the memory 302 can store one or more storage applications or data. Among them, the memory 302 can be a temporary storage or a permanent storage. The application stored in the memory 302 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the electronic device. Furthermore, the processor 301 can be configured to communicate with the memory 302, and the electronic device executes a series of computer executable instructions in the memory 302. The electronic device may also include one or more power supplies 303, one or more wired / wireless network interfaces 304, one or more input / output interfaces 305, one or more keyboards 306, etc.

[0070] In a specific embodiment, the electronic device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer executable instructions for the electronic device, and the one or more programs configured to be executed by one or more processors include the following computer executable instructions:

[0071] Read the execution file summary table, determine the execution scope and save the use case number to be executed; read the single use case file data, use case step data in sequence, and read the parameters in each step;

[0072] Call the encapsulated method to execute each step until all steps of the single use case are completed, and record the execution log and execution results of the use case;

[0073] Based on the above processing procedure, all the use cases are executed to completion.

[0074] The following is a detailed introduction to the various components of the processor:

[0075] In this embodiment, the processor is an application specific integrated circuit (ASIC), or is configured to implement one or more integrated circuits of the embodiments of the present application, such as one or more microprocessors (digital signal processors, DSP), or one or more field programmable gate arrays (field programmable gate arrays, FPGA).

[0076] Optionally, the processor may execute various functions by running or executing a software program stored in the memory and calling data stored in the memory, such as executing the above-mentioned Figure 3 The method shown.

[0077] In a specific implementation, as an embodiment, the processor may include one or more microprocessors.

[0078] Among them, the memory is used to store the software program that executes the solution of the present application, and the execution is controlled by the processor. The specific implementation method can refer to the above method embodiment and will not be repeated here.

[0079] Optionally, the memory may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may be integrated with the processor, or may exist independently and be coupled to the processing unit through the interface circuit of the processor, and the embodiments of the present application do not specifically limit this.

[0080] It should be noted that the structure of the processor shown in this embodiment does not constitute a limitation on the device, and the actual device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0081] In addition, the technical effects of the processor can refer to the technical effects of the method described in the above method embodiment, which will not be repeated here.

[0082] It should be understood that the processor in the embodiments of the present application may be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0083] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0084] The above embodiments can be implemented in whole or in part by software, hardware (such as circuits), firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0085] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can be represented by: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0086] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0087] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0088] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0089] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0090] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0091] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0092] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks or optical disks.

[0093] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A keyword-based UI automation architecture, characterized in that: The architecture includes: An encapsulation module is used to encapsulate common page element operation methods based on an encapsulation method, wherein the encapsulation method includes obtaining object attributes, obtaining window size, and encapsulating based on an example assertion method; The control logic execution module is used to read the use case execution summary table, obtain the use case number to be executed, save the execution number in the list, read the use case files one by one, read the test case step data, assemble the execution parameters, call the corresponding execution method to execute, and record the execution log of each step and the execution result of each use case; The use case step writing module is used to obtain keywords and corresponding parameters for the use case steps based on the keyword-driven model, and write based on the keywords and the parameters, specifically including writing parameters for each use case step and updating the use case execution summary table.

2. The keyword UI automation framework according to claim 1, characterized in that: The execution result of each of the use cases includes a failure of the use case execution. When the use case execution fails, it is executed again based on a preset number of runs.

3. The keyword-based UI automation framework according to claim 1, characterized in that: The method of obtaining the use case number to be executed and saving the execution number in a list includes: traversing the use case master table data, filtering out the use cases to be executed according to the execution tags, storing the use case numbers of the load reduction conditions in the use case master table, and sorting the filtered use cases according to the execution priority field in the use case master table, and executing them in sequence based on the sorting results.

4. The keyword-based UI automation framework according to claim 3, characterized in that: The assembling execution parameters includes: based on a mapping table between established keywords and actual execution methods, searching the mapping table based on keywords to obtain corresponding execution methods; extracting parameter values, and performing type conversion on the parameter values ​​based on the execution method, and assembling the keywords, the converted parameter values, and context information into a parameter structure required for the execution method.

5. The keyword-based UI automation framework according to claim 4, characterized in that: The call corresponding to the execution method is executed, and the execution log of each step and the execution result of each use case are recorded, including: according to the keywords in the step data, searching and calling the corresponding execution plan, and executing based on the assembled execution parameters. For each of the execution processes, its execution status, time-consuming data, and execution details are recorded and stored in the corresponding data structure.

6. The keyword-based UI automation framework according to claim 5, characterized in that: The keyword-driven model defines multiple common and representative operation keywords based on business needs and usage scenarios, and defines unique parameters, parameter types and parameter quantities for each keyword. The unique parameters, parameter types and parameter quantities are consistent with the requirements of the corresponding execution method.

7. The keyword-based UI automation framework according to any one of claims 1 to 6, characterized in that: The use case consists of multiple keywords and parameters of the keywords, and a complete execution flow is constructed through logical sequence and conditional statements.

8. The keyword-based UI automation framework according to claim 2, characterized in that: When the use case fails to execute, it is executed again based on a preset number of reruns, including: when the use case fails to execute, if the number of reruns is greater than 0, entering the rerun process and updating the number of reruns based on the rerun interval; entering the rerun process and updating the number of reruns based on the rerun interval, including: pausing the rerun to a specified time based on the rerun interval before performing the next rerun; updating the final state of the use case according to the execution result of the use case after the rerun, when the rerun is successful and the original failed step state is updated, when the rerun fails, retaining the original failure information.

9. A keyword-based UI automation execution method, characterized in that: The method is implemented based on the automation architecture according to any one of claims 1 to 8, and includes: Read the execution file summary table, determine the execution scope and save the use case number to be executed; Read a single use case file data, use case step data, and read the parameters in each step in sequence; Call the encapsulated method to execute each step until all steps of the single use case are completed, and record the execution log and execution results of the use case; Based on the above processing procedure, all the use cases are executed to completion.

10. The keyword-based UI automation execution method according to claim 9, characterized in that: When the execution of the step fails, it is determined whether it needs to be repeated based on the set execution mechanism. If repeated execution is required, a second execution is performed. If repeated execution is not required, the execution is terminated and the execution log and execution results are recorded.

Images