Test script generation method and device, electronic equipment and readable storage medium

Abstract

The application relates to a test script generation method and device, electronic equipment and a readable storage medium. The method comprises the following steps: acquiring an interface knowledge base corresponding to a to-be-tested interface and a test case required for testing the to-be-tested interface, wherein the interface knowledge base is used to provide basis information required for stage-by-stage verification; based on the test case, a structured case description object is constructed; based on the interface knowledge base and the case description object, an intermediate description object is generated, and the intermediate description object is subjected to stage-by-stage verification; in the case that the intermediate description object passes the verification, the intermediate description object is frozen; based on the frozen intermediate description object, a test script is generated, and the test script is subjected to consistency verification; and in the case that the test script passes the verification, the test script is output. In this way, a traditional model free reasoning process is changed into a stage-by-stage controlled generation process which is constrained and verifiable, and thus the accuracy of test script generation is improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to a test script generation method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] As the functionality of vehicle cockpits continues to increase, the interactive scenarios carried by their user interfaces are also increasing, which places higher demands on the coverage and execution efficiency of software automated testing.

[0003] In existing technologies, test script generation typically utilizes large language models to understand test cases and automatically infer executable test scripts. However, due to factors such as semantic drift, susceptibility to illusions, and attentional divergence in large language models, the accuracy of test scripts generated through free model inference is often low. Therefore, improving the accuracy of test scripts has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a test script generation method, apparatus, electronic device, and readable storage medium to solve the problem of low accuracy of test scripts generated by existing test script generation methods.

[0005] Firstly, this application provides a method for generating test scripts, the method comprising: Obtain the interface knowledge base corresponding to the interface to be tested, and the test cases required to test the interface to be tested, wherein the interface knowledge base is used to provide the basis information required for phased verification. Based on the test cases, a structured test case description object is constructed. Based on the interface knowledge base and the use case description object, an intermediate description object is generated, and the intermediate description object is verified in stages. If the intermediate description object passes the verification, the intermediate description object is frozen. Based on the frozen intermediate description object, a test script is generated, and the test script is subjected to consistency verification. If the test script passes the verification, the test script is output.

[0006] Optionally, the use case description object includes preconditions, execution steps, and expected results; The step of generating an intermediate description object based on the interface knowledge base and the use case description object includes: The page object, business operation object, or auxiliary capability object that the use case description object depends on is determined from the interface knowledge base, and the content of the first field used to characterize the business dependency declaration is determined based on the page object, the business operation object, or the auxiliary capability object. The preconditions, the execution steps, and the expected results are escaped respectively to obtain the second field content used to characterize the precondition action sequence, the third field content used to characterize the test action sequence, and the fourth field content used to characterize the assertion sequence. The contents of the first field, the second field, the third field, and the fourth field are concatenated to generate the intermediate description object.

[0007] Optionally, the step of performing phased verification on the intermediate description object includes: Based on the content of the first field, obtain the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content and / or page private rules associated with the content of the first field from the interface knowledge base; Based on the action method whitelist, the assertion method whitelist, the action method blacklist, the entry chain definition content, and / or the page private rules, the intermediate description object is subjected to phased verification.

[0008] Optionally, the phased verification includes at least one of the following: Verify whether the field content of the intermediate description object is complete; Verify whether the action name appearing in the intermediate description object belongs to the action method whitelist; Verify whether the assertion names appearing in the intermediate description object belong to the whitelist of assertion methods; Verify whether the action name appearing in the intermediate description object belongs to the action method blacklist; Verify whether the content of the first field of the intermediate description object contains framework-level dependencies; Verify whether the second field of the intermediate description object retains descriptive text; Based on the defined entry chain content, verify whether the entry chain corresponding to each element in the intermediate description object is complete; Based on the page's private rules, verify whether each page in the intermediate description object requires an additional mandatory entry point or tab switching action.

[0009] Optionally, after performing phased validation on the intermediate description object, the method further includes: If the intermediate description object fails the verification, the intermediate description object is rewritten in place until the rewritten intermediate description object passes the verification.

[0010] Optionally, freezing the intermediate description object includes: Obtain the stage identifier of the intermediate description object, the timestamp when the intermediate description object passes verification, and the digest hash value of the intermediate description object; The stage identifier, the timestamp, and the digest hash value are concatenated to obtain the version identifier corresponding to the intermediate description object; Perform a serialized snapshot on the intermediate description object to freeze the intermediate description object; The version identifier and the frozen intermediate description object are associated and stored in a preset storage area.

[0011] Optionally, before generating the test script based on the frozen intermediate description object, the method further includes: Based on the version identifier, the frozen intermediate description object is obtained from the preset storage area.

[0012] Optionally, the consistency check of the test script includes: The test script is parsed to obtain a structured call list, which includes an import list, an action list, and an assertion list. The import list is compared with the content of the first field in the frozen intermediate description object, the action list is compared with the content of the second and third fields in the frozen intermediate description object, and the assertion list is compared with the content of the fourth field in the frozen intermediate description object. Based on the comparison results, the consistency verification result of the test script is determined.

[0013] Optionally, after performing consistency verification on the test script, the method further includes: If the test script fails verification, the test script is rewritten in place until the rewritten test script passes verification.

[0014] Secondly, this application provides a test script generation apparatus, the apparatus comprising: The first acquisition module is used to acquire the interface knowledge base corresponding to the interface to be tested, and the test cases required to test the interface to be tested, wherein the interface knowledge base is used to provide the basis information required for phased verification. The building module is used to construct a structured test case description object based on the test cases; The phased verification module is used to generate intermediate description objects based on the interface knowledge base and the use case description objects, and to perform phased verification on the intermediate description objects. The freeze module is used to freeze the intermediate description object if the intermediate description object passes the verification. The consistency verification module is used to generate test scripts based on the frozen intermediate description objects and to perform consistency verification on the test scripts. The output module is used to output the test script if the test script passes the verification.

[0015] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the test script generation method described in the first aspect.

[0016] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions for executing the test script generation method described in the first aspect.

[0017] The beneficial effects of this application are: (1) This application uses the intermediate description object as the unique semantic carrier across stages. Before the test script is generated, the intermediate description object is checked in stages. After the check is passed, the intermediate description object is frozen and the test script is generated. Then, the frozen intermediate description object is used as the unique reference to check the consistency of the test script. This transforms the traditional one-time end-to-end free reasoning process of the model into a constrained, verifiable and traceable staged controlled generation process, thereby improving the accuracy of test script generation.

[0018] (2) This application uses the interface knowledge base as the basis for phased verification and imposes constraints on intermediate description objects to avoid the model generating method names, assertion names or import paths that do not exist in the interface knowledge base out of thin air, thereby further improving the accuracy of test script generation. Attached Figure Description

[0019] Figure 1 A flowchart illustrating a test script generation method provided in an embodiment of this application; Figure 2 A schematic diagram of an interface knowledge base provided in an embodiment of this application; Figure 3This is a schematic diagram of the structure of a test script generation device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0021] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] For ease of description, spatial relative terms may be used in the text to describe the relative position or movement of one element or feature relative to another element or feature, as shown in the figure. These relative terms include, for example, "inside," "outside," "middle," "outer," "below," "below," "above," "front," "back," etc. Such spatial relative terms are intended to include different orientations of the device in use or operation, other than those depicted in the figure. For example, if the device in the figure undergoes a positional flip, orientation change, or change of motion, these directional indications will change accordingly. For instance, an element described as "below other elements or features" or "below other elements or features" will subsequently be oriented "above other elements or features" or "above other elements or features." Therefore, the example term "below" can include both upper and lower orientations. The device may be otherwise oriented (rotated 90 degrees or in other directions), and the spatial relative descriptors used in the text will be interpreted accordingly.

[0023] To address the issue of low accuracy in test scripts generated by existing test script generation methods, this application provides a test script generation method, apparatus, electronic device, and readable storage medium that can improve the accuracy of test scripts.

[0024] See Figure 1 , Figure 1This is a flowchart illustrating a test script generation method provided in an embodiment of this application. Figure 1 As shown, the test script generation method may include the following steps: Step S102: Obtain the interface knowledge base corresponding to the interface to be tested, as well as the test cases required to test the interface to be tested. The interface knowledge base is used to provide the basis information required for phased verification.

[0025] Specifically, the interface to be tested can be any user interface (UI), such as the user interface in a vehicle cockpit. The test cases can be in Excel spreadsheet format, JavaScript Object Notation (JSON), or natural language text format, and can be manually written by testers. The interface knowledge base refers to a data set that systematically describes the structural information and interactive capabilities of the interface to be tested. This interface knowledge base includes at least the following information: page nodes, region nodes, and element nodes in the interface; the hierarchical relationship between nodes; the type and location information of each element; page-level entry information; page-specific rules configured for a specific target path; and the set of operation methods and assertion methods supported by each element. As an optional implementation, the interface knowledge base can be stored using a tree-structured page object model. Each page node can contain information such as the page name, page-level entry description, and a list of sub-regions; each region node can contain information such as the region name and a list of child elements or a list of nested sub-regions; each element node can contain the element name, element type (such as button, text box, switch, list item, etc.), one or more locators (such as XPath, resource-id, text matching, etc.), and the set of operation methods and assertion methods supported by the element. The operation methods and assertion methods can be registered differently according to the element type. For example, button elements can register the click operation and the assert_exists assertion, text elements can register the get_text operation and the assert_text_equals assertion, and switch elements can register the toggle operation and the assert_switch_state assertion, etc. For any uniquely identifiable element registered in the interface knowledge base, it can be referenced via a hierarchical path such as "page.subpage.element_name" or "page.region.element_name". The element's supported operation method set, assertion method set, entry point definition, and page-specific rules provide the basis for subsequent action validity checks, entry point chain integrity checks, and page-specific rule adaptation checks. If multiple candidates with the same name exist, the path is missing, or the element cannot be uniquely identified, direct mapping will not be performed; instead, the process will proceed to todos or risks.

[0026] For example, taking the user interface in a vehicle cockpit as an example, its interface knowledge base can be as follows: Figure 2 As shown, the system can first be divided into modules such as vehicle settings, navigation, and air conditioning, based on business modules. Then, for each module, determine its constituent page nodes. For example, the vehicle settings module includes two page nodes: connectivity and Bluetooth, and display and lighting; the navigation module includes one page node: search results, etc. Next, divide each page node into regions, determining the regional nodes under each page node. Finally, determine the elements contained in each regional node, obtaining the element nodes.

[0027] When acquiring the UI knowledge base corresponding to the interface to be tested, the page list and entry navigation path, as well as some special rules for certain pages (such as page-specific rules), can be manually defined first. Then, the Android Debug Bridge (ADB) is used to connect to the real vehicle hardware to automatically perform page navigation, scrolling screenshots, and dump the UI Extensible Markup Language (XML) tree to obtain the original screenshot and XML hierarchical structure of each page. Next, the stitched long screenshot and the merged XML hierarchical tree are fed into a multimodal visual model, which identifies the element type (button / switch / text box / slider, etc.), semantic name, region affiliation, and layout structure, generating structured JSON. Finally, based on the analysis results, a locator is automatically generated, and the effectiveness of the locator is verified one by one on the real device to obtain the final UI knowledge base.

[0028] Step S104: Based on the test cases, construct a structured test case description object.

[0029] Specifically, test cases can be parsed to extract information such as preconditions, execution steps, and expected results. This information can then be structured to obtain test case description objects.

[0030] Step S106: Based on the interface knowledge base and use case description object, generate intermediate description object and perform phased verification on the intermediate description object.

[0031] Specifically, the aforementioned intermediate description object serves as a unique semantic carrier across stages, and it may include structured fields such as business dependency declarations (imports), setup_actions, test step sequences (steps), assertions (assertions), cleanup_actions, todos (todos), and risks (risks).

[0032] After obtaining the interface knowledge base and use case description objects, intermediate description objects can be generated based on information such as page objects provided by the interface knowledge base and information such as preconditions, execution steps, and expected results in the use case description objects. Then, the interface knowledge base is used as the basis for phased verification to perform phased verification on the intermediate description objects.

[0033] Step S108: If the intermediate description object passes the verification, freeze the intermediate description object.

[0034] Specifically, if the intermediate description object fails validation, it can be rewritten in place; if the intermediate description object passes validation, it can be frozen to prevent the fields in the intermediate description object from being modified or added to.

[0035] Step S110: Based on the frozen intermediate description object, generate a test script and perform a consistency check on the test script.

[0036] Specifically, after the intermediate description object is frozen, test scripts can be generated based on the frozen intermediate description object, and consistency checks can be performed on the test scripts based on the frozen intermediate description object to ensure that the action names, assertion names, etc. in the test scripts are consistent with those in the intermediate description object.

[0037] Step S112: If the test script passes the verification, output the test script.

[0038] Specifically, if the test script fails the verification, the test script can be rewritten in place; if the test script passes the verification, the test script can be output to facilitate subsequent testing of the interface under test.

[0039] In this way, intermediate description objects can be used as the unique semantic carrier across stages. Before test script generation, these intermediate description objects undergo phased verification. After successful verification, the intermediate description object is frozen, and the test script is generated. Subsequently, the frozen intermediate description object serves as the sole reference for consistency verification of the test script. This transforms the traditional one-time end-to-end free inference process into a constrained, verifiable, and traceable phased controlled generation process, thereby improving the accuracy of test script generation. Furthermore, the interface knowledge base can be used as the basis for phased verification, imposing constraints on intermediate description objects and preventing the model from generating method names, assertion names, or import paths that do not exist in the interface knowledge base, further enhancing the accuracy of test script generation.

[0040] In an optional embodiment, the use case description object includes preconditions, execution steps, and expected results. Step S106 above, generating an intermediate description object based on the interface knowledge base and the use case description object, includes: Identify the page objects, business operation objects, or auxiliary capability objects that the use case description object depends on from the interface knowledge base, and determine the content of the first field used to represent the business dependency declaration based on the page objects, business operation objects, or auxiliary capability objects. The preconditions, execution steps, and expected results are escaped respectively to obtain the second field content used to represent the precondition action sequence, the third field content used to represent the test action sequence, and the fourth field content used to represent the assertion sequence. The contents of the first, second, third, and fourth fields are concatenated to generate an intermediate description object.

[0041] Specifically, when generating intermediate description objects, the page objects, business operation objects, or auxiliary capability objects that the use case description objects depend on can be determined from the interface knowledge base. Based on these objects, the content of the first field used to represent the business dependency declaration is then determined. Here, the page object refers to the page registered in the interface knowledge base, which provides various attributes and information of its elements. The business operation object refers to a business auxiliary class that encapsulates multi-step interaction processes for different pages, packaging multiple atomic operations into a single method call. For example, navigating to a destination can be written as: Open navigation, click search, enter the destination name, click OK, select a route, and confirm again. The business operation object packages these atomic operations into a reusable method; subsequently, it only needs to be imported and the destination name passed in when calling the method, improving the accuracy and readability of the script. The auxiliary capability object refers to underlying execution capabilities such as the test framework base class, vehicle bus signal injection tool, and voice injection application programming interface (API), which can be understood as some globally common, pre-encapsulated low-level test methods.

[0042] Furthermore, the preconditions, execution steps, and expected results can be escaped separately to obtain the second field content representing the precondition action sequence, the third field content representing the test action sequence, and the fourth field content representing the assertion sequence. Specifically, for preconditions, they can be classified into navigation preconditions, state preconditions, and environmental preconditions, and the executable parts can be transformed into entry chain actions and state preparation actions in the precondition action sequence. For example, "entered the Bluetooth tab" can be transformed into three actions: "enter vehicle settings, click the connection menu, and click the Bluetooth tab". For execution steps, the operations described in natural language can be mapped to specific operation method calls on registered elements in the interface knowledge base, and the reachability entry chain can be completed when the element is located in a secondary page, pop-up window, or area requiring tab switching. For expected results, they can be mapped to assertion method calls registered on elements in the interface knowledge base, and the assertions must actually verify the business state and must not degenerate into simply judging the existence of the element. When an element or method does not exist in the knowledge base, the AI ​​model is not allowed to fabricate it; the gap must be recorded in the items to be filled or the risk items. Finally, the contents of each field can be concatenated to generate an intermediate description object.

[0043] As an optional implementation, the intermediate description object includes at least the following seven types of fields: 1. Business dependency declaration (imports): Describes the page objects, business operation objects, or auxiliary capability objects that this use case actually depends on; 2. Setup Actions: Describes the navigation chain and state preparation actions that must be executed to meet the prerequisites; 3. Test Step Sequence (steps): Describes the main steps of the test; 4. Assertions: Describe the assertion actions corresponding to the expected results; 5. Cleanup Actions: Describes the cleanup actions; 6. To-dos: Items to be completed that are left unfinished when knowledge is insufficient but further processing is allowed; 7. Risks: Record knowledge gaps, semantic ambiguities, or risks requiring manual confirmation.

[0044] Here, we take the "Bluetooth connection device" test case as an example. Its corresponding structured test case description object is represented as follows: { case_id: "BT_CONNECT_001", module: "Vehicle Settings.Connections.Bluetooth", preconditions: [ "You have entered the vehicle settings Bluetooth connection tab" ], steps: [ Click on the target Bluetooth device name. Click "Confirm" in the pairing confirmation pop-up window. ], expected: [ Bluetooth connection status is displayed as connected. ], notes: "" }

[0045] Based on the interface knowledge base and the above use case description objects, the generated intermediate description object is represented as follows: { imports: [ { type: "page_object", path: "Vehicle Settings"} { type: "page_object", path: "Dock"} ], setup_actions: [ { action: "navigate_to", target: "Vehicle settings entry"}, { action: "click", target: "Link menu"}, { action: "click", target: "Bluetooth tab"} ], steps: [ { action: "click", target: "Target device element resolved"}, { action: "click", target: "Confirmation pop-up for parsed pairing - operation"} ], assertions: [ { assert: "text_equals", target: "Vehicle Settings.Connectivity.Bluetooth.Bag Status_Display", Expected: "Connected" } ], cleanup_actions: [], todos: [], risks: [] }

[0046] The generation of this intermediate description object can be performed by an agent. In this phase, the agent is configured as a planner, which first reads the page knowledge file involved in the test cases, obtains the paths, operation method sets, assertion method sets, and entry point definitions of registered elements, and then only allows the reference of names and methods already registered in the interface knowledge base during subsequent inference.

[0047] In this way, intermediate description objects can be accurately generated based on the interface knowledge base and test case description objects. This makes it convenient to use the intermediate description objects as the unique semantic carrier across stages to participate in processes such as stage verification, test script generation, and test script consistency verification, thereby improving the accuracy of test script generation.

[0048] In an optional embodiment, step S106, performing a phased verification of the intermediate description object, includes: Based on the content of the first field, retrieve the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content and / or page private rules associated with the content of the first field from the interface knowledge base; Based on the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content and / or page private rules, the intermediate description object is validated in stages.

[0049] Specifically, the first field mentioned above is the business dependency declaration field, which records the page object paths (such as "vehicle settings", "Dock bar", etc.) that the test case depends on. When the phased verification starts, each page object path declared in the first field is first parsed. Then, using these paths as indexes, the set of verification rules associated with each page object is extracted from the interface knowledge base. The action method whitelist refers to the set of all legal operation method names supported by registered elements on the page, such as click, long_press, get_text, wait, etc. The assertion method whitelist refers to the set of all legal assertion method names supported by registered elements on the page, such as assert_exists, assert_text_equals, assert_switch_state, etc. The action method blacklist refers to the set of method names or method aliases explicitly prohibited from use on the page. For example, some frameworks name the click operation as tap or select, but according to the interface knowledge base specifications, click should be used uniformly; therefore, tap and select are blacklisted. The aforementioned entry chain definition refers to the path description of the hierarchical entry nodes traversed from the root page or navigation start page to the target page. The aforementioned page-specific rules refer to additional entry chain requirements configured for specific target paths. For example, assuming a path prefix matches "vehicle settings.connection.Bluetooth", then setup_actions must cover the mandatory targets such as "vehicle settings entry", "connection menu", and "Bluetooth tab".

[0050] When performing phased validation on intermediate description objects, you can first perform phased validation on the intermediate description objects based on the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content and / or page private rules, and then perform phased validation on the intermediate description objects based on the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content and / or page private rules.

[0051] In this way, by dynamically retrieving validation rules using the dependency path declared in the first field as an index, it ensures that the validation rules accurately correspond to the actual page objects involved in the current test case, avoiding validation noise or rule bloat caused by loading irrelevant page rules. Simultaneously, based on action method whitelists, assertion method whitelists, action method blacklists, entry chain definitions, and / or page-specific rules, intermediate description objects are validated in stages, achieving comprehensive quality control: whitelist validation prevents the model from fabricating non-existent operation methods or assertion methods; blacklist validation prevents the use of deprecated or non-standard aliases; entry chain validation ensures that the generated script can actually reach the target business state instead of remaining on an error page; and page-specific rule validation ensures that the special navigation requirements of specific pages are met. Multi-dimensional validation forms multiple lines of defense before code generation, fundamentally reducing the probability of runtime errors in the final script.

[0052] In one optional embodiment, the phased verification includes at least one of the following: Verify that the field content of the intermediate description object is complete; Verify whether the action names appearing in the intermediate description object belong to the action method whitelist; Verify whether the assertion names appearing in the intermediate description object belong to the assertion method whitelist; Verify whether the action names appearing in the intermediate description object belong to the action method blacklist; Verify whether the first field of the intermediate description object contains framework-level dependencies; Verify whether the second field of the intermediate description object retains descriptive text; Based on the entry chain definition, verify whether the entry chain corresponding to each element in the intermediate description object is complete. Based on page-specific rules, verify whether each page in the intermediate description object requires additional mandatory entry points or tab switching actions.

[0053] Specifically, the aforementioned field content integrity verification refers to checking whether the intermediate description object has all the necessary top-level fields and whether each field has a valid value. The intermediate description object must include business dependency declaration fields, pre-action sequence fields, test step sequence fields, and assertion sequence fields. It may also include optional fields such as cleanup action sequence fields, fields to be completed, and risk item fields. For example, if a generated intermediate description object is missing the assertions field, or if the assertions field has an empty array value, it indicates that the field content is incomplete and the verification fails. This ensures that the intermediate description object conforms to predetermined specifications at the structural level, preventing data from being read incorrectly in subsequent code generation stages due to missing fields or incorrect formatting, and also preventing the generated test scripts from lacking verification logic due to empty assertion sequences.

[0054] The above-mentioned action method legality verification checks the "action" field value of each action entry in the preceding action sequence field and the test step sequence field of the intermediate description object. This value is compared with the action method whitelist obtained from the interface knowledge base. If the action name is not in the whitelist, it is determined to be a fictitious or illegal action, and a failure is recorded. It is worth noting that the action method whitelists differ for different target pages; therefore, the same action name may yield different verification results in different page contexts. For example, if the action `click_and_hold` appears in the `steps` field of the intermediate description object, but `click_and_hold` is not in the action method whitelist, the verification module determines that the action is illegal. This prevents the large language model from generating unregistered operation calls in the interface knowledge base out of thin air simply because it has seen certain method names in the training data, suppressing the generation of illusions from the source.

[0055] The validity check of the aforementioned assertion method examines the "assert" field value of each assertion entry within the assertion sequence field of the intermediate description object. This value is compared to a whitelist of assertion methods retrieved from the interface knowledge base. If an assertion name is not in the whitelist, it is considered an illegal assertion, and the failure is recorded. The assertion method whitelist is also bound to the target page; different types of elements register different assertion methods. For example, text elements register the `assert_text_equals` assertion, switch elements register the `assert_switch_state` assertion, and list elements register the `assert_list_not_empty` assertion. This ensures that the generated test script only uses the verification methods actually registered in the interface knowledge base, preventing the model from generating non-existent or incompatible assertion calls, avoiding undefined assertion method errors during script runtime, and preventing assertions from degenerating into weak validation behavior that only checks existence, as weak validation often uses simple assertion names fabricated by the model.

[0056] The aforementioned action method alias or obsolete name validation checks the action names of each action item in the preceding action sequence and test step sequence, but the judgment logic is the opposite of whitelist validation. If an action name is in the action method blacklist, the validation fails. The blacklist mechanism disables two types of action names: the first is obsolete method names that may still be output by the model; the second is different aliases that implement the same operation. To maintain consistent coding style and ensure method existence, the system prohibits the use of aliases and forces the use of standardized names. Thus, action method blacklist validation and whitelist validation form a double defense: the whitelist ensures method existence, and the blacklist ensures method standardization. The blacklist mechanism effectively prevents the model from using common aliases or obsolete method names found in the training data, ensuring compatibility and consistent coding style across different framework versions of the generated test scripts, and reducing maintenance costs caused by inconsistent method naming.

[0057] The aforementioned framework-level dependencies refer to infrastructure dependencies bound to the target testing framework, such as built-in modules of Python's unittest or pytest frameworks, base classes of third-party testing libraries, or runtime environment dependencies. The first field is the business dependency declaration field, designed to declare business-level dependencies such as page objects, business operation objects, or auxiliary capability objects that the test case depends on. Framework-level dependencies should be automatically added by the code generation module based on the target framework type, and should not be declared manually by the agent during the intermediate description object generation stage. This validation item checks each dependency declaration in the first field; if it finds any framework-level import paths or module names, it is considered a mixed-in framework-level dependency, and the validation fails. This ensures that the intermediate description object only carries business semantic information and does not contain framework implementation details.

[0058] The aforementioned descriptive text refers to natural language descriptions or annotations that have not been translated into executable actions. The second field, the pre-action sequence field, is designed to carry a sequence of executable action entries. Each action should be a programmatic instruction with a clear action name and target element, rather than a human-readable descriptive sentence. This validation check examines each entry in the second field. If an entry's structure does not conform to the action entry format definition (e.g., lacking an `action` or `target` field), or if its content is a natural language description rather than an executable action call, it is determined to contain descriptive text, and the validation fails. This forces that preconditions must be fully translated into an executable action sequence, preventing descriptive text from being directly passed to the code generation stage, thus preventing the generated script from lacking true navigation logic.

[0059] The aforementioned entry chain integrity check examines whether the sequence of preceding actions covers all intermediate navigation nodes required to reach the page containing the target element from the system's initial state. For each page in the interface knowledge base, the system stores a complete entry chain definition from the root page to that page, i.e., an ordered list of required nodes. When the test step sequence of an intermediate description object references a target element located on a deep page, its target path implicitly indicates the page's position in the interface hierarchy. This check item parses the target element path referenced by each action item in the test step sequence, retrieves the complete entry chain required to reach that path from the interface knowledge base, and then checks whether the preceding action sequence contains each required node in the entry chain in sequence. This ensures that the test script can completely reproduce the navigation path when entering a deep page, rather than assuming the program is already on a deep page and skipping necessary intermediate steps. This directly solves the defect pointed out in the background technology that "descriptive preconditions are not converted into executable entry chain actions, and the generated script cannot truly reach the target business state," ensuring that the generated script can actually reach the target page in the real running environment.

[0060] The aforementioned page-specific rule validation complements and enhances the entry chain integrity validation. Entry chain validation is based on general navigation requirements of the page hierarchy, while page-specific rule validation is based on specific constraints configured for particular target paths. Different pages may have their own unique access prerequisites, which are not included in the general entry chain definition but are stored separately as page-specific rules. During validation, the target paths referenced by each action entry in the intermediate description object are traversed, and each path is compared with the matching prefix of the page-specific rule. If a private rule is matched, the system checks whether the prerequisite action sequence contains all the additional nodes required by that rule. This allows the system to handle complex page scenarios with special prerequisites, preventing personalized navigation needs that cannot be covered by general entry chain validation from being ignored. This mechanism decouples the page's special access constraints from the page hierarchy, enabling validation rules to flexibly adapt to the personalized needs of different pages, further improving the accuracy of script generation in complex interface scenarios and its ability to accurately reach the target business state.

[0061] In an optional embodiment, after step S106 above, which involves performing a phased verification on the intermediate description object, the method further includes: If the intermediate description object fails the validation, the intermediate description object is rewritten in place until the rewritten intermediate description object passes the validation.

[0062] Specifically, in-situ rewriting refers to the process where, after an intermediate description object fails a stage of validation, the current intermediate description object is not discarded, nor is the process reverted to the test case parsing or intermediate description object generation stage to start over. Instead, it uses the currently failed intermediate description object as a basis and performs targeted corrections only on the specific issues and locations indicated in the validation failure list. The core characteristic of in-situ rewriting is that it is "in-situ," meaning the correction operation occurs within the data structure of the current intermediate description object, and the scope of correction is limited to the specific field entries marked as failed, while the parts that have passed validation are fully preserved.

[0063] This ensures the accuracy and efficiency of the correction. Targeted correction only processes specific entries marked as failed, avoiding the high computational cost of overall regeneration. More importantly, it prevents the risk of correcting one problem affecting or even destroying previously correct content. Because the correction is based on a structured list of failure reasons rather than vague natural language feedback, the rewriter can accurately locate the problem's position and type, making the correction operation clearly targeted and converging quickly.

[0064] In an optional embodiment, step S108, freezing the intermediate description object, includes: Obtain the stage identifier of the intermediate description object, the timestamp when the intermediate description object passes verification, and the digest hash value of the intermediate description object; The version identifier corresponding to the intermediate description object is obtained by concatenating the stage identifier, timestamp, and digest hash value. Perform a serialized snapshot on the intermediate description object to freeze the intermediate description object; The version identifier and the frozen intermediate description object are associated and stored in the preset storage area.

[0065] Specifically, the aforementioned stage identifier can refer to identification information used to uniquely identify the generation stage to which the current intermediate description object belongs. In the phased generation process of this invention, the generation of intermediate description objects for each test case has a clear stage attribute. The stage identifier can be composed of the test case number, module name, and stage sequence number, used to distinguish intermediate description objects generated by different test cases and different rounds. The aforementioned timestamp refers to the moment when the intermediate description object last passed the stage verification. The aforementioned digest hash value refers to a fixed-length hash digest calculated from the content data of the intermediate description object (including all its fields and field values) using a cryptographic hash algorithm (such as SHA-256, MD5, etc.). After obtaining the stage identifier, the timestamp when the intermediate description object passed verification, and the digest hash value of the intermediate description object, the stage identifier, timestamp, and digest hash value can be combined into a complete string in a predetermined order. The concatenated string is the version identifier (contract_version_id) of the intermediate description object. This version identifier corresponds one-to-one with the frozen intermediate description object and is the unique credential for subsequent stages to reference the frozen product.

[0066] The aforementioned serialization snapshot refers to the process of converting the intermediate description object data structure in memory into a persistent byte sequence or text format, representing a complete record of the intermediate description object's state at a specific moment. After performing a serialization snapshot on the intermediate description object, the serialized data is stored in a preset storage area in read-only mode. During storage, write protection can be applied to this data, ensuring that any subsequent operations (including code generation modules, consistency verification modules, or other system components) can only read the data and cannot modify, delete, or append to it. Write permissions are strictly limited to the freeze operation itself; once the freeze is complete, the write channel is closed.

[0067] This allows the verified intermediate description objects to be frozen, ensuring the immutability of the frozen output. Even if the agent or code generation module in subsequent stages has bugs or malicious behavior, it cannot destroy the frozen intermediate description objects.

[0068] In an optional embodiment, before step S110 above, which generates the test script based on the frozen intermediate description object, the method further includes: Based on the version identifier, retrieve the frozen intermediate description object from the preset storage area.

[0069] Specifically, before generating the test script, the version identifier (contract_version_id) corresponding to the frozen intermediate description object can be obtained. This version identifier serves as the unique credential for data retrieval, locating the serialized snapshot data associated with the version identifier in the storage area. This data is then converted from its storage format (such as JSON strings, binary sequences, etc.) back into a structured data object, enabling the code generation module to read each element (business dependency declarations, pre-action sequences, test step sequences, assertion sequences, etc.) of the intermediate description object field by field. When generating the test script, the elements of the intermediate description object can be mapped according to preset mapping rules to obtain the test script. Specifically, the `imports` field can be converted into import statements according to the target framework's import syntax, importing only declared modules; the `setup_actions` field can be mapped sequentially to the initialization logic in the test lifecycle methods, with each action calling the target element's operation method through a chained path via the page object; the `steps` field can be mapped sequentially to the operation calls in the test body; the `assertions` field can be mapped to the target framework's assertion method calls, and must not degenerate into existence checks; the `cleanup_actions` field can be mapped to recovery logic; and the `todos` and `risks` fields can be marked as comments in the script, and must not be automatically added as executable code.

[0070] Taking the intermediate description object corresponding to the test cases of the Bluetooth connection device mentioned above as an example, the generated test script is shown below:

[0071] In this way, the mechanism of obtaining frozen intermediate description objects from the preset storage area through version identifiers decouples data storage and data consumption. During the code generation stage, there is no need to care about how the frozen data is generated, what verifications it passes, or where it is stored. A complete intermediate description object with confirmed semantics can be obtained simply by using the version identifier.

[0072] In an optional embodiment, step S110, performing a consistency check on the test script, includes: The test script is parsed to obtain a structured call list, which includes an import list, an action list, and an assertion list. The import list is compared with the content of the first field in the frozen intermediate description object, the action list is compared with the content of the second and third fields in the frozen intermediate description object, and the assertion list is compared with the content of the fourth field in the frozen intermediate description object. Based on the comparison results, the consistency verification result of the test script is determined.

[0073] Specifically, when performing consistency checks on the test script, the test script can be parsed to obtain a structured call list, which includes an import list, an action list, and an assertion list. The import list is formed by extracting all import statements, the action list by extracting all page object method calls, and the assertion list by extracting all assert statements. Then, the import list is compared with the first field (i.e., the imports field) of the frozen intermediate description object; the action list is compared with the second field (i.e., the setup_actions field) and the third field (i.e., the steps field) of the frozen intermediate description object; and the assertion list is compared with the fourth field (i.e., the assertions field) of the frozen intermediate description object. Fields present in the frozen intermediate description object but missing in the test script are marked as "omission / deviation"; fields present in the test script but not in the frozen intermediate description object are marked as "unauthorized addition." This yields the consistency check result of the test script.

[0074] The key verification dimensions involved in the above consistency verification are explained as follows: The so-called disabled runtime mode check refers to checking whether there are any implementation methods in the test script that bypass declared page objects or freeze plans, temporarily splice locators at runtime, freely search for elements, or directly generate unregistered calls. If so, it is judged as a deviation; The so-called complete reference of non-pre-target means that, except for the pre-targets used for navigation and state preparation in setup_actions, the business targets corresponding to steps and assertions must be actually referenced and executed in the code. If they are missing, it is judged as a deviation.

[0075] For example, in some interfaces, the expected result after a list refresh cannot be replaced by assertions such as "the title still exists" or "the refresh icon still exists," but must be refined to stronger semantic assertions such as "the list is not empty" or "dynamic text was read." Large language models tend to generate such weakened assertions when there are no constraints. This invention intercepts these assertions during the code production stage through consistency checks to prevent semantic degradation of assertions.

[0076] This effectively prevents unverified calls from being introduced during the test script generation phase due to model divergence, ensuring that the final output of the entire script generation process has high accuracy and traceability.

[0077] In an optional embodiment, after step S110 above, which involves performing a consistency check on the test script, the method further includes: If the test script fails verification, the test script is rewritten in place until the rewritten test script passes verification.

[0078] Specifically, after a test script fails verification, instead of reverting to the intermediate description object generation or freezing stage to restart, the process uses the currently failed test script code as a basis and only performs targeted corrections on the specific deviations pointed to in the consistency verification failure list. The core feature of in-place rewriting is that it is in-place, meaning the correction operation occurs within the current test script code, and the scope of the correction is limited to the specific lines or segments of code marked as deviations, while the parts that have passed verification are completely preserved.

[0079] In this way, only the specific code statements marked as deviations are processed, avoiding the high computational overhead and time delays of regenerating the entire script. More importantly, it prevents the correction of one deviation from breaking other code sections that have already passed consistency checks. Because the correction is based on a structured list of deviations rather than vague natural language feedback, the code rewriter can accurately locate the deviation position and type, making the correction operation clearly targeted. It is also important to emphasize that during the in-place rewriting of the test script, the frozen intermediate description objects remain in a read-only state and cannot be modified.

[0080] See Figure 3 , Figure 3 This is a schematic diagram of a test script generation device provided in an embodiment of this application. Figure 3 As shown, the test script generation device 300 may include: The first acquisition module 302 is used to acquire the interface knowledge base corresponding to the interface to be tested, as well as the test cases required to test the interface to be tested. The interface knowledge base is used to provide the basis information required for phased verification. Module 304 is used to build a structured test case description object based on test cases; The phased verification module 306 is used to generate intermediate description objects based on the interface knowledge base and use case description objects, and to perform phased verification on the intermediate description objects. The freeze module 308 is used to freeze the intermediate description object if the intermediate description object passes the verification. The consistency verification module 310 is used to generate test scripts based on the frozen intermediate description objects and to perform consistency verification on the test scripts. Output module 312 is used to output the test script if the test script passes the verification.

[0081] Furthermore, the use case description object includes preconditions, execution steps, and expected results; the phased verification module 306 includes: The first determination submodule is used to determine the page object, business operation object or auxiliary capability object that the use case description object depends on from the interface knowledge base, and to determine the content of the first field used to represent the business dependency declaration based on the page object, business operation object or auxiliary capability object. The escape submodule is used to escape the preconditions, execution steps and expected results respectively, to obtain the second field content used to represent the precondition action sequence, the third field content used to represent the test action sequence and the fourth field content used to represent the assertion sequence. The first concatenation submodule is used to concatenate the contents of the first field, the second field, the third field, and the fourth field to generate an intermediate description object.

[0082] Furthermore, the phased verification module 306 also includes: The first acquisition submodule is used to retrieve, based on the content of the first field, the whitelist of action methods, the whitelist of assertion methods, the blacklist of action methods, the entry chain definition content and / or the private rules of the page associated with the content of the first field from the interface knowledge base. The validation submodule is used to perform phased validations on intermediate description objects based on the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content, and / or page private rules.

[0083] Furthermore, the phased verification includes at least one of the following: Verify that the field content of the intermediate description object is complete; Verify whether the action names appearing in the intermediate description object belong to the action method whitelist; Verify whether the assertion names appearing in the intermediate description object belong to the assertion method whitelist; Verify whether the action names appearing in the intermediate description object belong to the action method blacklist; Verify whether the first field of the intermediate description object contains framework-level dependencies; Verify whether the second field of the intermediate description object retains descriptive text; Based on the entry chain definition, verify whether the entry chain corresponding to each element in the intermediate description object is complete. Based on page-specific rules, verify whether each page in the intermediate description object requires additional mandatory entry points or tab switching actions.

[0084] Furthermore, the test script generation device 300 also includes: The first rewrite module is used to rewrite the intermediate description object in place if the intermediate description object fails the verification, until the rewritten intermediate description object passes the verification.

[0085] Furthermore, the freeze module 308 includes: The second acquisition submodule is used to acquire the stage identifier of the intermediate description object, the timestamp when the intermediate description object passes verification, and the digest hash value of the intermediate description object; The second splicing submodule is used to splice the stage identifier, timestamp, and digest hash value to obtain the version identifier corresponding to the intermediate description object; The freeze submodule is used to perform a serialized snapshot of the intermediate description object in order to freeze the intermediate description object; The storage submodule is used to associate and store the version identifier and the frozen intermediate description object in a preset storage area.

[0086] Furthermore, the test script generation device 300 also includes: The second acquisition module is used to retrieve the frozen intermediate description object from the preset storage area based on the version identifier.

[0087] Furthermore, the consistency verification module 310 includes: The parsing submodule is used to parse the test script to obtain a structured call list, which includes an import list, an action list, and an assertion list. The comparison submodule is used to compare the import list with the content of the first field in the frozen intermediate description object, compare the action list with the content of the second and third fields in the frozen intermediate description object, and compare the assertion list with the content of the fourth field in the frozen intermediate description object. The second determination submodule is used to determine the consistency verification result of the test script based on the comparison results.

[0088] Furthermore, the test script generation device 300 also includes: The second rewrite module is used to rewrite the test script in place if the test script fails the verification, until the rewritten test script passes the verification.

[0089] It should be noted that the test script generation device 300 can implement the test script generation method provided in any of the aforementioned method embodiments and achieve the same technical effect, which will not be elaborated here.

[0090] like Figure 4 As shown, this application embodiment also provides an electronic device, including a processor 411, a communication interface 412, a memory 413 and a communication bus 414, wherein the processor 411, the communication interface 412 and the memory 413 communicate with each other through the communication bus 414. Memory 413 is used to store computer programs; In one embodiment of this application, when the processor 411 executes the program stored in the memory 413, it implements the test script generation method provided in any of the foregoing method embodiments.

[0091] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the test script generation method provided in any of the foregoing method embodiments.

[0092] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0093] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable 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, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0094] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0095] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement 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 claimed herein.

Claims

1. A method for generating test scripts, characterized in that, The method includes: Obtain the interface knowledge base corresponding to the interface to be tested, and the test cases required to test the interface to be tested, wherein the interface knowledge base is used to provide the basis information required for phased verification. Based on the test cases, a structured test case description object is constructed. Based on the interface knowledge base and the use case description object, an intermediate description object is generated, and the intermediate description object is verified in stages. If the intermediate description object passes the verification, the intermediate description object is frozen. Based on the frozen intermediate description object, a test script is generated, and the test script is subjected to consistency verification. If the test script passes the verification, the test script is output.

2. The method according to claim 1, characterized in that, The use case description object includes preconditions, execution steps, and expected results; The step of generating an intermediate description object based on the interface knowledge base and the use case description object includes: The page object, business operation object, or auxiliary capability object that the use case description object depends on is determined from the interface knowledge base, and the content of the first field used to characterize the business dependency declaration is determined based on the page object, the business operation object, or the auxiliary capability object. The preconditions, the execution steps, and the expected results are escaped respectively to obtain the second field content used to characterize the precondition action sequence, the third field content used to characterize the test action sequence, and the fourth field content used to characterize the assertion sequence. The contents of the first field, the second field, the third field, and the fourth field are concatenated to generate the intermediate description object.

3. The method according to claim 2, characterized in that, The step-by-step verification of the intermediate description object includes: Based on the content of the first field, obtain the action method whitelist, assertion method whitelist, action method blacklist, entry chain definition content and / or page private rules associated with the content of the first field from the interface knowledge base; Based on the action method whitelist, the assertion method whitelist, the action method blacklist, the entry chain definition content, and / or the page private rules, the intermediate description object is subjected to phased verification.

4. The method according to claim 3, characterized in that, The phased verification includes at least one of the following: Verify whether the field content of the intermediate description object is complete; Verify whether the action name appearing in the intermediate description object belongs to the action method whitelist; Verify whether the assertion names appearing in the intermediate description object belong to the whitelist of assertion methods; Verify whether the action name appearing in the intermediate description object belongs to the action method blacklist; Verify whether the content of the first field of the intermediate description object contains framework-level dependencies; Verify whether the second field of the intermediate description object retains descriptive text; Based on the defined entry chain content, verify whether the entry chain corresponding to each element in the intermediate description object is complete; Based on the page's private rules, verify whether each page in the intermediate description object requires an additional mandatory entry point or tab switching action.

5. The method according to claim 3, characterized in that, After performing phased validation on the intermediate description object, the method further includes: If the intermediate description object fails the verification, the intermediate description object is rewritten in place until the rewritten intermediate description object passes the verification.

6. The method according to claim 1, characterized in that, Freezing the intermediate description object includes: Obtain the stage identifier of the intermediate description object, the timestamp when the intermediate description object passes verification, and the digest hash value of the intermediate description object; The stage identifier, the timestamp, and the digest hash value are concatenated to obtain the version identifier corresponding to the intermediate description object; Perform a serialized snapshot on the intermediate description object to freeze the intermediate description object; The version identifier and the frozen intermediate description object are associated and stored in a preset storage area.

7. The method according to claim 6, characterized in that, Before generating the test script based on the frozen intermediate description object, the method further includes: Based on the version identifier, the frozen intermediate description object is obtained from the preset storage area.

8. The method according to claim 1, characterized in that, The consistency check of the test script includes: The test script is parsed to obtain a structured call list, which includes an import list, an action list, and an assertion list. The import list is compared with the content of the first field in the frozen intermediate description object, the action list is compared with the content of the second and third fields in the frozen intermediate description object, and the assertion list is compared with the content of the fourth field in the frozen intermediate description object. Based on the comparison results, the consistency verification result of the test script is determined.

9. The method according to claim 8, characterized in that, After performing consistency verification on the test script, the method further includes: If the test script fails verification, the test script is rewritten in place until the rewritten test script passes verification.

10. A test script generation device, characterized in that, The device includes: The first acquisition module is used to acquire the interface knowledge base corresponding to the interface to be tested, and the test cases required to test the interface to be tested, wherein the interface knowledge base is used to provide the basis information required for phased verification. The building module is used to construct a structured test case description object based on the test cases; The phased verification module is used to generate intermediate description objects based on the interface knowledge base and the use case description objects, and to perform phased verification on the intermediate description objects. The freeze module is used to freeze the intermediate description object if the intermediate description object passes the verification. The consistency verification module is used to generate test scripts based on the frozen intermediate description objects and to perform consistency verification on the test scripts. The output module is used to output the test script if the test script passes the verification.

11. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the test script generation method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The device stores computer-executable instructions for performing the test script generation method according to any one of claims 1-9.

Images