CN115185852A - UI automation testing method and system, computer equipment - Google Patents

Abstract

The present application provides an automated UI testing method, including: loading an automatic testing behavior script, where the automatic testing behavior script includes a preset path and a calling interface; obtaining a preset xml file according to the preset path, and the preset xml file includes several step nodes, The step node includes one or several subnodes, each subnode includes a preset attribute value, and the preset attribute value includes operation parameters; the corresponding UI interface to be tested is called and loaded according to the calling interface; the execution step node is triggered on the UI interface to be tested. corresponding operations; and generating a test report based on the execution results of the operations. In addition, the present application also provides a UI automation testing system and computer equipment. The UI automated testing method provided by the present application makes the UI automated testing simple and easy to implement, thereby improving the testing efficiency.

Description

UI automation testing method and system, computer equipment

technical field

The present application relates to the field of computer technology, and in particular, to a UI automation testing method, system, and computer equipment.

Background technique

Software testing is an integral part of the software development process. Both development and testing require tools to assist software testing to improve software quality. Among them, UI (user interface) automation plays a pivotal role as an operation that simulates user interface behavior. There are many kinds of execution script frameworks currently tested, such as: appium script framework, calabash script framework, IOS UIAutomation script framework, robotium script framework, etc. Each framework has its own writing specifications and environment, and corresponding scripts need to be written. Most of the current UI automation requires the tester to write the corresponding script according to the writing specification of the corresponding framework, which has certain requirements on the tester's skills and requires the tester to have a certain language coding ability. With the upgrade of the corresponding framework, testers also need to perform targeted maintenance on historical scripts. If there are many scripts involved, the maintenance cost will increase accordingly.

SUMMARY OF THE INVENTION

In view of this, it is necessary to provide a UI automation testing method, system, and computer equipment, so as to make the UI automation testing simple and easy, thereby improving the testing efficiency.

In the first aspect, an embodiment of the present application provides a UI automation testing method, and the UI automation testing method includes:

Loading an automatic test behavior script, wherein the automatic test behavior script includes a preset path and a calling interface;

Acquire a preset xml file according to the preset path, wherein the preset xml file includes several step nodes, the step node includes one or several sub-nodes, and when the step node includes one sub-node, one of the step nodes A child node corresponds to a first operation, and when the step node includes several child nodes, each of the child nodes corresponds to a second operation, and the first operation is different from the second operation; each of the child nodes corresponds to a second operation. including preset attribute values, the preset attribute values including operation parameters;

Invoke and load the corresponding UI interface to be tested according to the invocation interface;

Trigger and execute the operation corresponding to the step node on the UI interface to be tested; and

A test report is generated based on the execution result of the operation.

In a second aspect, an embodiment of the present application provides a computer device, where the computer device includes:

memory for storing program instructions; and

The processor is configured to execute the program instructions to implement the UI automation testing method described above.

In a third aspect, an embodiment of the present application provides a UI automated testing system, the UI automated testing system includes:

a first loading module for loading an automatic test behavior script, wherein the automatic test behavior script includes a preset path and a calling interface;

an obtaining module, configured to obtain a preset xml file according to the preset path, wherein the preset xml file includes several step nodes, and the step node includes one or several sub-nodes, when the step node includes a sub-node , one of the child nodes corresponds to a first operation, and when the step node includes several child nodes, each of the child nodes corresponds to a second operation, and the first operation is different from the second operation; each - the child node includes a preset attribute value, and the preset attribute value includes an operation parameter;

a calling module for calling and loading the corresponding UI interface to be tested according to the calling interface;

an execution module, configured to trigger the execution of an operation corresponding to the step node on the UI interface to be tested; and

The first generating module is configured to generate a test report according to the execution result of the operation.

The above-mentioned UI automation testing method, system, and computer equipment, use the preset path in the automatic testing behavior script to obtain the preset xml file, use the calling interface in the automatic testing behavior script to call the UI interface to be tested, and trigger execution on the UI interface to be tested The operation corresponding to the step node to complete the UI automation testing process. The preset xml file is generated according to the UI interface to be tested. The logic and behavior are separated by the preset xml file, that is, the script developer who develops the script does not need to care about the specific test scenario, and the tester of the testing software does not need to care about the logic of the automatic test behavior script. The connection between the two parts is completed by the preset xml file. . That is to say, testers do not need to be proficient in using scripting languages, nor do they need to know the code content of the program to implement UI automation testing, which optimizes the difficulties existing in UI automation testing and improves the tester's testing efficiency with low learning costs. Repetitive work is left to the computer itself to perform as much as possible. It makes UI automation testing simple and easy, thereby improving testing efficiency. At the same time, when the requirements change, the tester only needs to modify the corresponding preset xml file, which is more beneficial and easy to maintain.

Description of drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only These are some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained according to the structures shown in these drawings without any creative effort.

FIG. 1 is a flowchart of a UI automation testing method provided by an embodiment of the present application.

FIG. 2 is a first sub-flow chart of the UI automation testing method provided by the embodiment of the present application.

FIG. 3 is a second sub-flow chart of the UI automation testing method provided by the embodiment of the present application.

FIG. 4 is a third sub-flow chart of the UI automation testing method provided by the embodiment of the present application.

FIG. 5 is a fourth sub-flow chart of the UI automation testing method provided by the embodiment of the present application.

FIG. 6 is a schematic diagram of an internal structure of a computer device provided by an embodiment of the present application.

FIG. 7 is a schematic diagram of a first internal structure of a UI automated testing system provided by an embodiment of the present application.

FIG. 8 is a schematic diagram of a second internal structure of the UI automated testing system provided by the embodiment of the present application.

The realization, functional characteristics and advantages of the purpose of the present application will be further described with reference to the accompanying drawings in conjunction with the embodiments.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this application.

The terms "first", "second", "third", "fourth", etc. (if any) in the description and claims of the present application and the above-mentioned drawings are used to distinguish similar planning objects and do not necessarily Used to describe a specific order or sequence. It is to be understood that the data so used are interchangeable under appropriate circumstances, in other words, the described embodiments are implemented in accordance with sequences other than those illustrated or described herein. Furthermore, the terms "comprising" and "having" and any variations thereof may also encompass other content, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to only those expressly listed steps or units, but may include other steps or units not expressly listed or inherent to these processes, methods, products or devices.

It should be noted that the descriptions involving "first", "second", etc. in this application are only for the purpose of description, and should not be construed as indicating or implying their relative importance or implying the number of indicated technical features . Thus, a feature defined as "first" or "second" may expressly or implicitly include one or more of that feature. In addition, the technical solutions between the various embodiments can be combined with each other, but must be based on the realization by those of ordinary skill in the art. When the combination of technical solutions is contradictory or cannot be realized, it should be considered that the combination of such technical solutions does not exist. , is not within the scope of protection claimed in this application.

Please refer to FIG. 1 , which is a flowchart of the UI automation testing method provided by the embodiment of the present application. The UI automation testing method is used to automate the testing of the user interface (User Interface, UI). The UI automation testing method specifically includes the following steps.

Step S102, load an automatic test behavior script. Among them, the automatic test behavior script includes a preset path and a calling interface.

In this embodiment, the automatic test behavior script is written and formed by a script developer using a script language. Scripting languages include, but are not limited to, Python, Java, JavaScript, and the like. Preferably, the scripting language is Python. The preset path and calling interface can be set according to the actual test situation, which is not limited here.

In this embodiment, before loading the automatic testing behavior script, the UI automatic testing method includes: providing a script template. The script template includes path elements and interface elements. When the path element is replaced with the preset path and the interface element is replaced with the calling interface, the script template is converted into an automatic test behavior script. It is understandable that the content in the script template has been completely written, and the script developer only needs to replace the path element with the preset path and the interface element with the calling interface according to the actual test situation to form an automatic test behavior script. The preset path in the same automatic test behavior script corresponds to the calling interface.

Step S104, obtaining a preset xml file according to a preset path. In this embodiment, the preset xml file is a file prepared in advance according to actual test requirements, and the preset path corresponds to the preset xml file one-to-one. The specific generation method of the preset xml file will be described in detail below.

In this embodiment, the preset xml file includes several step nodes, and each step node includes one or several child nodes. When the step node includes one child node, one child node corresponds to one first operation; when the step node includes several child nodes, each child node corresponds to one second operation. Wherein, the first operation and the second operation are different. Each child node includes a preset attribute value, and the preset attribute value includes an operation parameter. The operations include but are not limited to mouse operations, keyboard operations, and the like. Preset attribute values include but are not limited to path parameters, location parameters, time parameters, operation parameters, and key values.

Step S106, calling and loading the corresponding UI interface to be tested according to the calling interface. In this embodiment, the calling interface is in one-to-one correspondence with the UI interface to be tested.

Step S108, triggering the execution of the operation corresponding to the step node on the UI interface to be tested. In this embodiment, after the UI interface to be tested is loaded, the step nodes of the preset xml file are identified and parsed, so as to obtain the corresponding first operation and/or second operation set, and trigger the execution of the first operation and/or in sequence. or the second operation. The method for identifying the step node in the preset xml file is a common method, which will not be repeated here.

Step S110, generating a test report according to the execution result of the operation. In the process of performing operations on the UI interface to be tested, the execution results corresponding to all operations can be recorded to form a test report.

In the above embodiment, the preset xml file is obtained by using the preset path in the automatic test behavior script, the UI interface to be tested is called by using the calling interface in the automatic test behavior script, and the operation corresponding to the execution step node is triggered on the UI interface to be tested, thereby Complete the UI automation testing process. The preset xml file is generated according to the UI interface to be tested. The logic and behavior are separated by the preset xml file, that is, the script developer who develops the script does not need to care about the specific test scenario, and the tester of the testing software does not need to care about the logic of the automatic test behavior script. The connection between the two parts is completed by the preset xml file. . That is to say, testers do not need to be proficient in using scripting languages, nor do they need to know the code content of the program to implement UI automation testing, which optimizes the difficulties existing in UI automation testing and improves the tester's testing efficiency with low learning costs. Repetitive work is left to the computer itself to perform as much as possible. It makes UI automation testing simple and easy, thereby improving testing efficiency. At the same time, when the requirements change, the tester only needs to modify the corresponding preset xml file, which is more beneficial and easy to maintain.

In addition, the automatic test behavior script is generated according to the script template. It only needs to replace the path element and interface element in the script template with the preset path of the preset xml file in the actual test and the calling interface of the UI interface to be tested. Test behavior scripts can be adapted to a variety of different applications. The preset xml files can be implemented on various operating systems, which uncouples script development and different logics required by different applications.

Please refer to FIG. 2 , which is a first sub-flow chart of the UI automation testing method provided by the embodiment of the present application. Before performing step S102, the UI automation testing method further includes the following steps.

Step S202, loading preset writing rules and test cases of the UI interface to be tested. In this embodiment, the preset writing rule includes all identification fields and corresponding preset attribute values, and the test case includes several test operations. The test operation is an operation that needs to be performed in the actual test process.

In this embodiment, the preset writing rule is an artificially prescribed writing rule. Preset authoring rules include several configurable items. Configurable items include but are not limited to Session, StepAction, Location, LocationXY, VisualImagePath, Duration, and Action. Specifically, Session represents a session, StepAction represents an execution step, Location represents an address, LocationXY represents an address coordinate, VisualImagePath represents an image address, Duration represents a stop duration, and Action represents an event. Wherein, a session includes multiple execution steps; the execution step may include a first operation or at least one second operation. Specifically, Location, LocationXY, VisualImagePath, and Duration all represent the first operation.

In this embodiment, StepAction includes a number parameter (StepNumber). The number parameter is used to describe the uniqueness of the execution step.

Action includes several event types, including left_mouse_click, right_mouse_click, mouse_move, key_down, and loop. Specifically, left_mouse_click means clicking the left mouse button, right_mouse_click means clicking the right mouse button, mouse_move means moving the mouse, key_down means entering a key value, and loop means a loop event. left_mouse_click, right_mouse_click, mouse_move, key_down, and loop all represent the second operation. It can be understood that the execution step may include an event, and an event includes at least one second operation.

In this embodiment, the identification fields include but are not limited to Location, LocationXY, VisualImagePath, Duration, Action, left_mouse_click, right_mouse_click, mouse_move, key_down, and loop.

Correspondingly, the preset attribute values of Location include absolute and visualization. The preset property values of LocationXY include coordinate values, that is, location parameters. The default property value of VisualImagePath includes the path, that is, the path parameter. Wherein, when the preset attribute value of Location is absolute, LocationXY must include the preset attribute value; when the preset attribute value of Location is visualization, VisualImagePath must include the preset attribute value. Specifically, the preset attribute value format of LocationXY is (x, y), and the preset attribute value of VisualImagePath is a relative path or an absolute path of the image.

The default property value of Duration includes the number of seconds, that is, the time parameter. Specifically, Duration represents the stop time after each event is executed, and the unit of the preset attribute value is seconds.

The default attribute values of Action include left_mouse_click, right_mouse_click, mouse_move, key_down and loop.

Among them, the preset attribute values of left_mouse_click and right_mouse_click include the number of times, that is, operation parameters. The default attribute value of left_mouse_click is used to indicate the number of clicks of the left mouse button, and the default attribute value of right_mouse_click is used to indicate the number of clicks of the right mouse button.

The preset attribute values of mouse_move include coordinate values, that is, position parameters. The default attribute value format of mouse_move is (x, y), which is used to indicate that the mouse moves to the corresponding coordinate.

The default property value of key_down includes the key value. Specifically, the key value can be assigned by referring to pyautogui.KEYBOARD_KEYS.

Loop's preset property values include loopBegin, vars, and loopEnd. Among them, loopBegin represents the beginning part of the loop event, vars represents the loop part of the loop event, and loopEnd represents the end part of the loop event. In a cyclic event, the beginning part and the end part are both constant parts, and the cyclic part is the changing part. loopBegin, vars, and loopEnd all include preset property values. Specifically, the format of the preset attribute values of loopBegin and loopEnd is "int,...,int", and the format of the preset attribute values of vars is "int,...,int;...;int,. ..,int". Among them, the semicolon is used to separate a loop, and the comma is used to separate the method of changing the part that needs to go through each loop.

Step S204, generating a preset xml file according to the test case and the preset writing rule. Among them, the names of step nodes and child nodes are both identification fields. It can be understood that the test case specifies the content of the preset xml file, and the preset writing rule specifies the writing specification of the preset xml file.

In this embodiment, the tester can complete the generation and modification of the preset xml file by writing some interface programs, or can manually write the preset xml file directly according to the test case and the preset writing rules. Wherein, the test operation in the test case corresponds to the UI interface to be tested, so that the first operation and/or the second operation in the generated preset xml file corresponds to the UI interface to be tested.

The specific process of generating the preset xml file according to the test case and the preset writing rule through the interface program will be described in detail below.

In the above embodiment, the preset xml file is generated according to the test case and the preset writing rule, so that the preset xml file matches the actual test case. It is understandable that in different testing processes, the content of the preset xml file is set according to the actual test requirements, while the content of the automatic test behavior script is roughly the same, and the preset path only used to obtain the preset xml file in the automatic test behavior script is different. , making automated test behavior scripts reusable once written. At the same time, the preset writing rules greatly reduce the difficulty for testers to write preset xml files, so that the preset xml files have a unified writing style.

Please refer to FIG. 3 , which is a second sub-flow chart of the UI automation testing method provided by the embodiment of the present application. Step S204 specifically includes the following steps.

Step S302, obtain operation data from the step recorder. In this embodiment, the operation data is data recorded in the step recorder that the user performs operations according to the test steps of the test case. Among them, the user can be a tester. The step recorder is an interface program that comes with the Windows system. In some possible embodiments, the step recorder may also be other interface programs written by the tester.

It is understandable that when the operation starts, the tester needs to start the step recorder first, and then the tester operates according to the test steps in the test case, so that the step recorder can record the corresponding operation data. The file format of the operation data is *.mht.

Step S304, converting the operation data into a preset xml file according to the preset writing rule. It can be understood that the step nodes in the preset xml file correspond to the test steps in the test case.

In the above embodiment, in the Windows system, the operation data can be generated by recording user operations through the step recorder that comes with the Windows system, and then the operation data can be converted into a preset xml file according to preset writing rules, so that the writing of the preset xml file can be performed. It is simpler and more feasible, greatly reduces the difficulty of the tester's work, and effectively improves the tester's testing efficiency.

Please refer to FIG. 4 , which is a third sub-flow chart of the UI automation testing method provided by the embodiment of the present application. After step S108 is performed, the UI automation testing method further includes the following steps.

Step S402, it is judged whether an abnormality occurs in the execution of the operation on the UI interface to be tested.

When an abnormality occurs in the execution of the operation on the UI interface to be tested, step S404 is performed.

Step S404, suspend or skip the operation.

In the above-mentioned embodiment, an abnormal execution event is added to the automatic test behavior script to abort or skip the abnormal execution operation or event, so as to ensure that the test process can be successfully completed.

Please refer to FIG. 5 , which is a fourth sub-flow chart of the UI automation testing method provided by the embodiment of the present application. After step S108 is performed, the UI automation testing method further includes the following steps.

Step S502, start the screen recording tool to record the execution process of the operation. Among them, the screen recording tool can be a program that comes with the Windows system, or can be a program written by a tester.

Step S504, generating a recording result according to the content recorded by the screen recording tool. Start the screen recording tool to record the test process and form a recorded result for the tester to review.

In some possible embodiments, the recorded result may be a log file. Among them, a log file can be generated according to the corresponding specification, and the log file can also be used as a test report for the tester to review.

Please refer to FIG. 6 , which is a schematic diagram of an internal structure of a computer device according to an embodiment of the present application. Computer device 10 includes memory 11 and processor 12 . The memory 11 is used for storing program instructions, and the processor 12 is used for executing the program instructions to implement the above-mentioned UI automation testing method.

The processor 12 may be a central processing unit (Central Processing Unit, CPU), a controller, a microcontroller, a microprocessor or other data processing chips in some embodiments, and is used to execute program instructions stored in the memory 11 .

The memory 11 includes at least one type of readable storage medium including flash memory, hard disk, multimedia card, card-type memory (eg, SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, and the like. The memory 11 may in some embodiments be an internal storage unit of the computer device, such as a hard disk of the computer device. In other embodiments, the memory 11 may also be an external storage device of the computer device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a Secure Digital (Secure Digital, SD) card equipped on the computer device, Flash card (FlashCard) and so on. Further, the memory 11 may also include both an internal storage unit of a computer device and an external storage device. The memory 11 can not only be used to store application software installed on the computer device and various data, such as codes for implementing the UI automation testing method, etc., but also can be used to temporarily store data that has been output or will be output.

Please refer to FIG. 7 , which is a schematic diagram of the first internal structure of the UI automated testing system provided by the embodiment of the present application. The UI automated testing system 20 includes a first loading module 21 , an acquiring module 22 , a calling module 23 , an executing module 24 and a first generating module 25 .

The first loading module 21 is used to load the automatic test behavior script. Among them, the automatic test behavior script includes a preset path and a calling interface.

In this embodiment, the automatic test behavior script is written and formed by a script developer using a script language. Scripting languages include, but are not limited to, Python, Java, JavaScript, and the like. Preferably, the scripting language is Python. The preset path and calling interface can be set according to the actual test situation, which is not limited here.

In this embodiment, before the first loading module 21 loads the automatic testing behavior script, the UI automatic testing system 20 also needs to provide a script template. The script template includes path elements and interface elements. When the path element is replaced with the preset path and the interface element is replaced with the calling interface, the script template is converted into an automatic test behavior script. It is understandable that the content in the script template has been completely written, and the script developer only needs to replace the path element with the preset path and the interface element with the calling interface according to the actual test situation to form an automatic test behavior script. The preset path in the same automatic test behavior script corresponds to the calling interface.

The obtaining module 22 is configured to obtain the preset xml file according to the preset path. In this embodiment, the preset xml file is a file prepared in advance according to actual test requirements, and the preset path corresponds to the preset xml file one-to-one.

In this embodiment, the preset xml file includes several step nodes, and each step node includes one or several child nodes. When the step node includes one child node, one child node corresponds to one first operation; when the step node includes several child nodes, each child node corresponds to one second operation. Wherein, the first operation is different from the second operation. Each child node includes a preset attribute value, and the preset attribute value includes an operation parameter. The operations include but are not limited to mouse operations, keyboard operations, and the like. Preset attribute values include but are not limited to path parameters, location parameters, time parameters, operation parameters, and key values.

The calling module 23 is used for calling and loading the corresponding UI interface to be tested according to the calling interface. In this embodiment, the calling interface is in one-to-one correspondence with the UI interface to be tested.

The execution module 24 is configured to trigger the operation corresponding to the execution step node on the UI interface to be tested. In this embodiment, after the calling module 23 loads the UI interface to be tested, the execution module 24 identifies and parses the step nodes of the preset xml file, thereby obtaining the corresponding first operation and/or second operation set, and triggers them in sequence Perform the first operation and/or the second operation. The method for identifying the step node in the preset xml file is a common method, which will not be repeated here.

The first generating module 25 is configured to generate a test report according to the execution result of the operation. When the execution module 24 performs an operation on the UI interface to be tested, the first generation module 25 can record the execution results corresponding to all the operations to form a test report.

Please refer to FIG. 8 , which is a schematic diagram of the second internal structure of the UI automated testing system provided by the embodiment of the present application. The UI automation testing system 20 further includes a second loading module 26 and a second generating module 27 .

The second loading module 26 is used for loading preset writing rules and test cases of the UI interface to be tested. In this embodiment, the preset writing rule includes all identification fields and corresponding preset attribute values, and the test case includes several test operations. The test operation is an operation that needs to be performed in the actual test process.

In this embodiment, the preset writing rule is an artificially prescribed writing rule. Preset authoring rules include several configurable items. Configurable items include but are not limited to Session, StepAction, Location, LocationXY, VisualImagePath, Duration, and Action. Specifically, Session represents a session, StepAction represents an execution step, Location represents an address, LocationXY represents an address coordinate, VisualImagePath represents an image address, Duration represents a stop duration, and Action represents an event. Wherein, a session includes multiple execution steps; the execution step may include a first operation or at least one second operation. Specifically, Location, LocationXY, VisualImagePath, and Duration all represent the first operation.

In this embodiment, StepAction includes a number parameter (StepNumber). The number parameter is used to describe the uniqueness of the execution step.

Action includes several event types, including left_mouse_click, right_mouse_click, mouse_move, key_down, and loop. Specifically, left_mouse_click means clicking the left mouse button, right_mouse_click means clicking the right mouse button, mouse_move means moving the mouse, key_down means entering a key value, and loop means a loop event. left_mouse_click, right_mouse_click, mouse_move, key_down, and loop all represent the second operation. It can be understood that the execution step may include an event, and an event includes at least one second operation.

In this embodiment, the identification fields include but are not limited to Location, LocationXY, VisualImagePath, Duration, Action, left_mouse_click, right_mouse_click, mouse_move, key_down, and loop.

Correspondingly, the preset attribute values of Location include absolute and visualization. The preset property values of LocationXY include coordinate values, that is, location parameters. The default property value of VisualImagePath includes the path, that is, the path parameter. Wherein, when the preset attribute value of Location is absolute, LocationXY must include the preset attribute value; when the preset attribute value of Location is visualization, VisualImagePath must include the preset attribute value. Specifically, the preset attribute value format of LocationXY is (x, y), and the preset attribute value of VisualImagePath is a relative path or an absolute path of the image.

The default property value of Duration includes the number of seconds, that is, the time parameter. Specifically, Duration represents the stop time after each event is executed, and the unit of the preset attribute value is seconds.

The default attribute values of Action include left_mouse_click, right_mouse_click, mouse_move, key_down and loop.

Among them, the preset attribute values of left_mouse_click and right_mouse_click include the number of times, that is, operation parameters. The default attribute value of left_mouse_click is used to indicate the number of clicks of the left mouse button, and the default attribute value of right_mouse_click is used to indicate the number of clicks of the right mouse button.

The preset attribute values of mouse_move include coordinate values, that is, position parameters. The default attribute value format of mouse_move is (x, y), which is used to indicate that the mouse moves to the corresponding coordinate.

The default property value of key_down includes the key value. Specifically, the key value can be assigned by referring to pyautogui.KEYBOARD_KEYS.

Loop's preset property values include loopBegin, vars, and loopEnd. Among them, loopBegin represents the beginning part of the loop event, vars represents the loop part of the loop event, and loopEnd represents the end part of the loop event. In a cyclic event, the beginning part and the end part are both constant parts, and the cyclic part is the changing part. loopBegin, vars, and loopEnd all include preset property values. Specifically, the format of the preset attribute values of loopBegin and loopEnd is "int,...,int", and the format of the preset attribute values of vars is "int,...,int;...;int,. ..,int". Among them, the semicolon is used to separate a loop, and the comma is used to separate the method of changing the part that needs to go through each loop.

The second generating module 27 is configured to generate the preset xml file according to the test case and the preset writing rule. Among them, the names of step nodes and child nodes are both identification fields. It can be understood that the test case specifies the content of the preset xml file, and the preset writing rule specifies the writing specification of the preset xml file. In this embodiment, the test operation in the test case corresponds to the UI interface to be tested, so that the first operation and/or the second operation in the generated preset xml file corresponds to the UI interface to be tested.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

The above enumeration is only the preferred embodiment of the present application, of course, the scope of the right of the present application cannot be limited by this, so the equivalent changes made according to the claims of the present application still belong to the scope covered by the present application.

Claims (10)

1. A UI automation test method is characterized by comprising the following steps:

loading an automatic testing behavior script, wherein the automatic testing behavior script comprises a preset path and a calling interface;

acquiring a preset xml file according to the preset path, wherein the preset xml file comprises a plurality of step nodes, each step node comprises one or a plurality of sub-nodes, when the step node comprises one sub-node, one sub-node corresponds to one first operation, when the step node comprises a plurality of sub-nodes, each sub-node corresponds to one second operation, and the first operation is different from the second operation; each child node comprises a preset attribute value, and the preset attribute value comprises an operation parameter;

calling and loading a corresponding UI to be tested according to the calling interface;

triggering and executing the operation corresponding to the step node on the UI interface to be tested; and

and generating a test report according to the execution result of the operation.

2. The UI automation test method of claim 1, wherein prior to loading an automation test behavior script, the UI automation test method further comprises:

loading a preset compiling rule and a test case of the UI interface to be tested, wherein the preset compiling rule comprises all identification fields and corresponding preset attribute values, and the test case comprises a plurality of test operations; and

and generating the preset xml file according to the test case and a preset writing rule, wherein the names of the step node and the child node are the identification fields.

3. The UI automation test method of claim 2, wherein the generating the preset xml file according to the test case and the preset writing rule specifically comprises:

acquiring operation data from a step recorder, wherein the operation data is data recorded in the step recorder by a user according to the test steps of the test case; and

and converting the operation data into the preset xml file according to the preset compiling rule.

4. The method for automatically testing a UI according to claim 1, wherein after the UI interface to be tested triggers the operation corresponding to the step node, the method for automatically testing a UI further comprises:

starting a screen recording tool to record the execution process of the operation; and

and generating a recording result according to the content recorded by the screen recording tool.

5. The UI automated testing method according to claim 1, wherein after the UI interface to be tested triggers execution of the operation corresponding to the step node, the UI automated testing method further comprises:

judging whether the operation executed on the UI interface to be tested is abnormal or not; and

and when the operation executed on the UI interface to be tested is abnormal, stopping or skipping the operation.

6. The UI automation test method of claim 1 wherein prior to loading the automation test behavior script, the UI automation test method further comprises:

providing a script template, wherein the script template comprises path elements and interface elements, and when the path elements are replaced by the preset paths and the interface elements are replaced by the calling interfaces, the script template is converted into the automatic test behavior script.

7. The UI automation test method of claim 1 wherein the preset attribute values include a path parameter, a location parameter, a time parameter, an operation parameter, and a key value.

8. A computer device, characterized in that the computer device comprises:

a memory for storing program instructions; and

a processor for executing the program instructions to implement the UI automation test method of any one of claims 1 to 7.

9. A UI automation test system, the UI automation test system comprising:

the system comprises a first loading module, a second loading module and a control module, wherein the first loading module is used for loading an automatic testing behavior script, and the automatic testing behavior script comprises a preset path and a calling interface;

an obtaining module, configured to obtain a preset xml file according to the preset path, where the preset xml file includes a plurality of step nodes, each step node includes one or a plurality of child nodes, when the step node includes one child node, one child node corresponds to one first operation, when the step node includes a plurality of child nodes, each child node corresponds to one second operation, and the first operation is different from the second operation; each child node comprises a preset attribute value, and the preset attribute value comprises an operation parameter;

the calling module is used for calling and loading the corresponding UI interface to be tested according to the calling interface;

the execution module is used for triggering and executing the operation corresponding to the step node on the UI interface to be tested; and

and the first generation module is used for generating a test report according to the execution result of the operation.

10. The UI automation test system of claim 9 wherein the UI automation test system further comprises:

the second loading module is used for loading a preset compiling rule and a test case of the UI interface to be tested, wherein the preset compiling rule comprises all identification fields and corresponding preset attribute values, and the test case comprises a plurality of test operations; and

and the second generation module is used for generating the preset xml file according to the test case and a preset writing rule, wherein the names of the step node and the child node are the identification fields.

Images