A test script generation method and device, an electronic device, and a storage medium

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for generating test scripts. The method includes: converting test requirement information to obtain test scenario information; parsing the code under test to obtain target information related to interface objects in a graphical user interface; generating an object mapping file based on the test scenario information and target information, wherein the object mapping file is used to define interface objects; determining an action encapsulation library based on the object mapping file, wherein the action encapsulation library is used to encapsulate target actions that interact with interface objects; and generating a test script for the code under test based on the test scenario information, object mapping file, and action encapsulation library. Thus, the interface object definition, interactive actions, and test scenario form an interconnected but relatively independent structure, reducing the direct coupling of test scripts with interface object details and improving the structure and maintainability of the test script generation process.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for generating test scripts. Background Technology

[0002] As industrial simulation software, engineering design software, and test management software become increasingly complex, their graphical interfaces typically contain a large number of interface objects such as windows, buttons, tabs, input boxes, and pop-ups. Testers need to use test scripts to repeatedly verify the business processes of these graphical interfaces in order to reduce the workload of manual testing and improve test consistency.

[0003] Correspondingly, in existing graphical interface testing processes, test scripts typically need to describe test steps, interface objects, and interactive actions performed on these objects. For software with complex interfaces, lengthy operation processes, and numerous state dependencies, the writing and maintenance of test scripts place high demands on testers. In particular, when the interface is adjusted, the parts of the test script involving interface objects are easily affected and require modification and adjustment. Therefore, the efficiency of test script generation and maintenance is low. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for generating test scripts to improve the efficiency of test script generation and maintenance.

[0005] In a first aspect, embodiments of this application provide a method for generating test scripts, including: The test requirement information is transformed to obtain test scenario information; The code under test is parsed to obtain target information related to the interface objects of the graphical interface; Based on the test scenario information and the target information, an object mapping file is generated, which is used to define the interface object; Based on the object mapping file, an action encapsulation library is determined, which is used to encapsulate target actions that interact with the interface object. Based on the test scenario information, the object mapping file, and the action encapsulation library, a test script is generated for the code under test.

[0006] Optionally, the object mapping file includes definition information of the interface object, which is related to the test scenario information. The definition information includes a business semantic name and object location information corresponding to the business semantic name. The object location information includes at least one of object identifier, control type, parent-child hierarchy, title text, visibility attribute, and logical attribute.

[0007] Optionally, generating an object mapping file based on the test scenario information and the target information includes: The interface objects actually invoked by the test scenario information are written into the object mapping file, and the object location information corresponds to the object logic identifier and / or business semantic identifier in the code under test.

[0008] Optionally, the code under test includes an interface description file and a program source code file; The process of parsing the code under test to obtain target information related to the interface objects of the graphical interface includes: The interface description file is parsed to extract at least one of the following: window information, control information, title text information, and hierarchical relationship information. The program source code file is parsed to extract at least one of the following: object identification information, control type information, object creation logic, object lookup logic, action signal function, and execution path.

[0009] Optionally, the action encapsulation library includes multiple target actions, which include at least one of the following actions: loading the code under test, switching tabs, clicking a control, inputting text or a path, confirming a dialog box, handling a prompt pop-up, executing a shortcut key, executing a drag-and-drop action, waiting for the interface state, and reading the interface state.

[0010] Optionally, the test script includes assertion statements; The step of generating a test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library includes: The test scenario information is verified to obtain the verification result; If the verification result indicates that the test scenario information is not covered by an existing test script, the assertion statement is generated based on the success criteria and / or assertion type in the test scenario information. The assertion statement includes at least one of the following: object existence assertion, interface state assertion, text or numerical exact match assertion, business result assertion, and exception prompt assertion.

[0011] Optionally, after generating the test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library, the method further includes: Execute the test script to obtain the test results; If the test result indicates that the test has failed, the cause of the failure is located based on the failure log, object lookup exception information, and / or execution context information. The test script is updated based on the reasons for the failure, resulting in an updated test script.

[0012] Secondly, embodiments of this application provide a test script generation apparatus, comprising: The information conversion module is used to convert test requirement information into test scenario information; The code parsing module is used to parse the code under test and obtain target information related to the interface objects of the graphical interface. The file generation module is used to generate an object mapping file based on the test scenario information and the target information, wherein the object mapping file is used to define the interface object; The encapsulation library determination module is used to determine the action encapsulation library based on the object mapping file, wherein the action encapsulation library is used to encapsulate the target action that interacts with the interface object. The script generation module is used to generate a test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library.

[0013] Thirdly, embodiments of this application provide an electronic device, the device including: a processor, a memory, and a system bus; The processor and the memory are connected via the system bus; The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform any of the implementation steps of the above-described test script generation method.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the implementation steps of the test script generation method described above.

[0015] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: In this embodiment, after converting the test requirement information to obtain test scenario information, the code under test can be parsed to obtain target information related to the interface objects of the graphical interface. Then, based on the test scenario information and target information, an object mapping file is generated, which defines the interface objects. Next, an action encapsulation library is determined based on the object mapping file. This library encapsulates the target actions that interact with the interface objects. In this way, test scripts for the code under test can be generated based on the test scenario information, the object mapping file, and the action encapsulation library. Since the object mapping file defines the interface objects and the action encapsulation library encapsulates the target actions that interact with the interface objects, when generating the test script, the test script can describe the business process based on the test scenario information, obtain the interface object definition through the object mapping file, and call the target actions through the action encapsulation library. Therefore, the interface object definition, interaction actions, and test scenario form an interconnected but relatively independent structure, reducing the direct coupling of the test script with the details of the interface objects. When testing requirements change, the script logic corresponding to the test scenarios can be adjusted more; when the definition of UI objects changes, the object mapping files can be adjusted more; and when interactive actions are reused or changed, the action encapsulation library can be adjusted more. This improves the structure and maintainability of the test script generation process. Furthermore, since object definitions originate from UI object-related information in the code under test, rather than relying solely on manual descriptions by script writers, it helps reduce labor costs and workload. Attached Figure Description

[0016] Figure 1 A flowchart illustrating a method for generating a test script as provided in an embodiment of this application; Figure 2 This is a schematic diagram of a test script generation device provided in an embodiment of this application. Detailed Implementation

[0017] As mentioned earlier, for software with complex interfaces, long operation processes, and many state dependencies, the writing and maintenance of test scripts place high demands on testers. In particular, when the interface is adjusted, the parts of the test script involving interface objects are easily affected and need to be modified and adjusted again. Therefore, the efficiency of test script generation and maintenance is low.

[0018] To address the aforementioned issues, this application provides a method for generating test scripts, comprising: after converting test requirement information to obtain test scenario information, firstly parsing the code under test to obtain target information related to interface objects of the graphical interface; then, generating an object mapping file based on the test scenario information and target information, which is used to define interface objects; and finally, determining an action encapsulation library based on the object mapping file, which is used to encapsulate target actions that interact with interface objects. In this way, test scripts for the code under test can be generated based on test scenario information, object mapping files, and action encapsulation libraries.

[0019] Since object mapping files define UI objects and action encapsulation libraries encapsulate target actions that interact with UI objects, test scripts can describe business processes based on test scenario information, obtain UI object definitions through object mapping files, and call target actions through action encapsulation libraries when generating test scripts. This creates an interconnected yet relatively independent structure between UI object definitions, interaction actions, and test scenarios, reducing the direct coupling of test scripts with UI object details. When test requirements change, the script logic corresponding to the test scenario can be adjusted more; when UI object definitions change, the object mapping files can be adjusted more; and when interaction actions are reused or changed, the action encapsulation libraries can be adjusted more. This improves the structure and maintainability of the test script generation process. Furthermore, since object definitions originate from UI object-related information in the code under test, rather than relying solely on manual descriptions by script writers, it helps reduce labor costs and workload.

[0020] It should be noted that the embodiments of this application do not limit the executing entity of the test script generation method. For example, the test script generation method of this application embodiment can be applied to data processing devices such as servers or terminal devices. The server can be a standalone server, a cluster server, or a cloud server. The terminal device can be an electronic device such as a smartphone, computer, personal digital assistant (PDA), or tablet computer.

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0022] Figure 1A flowchart illustrating a test script generation method provided in this application embodiment. (In conjunction with...) Figure 1 As shown, the test script generation method provided in this application embodiment includes the following steps S101-S105.

[0023] S101: Transform the test requirement information to obtain test scenario information.

[0024] Test requirement information refers to the information entered by testers or business personnel to describe the test objectives and processes. Test requirement information can be presented as natural language test cases, functional test documents, screenshots, existing test scripts, or structured step descriptions. For example, test requirement information could be: Start the software under test, create a new project, enter the project path, click the OK button, and check if the project was created successfully. Alternatively, test requirement information can come from script content in an existing test suite or from test step descriptions for a specific function in a functional test document.

[0025] In practical applications, test requirement information is not always directly suitable for generating test scripts. Natural language may contain omitted content, such as not explicitly specifying the entry interface, prerequisite states, success criteria, or assertion methods; functional test documentation may also combine multiple operations into a single description; screenshot descriptions may only show interface prompts without a complete operation path. Based on this, in the embodiments of this application, test requirement information can be transformed to obtain test scenario information.

[0026] Test scenario information refers to a structured test description used to generate test scripts. It can include entry conditions, prerequisite states, key business actions, success criteria, assertion types, and environment dependencies. Entry conditions indicate the interface, menu, or function from which the test begins; prerequisite states indicate the states that must be met before the test can be executed, such as the software under test being started, the absence of a project with the same name, or the loading of a test file; key business actions indicate the steps to be performed, such as clicking a button, switching tabs, entering a path, or entering a confirmation dialog; success criteria indicate the conditions for passing the test, such as the appearance of a target window, the interface changing to a completed state, or a field displaying the expected value; assertion types indicate how success criteria are determined, such as checking if an object exists, checking if the interface state meets expectations, or checking if text or values ​​match precisely; and environment dependencies indicate the data directory, test files, or runtime environment required for the test.

[0027] In practical implementation, the process of transforming test requirement information can utilize pre-defined domain cue templates or structured rules to semantically complete, constrain, and decompose the test requirement information. Here, a domain cue template refers to pre-designed rule-based prompts for specific graphical interface testing scenarios, used to guide natural language processing models or script generation systems to understand test requirements according to a unified format. For example, in industrial software graphical interface testing scenarios, a domain cue template can prompt the system to recognize "creating a new project" in natural language as a set of business actions including opening a new entry point, inputting the project path, confirming creation, and checking the project creation results; it can also prompt the system to convert the check for success into a specific assertion type.

[0028] Based on the content of step S101 above, the test requirement information is converted into test scenario information. This transforms potentially incomplete, non-standard, or human-interpretive descriptions into structured information that can be used to generate object mapping files, action encapsulation libraries, and test scripts. In this way, the test script generation process can use structured test scenarios as input, reducing generation deviations caused by incomplete or inconsistent natural language descriptions and improving the accuracy and consistency of test script generation.

[0029] S102: Parse the code under test to obtain target information related to the interface objects of the graphical interface.

[0030] The code under test refers to the code file corresponding to the software being tested. For graphical user interface software, the code under test typically contains content related to the interface structure and program logic.

[0031] Interface objects refer to objects in a graphical interface that can be identified, located, manipulated, or verified, such as windows, menus, buttons, input boxes, lists, tree nodes, tabs, dialog boxes, or pop-up prompts.

[0032] Target information refers to information related to these interface objects and that can be used for subsequent object definition and action invocation. For example, target information may include window information, control information, object identification information, control type information, title text information, parent-child hierarchy information, object creation logic, object lookup logic, action signal functions, or execution paths, etc.

[0033] For example, for a desktop application based on Qt (a cross-platform application development framework), the code under test can include interface description files and program source code files. The interface description file, for example, is a .ui file, which can contain interface structure information such as window information, control information, title text information, and hierarchy information; the program source code file, for example, is a .h file or a .cpp file, which can contain program logic information such as object identification information, control type information, object creation logic, object lookup logic, action signal functions, and execution paths.

[0034] In practical applications, if traditional test scripts directly rely on object paths or object names generated during recording, these object paths may be tightly bound to factors such as interface layout, parent containers, and control display positions. When the interface structure is slightly adjusted, the object location expressions in the original script may become invalid. However, the code under test typically contains more stable interface object information, such as object names, control types, logical identifiers, control creation code, and signal-slot connection relationships. This information reflects how interface objects and business logic are defined during software development and generally offers better stability and interpretability compared to object serial numbers or long paths temporarily generated during recording.

[0035] Therefore, for ease of understanding, the process of parsing the code under test will be described below with reference to one possible implementation method.

[0036] As one possible implementation, the code under test includes an interface description file and a program source code file. Accordingly, the process of parsing the code under test can specifically involve parsing the interface description file and extracting at least one of the following: window information, control information, title text information, and hierarchical relationship information. Alternatively, it can involve parsing the program source code file and extracting at least one of the following: object identification information, control type information, object creation logic, object lookup logic, action signal functions, and execution path.

[0037] Specifically, an interface description file (IDE) can be used to describe statically existing windows and controls within an interface. For example, an IDE description file can define the main window, menu bar, "New Project" button, project path input box, "OK" button, and the parent-child hierarchy relationships between these controls. By parsing this IDE description file, we can determine which window or container a button belongs to, what its title text is, and what type of control it corresponds to.

[0038] Program source code files can be used to describe the creation, retrieval, and business interactions of interface objects during program execution. For example, source code files may contain statements that set object names, find child controls, dynamically create tabs or pop-ups, and connect button click signals to business processing functions. By parsing the program source code files, dynamic object information and business action associations that cannot be fully represented in static interface description files can be obtained.

[0039] Furthermore, when the interface description file already contains complete target interface object information, the window, control, title text, and hierarchy information in the interface description file can be used first. When the interface description file does not contain the target interface object, or the interface object is dynamically created at runtime, the object creation logic and object lookup logic in the program source code file can be further analyzed. For example, if a test scenario needs to verify dynamically generated tabs or pop-ups, and these tabs or pop-ups are not permanently written into the interface description file, their object identifier, control type, or business semantics can be determined through the logic for creating the tab or pop-up in the program source code file. This can cover dynamic interface objects and make the object definition more complete.

[0040] Based on the content of step S102 above, by parsing the code under test to obtain target information, the subsequent generation of object mapping files can describe objects based on the actual interface structure and object definitions in the code, rather than relying solely on manual experience or recording results. This helps improve the matching degree between object definitions and the interface implementation of the software under test, enabling the generated test scripts to more accurately locate interface objects and reduce the risk of script failure due to interface layout adjustments.

[0041] It should be noted that the code under test in this application embodiment is not limited to a specific suffix or a specific development framework. As long as the code under test can provide information related to the graphical interface object, it can be applied to this application embodiment.

[0042] S103: Based on the test scenario information and target information, generate an object mapping file. The object mapping file is used to define interface objects.

[0043] An object mapping file is a file or data collection used to store the definition information of interface objects, such as `new_project_map.py`. The purpose of the object mapping file is to establish the correspondence between business semantics and the location information of interface objects. Business semantics refers to the names or meanings used to describe business actions in the test scenario, such as a "Create Project" button, a project path input box, a "Confirm" button, a message prompt box, or a model view area. Object location information refers to the information used by the test script or action encapsulation library to find the corresponding interface object, such as object identifier, control type, parent-child hierarchy, title text, visibility attributes, and logical attributes.

[0044] It's important to note that object mapping files are used to define UI objects, but they are not required to store all UI objects in the software under test. To make object mapping files more suitable for the current test script generation process, you can determine which UI objects the current test scenario actually needs to call based on the test scenario information, and then select the corresponding object definition information from the target information and write it into the object mapping file. In this way, the object mapping file can be organized around the current test scenario or test suite, rather than accumulating all object definitions encountered during the recording process.

[0045] In this embodiment of the application, the object mapping file may include the definition information of the interface object, and the interface object is related to the test scenario information.

[0046] The definition information includes a business semantic name and the object location information corresponding to that business semantic name. The object location information includes at least one of the following: object identifier, control type, parent-child hierarchy, title text, visibility attribute, and logical attribute.

[0047] Specifically, business semantic names can be names that are easy for test scripts to understand and call, such as a "Create Project" button, a "Project Name Input Box," or a "Confirmation Dialog Box."

[0048] Object location information can be obtained by parsing the code under test. For example, the object location information for a "Create Project" button may include its object identifier, control type (button), parent container, button title text, and visibility attribute. Similarly, the object location information for a pop-up notification may include the pop-up type, title text, window it belongs to, and visibility attribute. During execution, the action encapsulation library or test script can find the corresponding object location information in the object mapping file based on the business semantic name, thereby locating the UI object. For ease of understanding, the following describes the object mapping file generation process using one possible implementation method.

[0049] As one possible implementation, when generating the object mapping file, the UI objects actually called by the test scenario information can be written into the object mapping file. The object location information corresponds to the object's logical identifier and / or business semantic identifier in the code under test.

[0050] Specifically, the UI objects actually invoked in the test scenario refer to the UI objects necessary for performing the operations or verifications required for that test scenario. For example, the UI objects actually invoked in the "Create New Project" test scenario may include the "Create New Project" entry, the "Project Path" input box, the "OK" button, the success message object, or the project list object. Other controls not involved in the current test scenario, such as other menu items, other tool buttons, or irrelevant settings panels, do not need to be written to the object mapping file corresponding to that test scenario.

[0051] The correspondence between object location information and object logical identifiers and / or business semantic identifiers in the code under test means that the location basis in the object mapping file is primarily derived from the object name, logical attributes, or business meaning defined in the code under test, rather than from names randomly generated during recording or dependent on position order.

[0052] Based on the above steps S103, it is clear that by generating an object mapping file, the definition of UI objects can be separated from the test script. This eliminates the need for the test script to directly maintain a large number of low-level object location expressions, making the script content more concise. Furthermore, when the location information of UI objects changes, the object mapping file can be updated for adaptation, rather than modifying the location expressions of the same UI object in multiple test scripts, thus reducing maintenance costs.

[0053] S104: Determine the action encapsulation library based on the object mapping file. The action encapsulation library is used to encapsulate the target actions that interact with the interface objects.

[0054] In this context, an action encapsulation library refers to a file or program module used to store reusable action functions, such as common.py. In practice, an action encapsulation library can include multiple target actions. A target action is an action that interacts with the interface object or obtains the interface state during the testing process, such as loading the code under test, switching tabs, clicking controls, entering text or a path, entering a confirmation dialog, handling a prompt pop-up, executing a shortcut key, performing a drag-and-drop action, waiting for the interface state, and reading the interface state—at least one of these actions.

[0055] In practical applications, multiple test scenarios within a test script often reuse the same or similar user interface interactions. For example, different test scenarios may require launching the application under test, opening a specific function tab, clicking the "OK" button, handling pop-up prompts, or entering file paths. If each test script directly writes these low-level interactions, it not only leads to code duplication but also complicates script maintenance. Therefore, action encapsulation libraries encapsulate these common actions, allowing test scripts to call semantic action functions to complete operations.

[0056] Specifically, the action encapsulation library can determine the UI objects required for each target action based on the object mapping file. For example, the action of clicking the "Create Project" button can read the object location information corresponding to the "Create Project" button from the object mapping file, and then call the click interface of the graphical interface automation testing tool to perform the click operation. The action of entering the project path can read the object location information corresponding to the project path input box from the object mapping file, and then perform the operation of entering text or path. The action of handling the prompt pop-up can read the object location information of the prompt pop-up and the confirmation button from the object mapping file, then determine whether the pop-up appears and perform the confirmation operation.

[0057] Furthermore, the action wrapper library can be generated in the shared script directory of the current test suite, or it can be incrementally updated based on an existing action wrapper library. Here, incremental update means that when the current test scenario requires a target action that is not present in the existing action wrapper library, the corresponding action function is added; when the existing action function can meet the needs of the current test scenario, the existing action function is reused. For example, if the existing action wrapper library already contains action functions such as clicking a button, entering a path, and confirming a dialog box, the newly generated test script can directly call these action functions; if the current test scenario adds a drag-and-drop operation of a model object, and the action wrapper library does not yet contain a drag-and-drop action function, a function to perform the drag-and-drop action can be added.

[0058] Based on the content of step S104 above, it is known that by determining the action encapsulation library based on the object mapping file, the positioning of interface objects and interface interaction actions can be associated and encapsulated. In this way, test scripts can call high-level semantic actions to describe business processes, avoiding the need to repeatedly write repetitive logic such as low-level clicks, inputs, waits, and pop-up handling in the test scripts, improving the reusability of actions, and reducing the testers' dependence on the low-level automated test interfaces and object recognition mechanisms.

[0059] S105: Generates test scripts for the code under test based on test scenario information, object mapping files, and action encapsulation libraries.

[0060] The test script, such as test.py, is a script file used to automate the testing of the software corresponding to the code under test. This test script can include test steps organized according to test scenario information and perform specific UI operations through object mapping files and action encapsulation libraries. The test script does not need to directly write the underlying positioning details of each UI object; instead, it can call target actions from the action encapsulation library, which then further locate the UI objects through the object mapping file.

[0061] For example, in the test scenario of creating a new project, the test scenario information could include starting the software, opening the new project entry point, entering the project path, clicking the confirmation button, and checking that the project has been created successfully. The object mapping file can define the object location information for the new project entry point, the project path input box, the confirmation button, and the success message object. The action encapsulation library can include actions such as starting the application under test, clicking a control, entering a path, entering a confirmation dialog box, or reading the interface state. The final generated test script can call these action functions according to the business process, thereby achieving automatic execution of the test scenario.

[0062] To facilitate understanding, the generation process of this test script is described below with reference to one possible implementation method.

[0063] As one possible implementation, the test script includes assertion statements. Accordingly, in the test script that generates the code under test, the test scenario information can first be verified to obtain the verification result.

[0064] Specifically, validating test scenario information means determining whether the current test scenario has already been covered by an existing test script. For example, the entry conditions, key business actions, and success criteria in the test scenario can be matched with the corresponding test scenarios in existing test scripts. If an existing test script already covers the same or equivalent test scenario, no new test script needs to be created, avoiding duplicate generation. If it is not covered, a new test script is generated. This makes the test scripts in the test suite more organized and reduces duplicate test cases.

[0065] Based on this, if the test scenario information identified by the verification result is not covered by existing test scripts, assertion statements are generated based on the success criteria and / or assertion types in the test scenario information. Here, assertion statements include at least one of the following: object existence assertion, interface state assertion, text or numerical exact match assertion, business result assertion, and exception message assertion.

[0066] Furthermore, assertion statements are used to determine whether the actual result meets expectations after the test script has executed a specific step. Object existence assertions can be used to determine whether a window, button, or dialog box appears; interface state assertions can be used to determine whether a button is available, whether a page has switched successfully, or whether a task has been completed; text or value exact match assertions can be used to determine whether the text or value displayed on the interface matches expectations; business result assertions can be used to determine whether business results such as creating a new project, importing a file, or performing a calculation have been completed; and exception message assertions can be used to determine whether the expected message appears when there is abnormal input or incorrect operation.

[0067] Based on the content of step S105 above, it is clear that by generating test scripts based on test scenario information, object mapping files, and action encapsulation libraries, test scripts can simultaneously possess business readability and executability. In this way, the business process in the test script originates from the test scenario information, the interface object definition comes from the object mapping file, and the interface interaction logic comes from the action encapsulation library. The three components have a clear division of labor, reducing the coupling between test logic and object location logic, and improving script generation efficiency and subsequent maintenance efficiency.

[0068] Based on the above steps S101-S105, in this embodiment, after converting the test requirement information to obtain the test scenario information, the code under test can be parsed to obtain target information related to the interface objects of the graphical interface. Then, based on the test scenario information and target information, an object mapping file is generated, which is used to define the interface objects. Next, an action encapsulation library is determined based on the object mapping file, which is used to encapsulate the target actions that interact with the interface objects. In this way, a test script for the code under test can be generated based on the test scenario information, the object mapping file, and the action encapsulation library. Since the object mapping file is used to define the interface objects, and the action encapsulation library is used to encapsulate the target actions that interact with the interface objects, when generating the test script, the test script can describe the business process based on the test scenario information, obtain the interface object definition through the object mapping file, and call the target actions through the action encapsulation library. Therefore, the interface object definition, interaction actions, and test scenario form an interconnected but relatively independent structure, reducing the direct coupling of the test script with the details of the interface objects. When testing requirements change, the script logic corresponding to the test scenarios can be adjusted more; when the definition of UI objects changes, the object mapping files can be adjusted more; and when interactive actions are reused or changed, the action encapsulation library can be adjusted more. This improves the structure and maintainability of the test script generation process. Furthermore, since object definitions originate from UI object-related information in the code under test, rather than relying solely on manual descriptions by script writers, it helps reduce labor costs and workload.

[0069] Furthermore, after generating the test script, embodiments of this application can further execute the test script to complete the test. For ease of understanding, the process of executing the test script is described below with reference to a possible implementation method.

[0070] As one possible implementation, the test script is first executed to obtain the test results. Specifically, executing the test script can be either executing a single test case or executing a test suite containing multiple test cases. The test results can indicate whether the test passed or failed, and may also include specific failure steps, failure logs, exception stack traces, object lookup exception information, screenshots, or execution context information.

[0071] In practical applications, test failures can be caused by a variety of reasons. For example, incomplete object location information in the object mapping file may prevent the button from being found; the wait time or pop-up handling logic in the action encapsulation library may not be suitable for the current interface state; the business steps in the test script may be inconsistent with the actual process; and the assertion statements may be inconsistent with the success criteria in the test requirements.

[0072] Therefore, when the test result indicates a test failure, the cause of the failure can be located by analyzing the failure log, object lookup exception information, and execution context information. This allows us to determine whether the failure is due to an object location problem, an action execution problem, a business step problem, or an assertion problem. Specifically, the failure log records error information that occurs during script execution; object lookup exception information indicates that a certain UI object cannot be located, object properties do not match, or the object is not visible; and the execution context information indicates the UI at the time of execution failure, the current test step, the actions already executed, the input data, or the environment state.

[0073] Furthermore, the test script can be updated based on the cause of failure, resulting in an updated test script. In practice, updating the test script can include updating the test script itself, or updating the object mapping file or action encapsulation library related to the generation and execution of the test script. For example, when the failure is due to inaccurate object location information, the object mapping file can be updated based on the object identifier or hierarchy information obtained from the code under test, and the test script can locate the object through the updated object mapping file during the next execution; when the failure is due to the lack of pop-up handling in the action execution logic, the target action in the action encapsulation library can be updated; when the failure is due to the inconsistency between the order of steps in the test script and the test scenario, the business steps in the test script can be updated. After updating, the updated test script can be re-executed to verify the repair results.

[0074] Therefore, by executing test scripts and locating and updating them when they fail, a closed loop of script generation, execution, failure analysis, and repair can be formed. In this way, the generated test scripts do not merely remain at the text generation stage, but can be verified through execution results and corrected based on the reasons for failure, thereby improving the usability and stability of the test scripts.

[0075] Furthermore, after the test script finishes execution, the temporary data directory generated during automated testing can be cleaned up. The temporary data directory refers to the directory created by the test script to save intermediate files, temporary projects, log files, or runtime data. For continuously running test environments, if temporary data is retained for a long time, it may affect the results of subsequent test executions or pollute the repository. By cleaning up the temporary data directory after execution, the test environment can be kept relatively clean, reducing the impact of historical runtime data on subsequent tests.

[0076] Furthermore, the method described in this application can be integrated into continuous integration environments such as Jenkins (an open-source continuous integration tool). Within a continuous integration environment, test suite directories, object mapping files (such as map files), action wrapper libraries (such as common files), and test scripts (such as test.py) can be pulled from a code repository, and the test scripts are automatically executed after the software under test is installed. A temporary running directory can be automatically created during execution, and cleaned up after execution. Thus, the generation and execution process of test scripts can be adapted for automated build and regression testing workflows.

[0077] Based on the test script generation method provided in the above embodiments, this application embodiment can also provide a test script generation apparatus. The test script generation apparatus will now be described in conjunction with embodiments and accompanying drawings.

[0078] Figure 2 This is a schematic diagram of a test script generation device provided in an embodiment of this application. (In conjunction with...) Figure 2 As shown, the test script generation apparatus 200 provided in this application embodiment includes: The information conversion module 201 is used to convert test requirement information to obtain test scenario information; The code parsing module 202 is used to parse the code under test and obtain target information related to the interface objects of the graphical interface. The file generation module 203 is used to generate an object mapping file based on the test scenario information and the target information, wherein the object mapping file is used to define the interface object; The encapsulation library determination module 204 is used to determine the action encapsulation library based on the object mapping file, wherein the action encapsulation library is used to encapsulate the target action that interacts with the interface object. The script generation module 205 is used to generate a test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library.

[0079] Optionally, the object mapping file includes definition information of the interface object, which is related to the test scenario information. The definition information includes a business semantic name and object location information corresponding to the business semantic name. The object location information includes at least one of object identifier, control type, parent-child hierarchy, title text, visibility attribute, and logical attribute.

[0080] Optionally, the file generation module 203 is specifically used for: The interface objects actually invoked by the test scenario information are written into the object mapping file, and the object location information corresponds to the object logic identifier and / or business semantic identifier in the code under test.

[0081] Optionally, the code under test includes an interface description file and a program source code file; The code parsing module 202 is specifically used for: The interface description file is parsed to extract at least one of the following: window information, control information, title text information, and hierarchical relationship information. The program source code file is parsed to extract at least one of the following: object identification information, control type information, object creation logic, object lookup logic, action signal function, and execution path.

[0082] Optionally, the action encapsulation library includes multiple target actions, which include at least one of the following actions: loading the code under test, switching tabs, clicking a control, inputting text or a path, confirming a dialog box, handling a prompt pop-up, executing a shortcut key, executing a drag-and-drop action, waiting for the interface state, and reading the interface state.

[0083] Optionally, the test script includes assertion statements; The script generation module 205 is specifically used for: The test scenario information is verified to obtain the verification result; If the verification result indicates that the test scenario information is not covered by an existing test script, the assertion statement is generated based on the success criteria and / or assertion type in the test scenario information. The assertion statement includes at least one of the following: object existence assertion, interface state assertion, text or numerical exact match assertion, business result assertion, and exception prompt assertion.

[0084] Optionally, the test script generation device 200 further includes: The script execution module is used to execute the test script and obtain the test results. The cause localization module is used to locate the cause of failure based on failure logs, object lookup exception information, and / or execution context information when the test result indicates that the test has failed. The script update module is used to update the test script based on the failure reason to obtain the updated test script.

[0085] Furthermore, embodiments of this application also provide an electronic device, including: a processor, a memory, and a system bus; The processor and the memory are connected via the system bus; The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform any of the implementation steps of the test script generation method described above.

[0086] Furthermore, embodiments of this application also provide a computer-readable storage medium storing instructions that, when executed on an electronic device, cause any of the above-described steps of the test script generation method to be implemented.

[0087] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a media gateway, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application. It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on describing the differences from other embodiments. The same or similar parts between the various embodiments can be referred to mutually.

[0088] The system disclosed in the embodiments is described in a relatively simple manner because it corresponds to the method disclosed in the embodiments. For relevant details, please refer to the method section.

[0089] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0090] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of generating a test script, characterized by, include: The test requirement information is transformed to obtain test scenario information; The code under test is parsed to obtain target information related to the interface objects of the graphical interface; Based on the test scenario information and the target information, an object mapping file is generated, which is used to define the interface object; Based on the object mapping file, an action encapsulation library is determined, which is used to encapsulate target actions that interact with the interface object. Based on the test scenario information, the object mapping file, and the action encapsulation library, a test script is generated for the code under test.

2. The method of claim 1, wherein, The object mapping file includes the definition information of the interface object, which is related to the test scenario information. The definition information includes a business semantic name and object location information corresponding to the business semantic name. The object location information includes at least one of object identifier, control type, parent-child hierarchy, title text, visibility attribute, and logical attribute.

3. The method of claim 2, wherein, The step of generating an object mapping file based on the test scenario information and the target information includes: The interface objects actually invoked by the test scenario information are written into the object mapping file, and the object location information corresponds to the object logic identifier and / or business semantic identifier in the code under test.

4. The method of claim 1, wherein, The code under test includes an interface description file and a program source code file; The process of parsing the code under test to obtain target information related to the interface objects of the graphical interface includes: The interface description file is parsed to extract at least one of the following: window information, control information, title text information, and hierarchical relationship information. The program source code file is parsed to extract at least one of the following: object identification information, control type information, object creation logic, object lookup logic, action signal function, and execution path.

5. The method of claim 1, wherein, The action encapsulation library includes multiple target actions, which include at least one of the following actions: loading the code under test, switching tabs, clicking controls, inputting text or path, confirming dialog box, handling prompt pop-up, executing shortcut keys, executing drag and drop, waiting for interface state, and reading interface state.

6. The method of claim 1, wherein, The test script includes assertion statements; The step of generating a test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library includes: The test scenario information is verified to obtain the verification result; If the verification result indicates that the test scenario information is not covered by an existing test script, the assertion statement is generated based on the success criteria and / or assertion type in the test scenario information. The assertion statement includes at least one of the following: object existence assertion, interface state assertion, text or numerical exact match assertion, business result assertion, and exception prompt assertion.

7. The method of claim 1 to 6, wherein, After generating the test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library, the method further includes: Execute the test script to obtain the test results; If the test result indicates that the test has failed, the cause of the failure will be located based on the failure log, object lookup exception information, and / or execution context information. The test script is updated based on the reasons for the failure, resulting in an updated test script.

8. An apparatus for generating a test script, characterized by: include: The information conversion module is used to convert test requirement information into test scenario information; The code parsing module is used to parse the code under test and obtain target information related to the interface objects of the graphical interface. The file generation module is used to generate an object mapping file based on the test scenario information and the target information, wherein the object mapping file is used to define the interface object; The encapsulation library determination module is used to determine the action encapsulation library based on the object mapping file, wherein the action encapsulation library is used to encapsulate the target action that interacts with the interface object. The script generation module is used to generate a test script for the code under test based on the test scenario information, the object mapping file, and the action encapsulation library.

9. An electronic device, comprising: The device includes: a processor, a memory, and a system bus; The processor and the memory are connected via the system bus; The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform the steps of the test script generation method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the test script generation method as described in any one of claims 1 to 7.

Images