Automatic test code generation method and device and electronic equipment

Abstract

The invention provides an automatic test code generation method and device and electronic equipment, and relates to the technical field of automatic test code generation, and the method comprises the following steps: initializing a structured test knowledge base; extracting test case information from the test data source so as to construct a standardized problem dictionary comprising case identifiers, test levels, step types and associated scenes through the test case information; generating a new test keyword code by sequentially executing script-based concurrent preprocessing, recall process concurrent retrieval and in-script concurrent generation on the question dictionary; performing intelligent unified verification on the new test keyword code; calling a preset use case template, filling the question dictionary information and the keyword codes conforming to the target test specification to generate complete test codes, and updating newly generated keywords to the structured test knowledge base; the test code can be automatically and accurately generated.

Description

Technical Field

[0001] This invention relates to the field of automatic test code generation technology, and in particular to a method, apparatus and electronic device for automatic test code generation. Background Technology

[0002] Against the backdrop of rapid development in automotive intelligence, automotive testing needs to cover multi-dimensional functional, performance, and safety testing of cockpit HMI, ADAS, and other systems. A single vehicle model may have thousands of cockpit test cases with frequent iterations. Traditional automated test script development relies on manual parsing of test cases and writing keyword code, taking an average of 1-2 hours per case, which is difficult to adapt to the needs of rapid iteration. At the same time, the code for the same or similar test actions (such as "turn on the air conditioner") is scattered in different scripts and cannot be reused in a unified manner. When the vehicle system version is updated (such as UI element ID changes), the associated scripts must be modified manually one by one, resulting in extremely high maintenance costs. In existing technologies, although there have been attempts to use AI to generate test scripts, they are limited by the scattered storage of knowledge (only storing simple "action-method" mappings in the database, lacking dimensional information such as UI elements and parameter rules) and the insufficient accuracy of AI generation. The generated code still requires a lot of manual debugging and cannot meet the high efficiency and high accuracy requirements of automotive testing. Therefore, how to automatically and accurately generate test code has become an urgent technical problem to be solved. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to a first aspect of this application, a method for automatically generating test code is provided, comprising: Initialize a structured test knowledge base; the structured test knowledge base stores multi-dimensional test knowledge, and the test knowledge supports semantic retrieval and dynamic updates; Extract test case information from the test data source to build a standardized issue dictionary containing test case identifiers, test levels, step types, and associated scenarios. New test keyword codes are generated by sequentially performing script-based concurrent preprocessing, concurrent retrieval during the recall process, and concurrent generation within the script on the standardized question dictionary. The new test keyword code is intelligently and uniformly validated, and if the validation passes, the keyword code that conforms to the target test specification is obtained; The system calls a preset test case template, fills in the problem dictionary information and keyword codes that conform to the target test specifications to generate complete test code, and updates the newly generated keywords to the structured test knowledge base.

[0004] According to another aspect of this application, an automatic test code generation apparatus is also provided, the apparatus comprising: An initialization module is used to initialize a structured test knowledge base; the structured test knowledge base stores multi-dimensional test knowledge, and the test knowledge supports semantic retrieval and dynamic updates; The test case information extraction module is used to extract test case information from the test data source, so as to build a standardized problem dictionary containing test case identifier, test level, step type and associated scenario; The question dictionary processing module is used to generate new test keyword codes by sequentially performing script-based concurrent preprocessing, concurrent retrieval during the recall process, and concurrent generation within the script on the standardized question dictionary. The verification module is used to perform intelligent and unified verification on the new test keyword code. If the verification passes, the keyword code that conforms to the target test specification is obtained. The calling module is used to call a preset test case template, fill in the problem dictionary information and the verified keyword code to generate complete test code, and update the newly generated keywords to the structured test knowledge base.

[0005] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned test code automatic generation device, or the processor performing the method as described in any of the first aspects.

[0006] The present invention has at least the following beneficial effects: The automatic test code generation method of this invention effectively solves the problems of scattered storage and difficulty in reuse of test knowledge in the prior art by initializing and storing a structured test knowledge base that supports semantic retrieval and dynamic updates. This forms a knowledge closed loop of "generation-storage-reuse," significantly improving the reuse rate of identical or similar test actions. Furthermore, the standardized problem dictionary enables the standardized processing of test case information, providing a unified data foundation for subsequent automated generation. Finally, a three-stage pipeline concurrent processing mode, consisting of concurrent preprocessing by script, concurrent retrieval during the recall process, and concurrent generation within the script, replaces the traditional step-by-step approach. The streamlined processing significantly shortens the time required to generate test code and greatly improves generation efficiency. Combined with intelligent unified verification, it ensures that the generated code conforms to the target test specifications, reducing the code error rate. Finally, through the filling of preset test case templates and dynamic updates of the knowledge base, it not only achieves the rapid assembly of complete test code, but also enables automatic adaptation of associated scripts in scenarios such as vehicle system version updates, requiring only updates to relevant information in the knowledge base. This reduces manual maintenance costs and effectively solves the core pain points of traditional manual development, such as low efficiency and poor reusability, as well as the insufficient accuracy and cumbersome maintenance of existing AI generation solutions. It meets the needs of efficient iteration and high-precision generation in test scenarios. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A flowchart of the test code automatic generation method provided in the embodiments of the present invention; Figure 2 This is a schematic diagram illustrating the automated generation of test code based on a knowledge base and a large model, as provided in an embodiment of the present invention. Detailed Implementation

[0009] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0010] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0011] The following will refer to Figure 1 The flowchart shown illustrates a method for automatically generating test code, introducing one such method.

[0012] The method for automatically generating test code may include the following steps: S100, Initialize the structured test knowledge base; the structured test knowledge base stores multi-dimensional test knowledge, and the test knowledge supports semantic retrieval and dynamic updates.

[0013] In this embodiment, this step is the "knowledge foundation" of the method, the core of which is to build a structured system that stores multi-dimensional test knowledge and supports semantic retrieval and dynamic updates.

[0014] Import historical test data: Enter verified test knowledge, which must meet the classification and format standards of the automotive testing field. For example: Test action description: Classified by P (pre-position) / A (execute) / E (expected), such as "P - vehicle is in P gear", "A - press the steering wheel volume + button", "E - media volume increases by 2 levels".

[0015] Corresponding method names: conform to Python naming conventions, such as "checkVehicleInPGear()", "pressSteeringWheelVolumeUp()", and "verifyMediaVolumeIncrease()".

[0016] Code snippet: Initialize adb → Update UI → Get element → Operate on element, example code is as follows: def pressSteeringWheelVolumeUp(): #1. Initialize the ADB device (connect to the vehicle's infotainment system) ad=svw.ivi().adb #2. Update the UI automation tool (ensure it recognizes the latest UI). ad.updateUiAutomator() #3. Retrieve UI elements (read element IDs from the knowledge base) volume_up_btn=ad.getNodesById("steering_wheel_volume_up") if not volume_up_btn: cvtest.fail("Steering wheel volume + key element not found") #4. Perform the operation (click) volume_up_btn[0].click() cvtest.logi("The volume + button on the steering wheel has been pressed").

[0017] UI element information: Stored in the format of "element ID|module|applicable scenario", such as "steering_wheel_volume_up|steering wheel control module|media volume adjustment scenario".

[0018] Define the knowledge structure: According to the document requirements, it is classified by test module (cockpit, chassis, ADAS). Each knowledge item contains 9 core fields, including action_desc (action description), semantic_vector (semantic vector generated by the algorithm semantic model, used for subsequent similarity judgment), param_rules (parameter rules, such as the default value of "click_count=1"), scene (applicable scenario), etc.

[0019] Supports dynamic updates: Reserved interfaces for the subsequent addition of newly generated keywords to the database, and for updating the "reuse priority" based on execution feedback (e.g., "priority is increased if three consecutive executions are successful").

[0020] This structured knowledge base breaks through the limitations of traditional test knowledge, which simply stores binary mappings of "action-method". By centrally storing multi-dimensional knowledge including test action descriptions (categorized by P_ / A_ / E_), corresponding method names, code snippets (following the four-stage standard of UI operation), UI element information (including element ID and applicable modules), parameter rules, applicable scenarios, and semantic vectors, it ensures that the information required for the entire test script generation process (from retrieval to AI generation) is complete and available, avoiding generation interruptions or manual completion operations due to knowledge gaps. Its supported semantic retrieval function, relying on semantic vectors generated by the algorithm's semantic model, can accurately identify test actions that are "speech-different but semantically similar" (such as "press the steering wheel volume + button" and "press the square"). The system, which includes features like the "steering wheel volume up button," addresses the issue of missing similar actions in traditional literal matching searches. This increases the reusability of identical or similar test actions to ≥80%, significantly reducing redundant development. Furthermore, its dynamic update capability enables the automatic storage of newly generated keywords (including code and UI element information) and updates the knowledge reuse priority based on script execution feedback (such as continuous successful runs). This forms a closed knowledge loop of "generation-storage-reuse-optimization." When subsequent vehicle system versions are updated (such as UI element ID changes), only the corresponding information in the knowledge base needs to be updated to achieve automatic adaptation of all related scripts, eliminating the need for manual script modification and significantly reducing maintenance costs. This provides stable, efficient, and iterative knowledge support for the entire automatic test code generation method.

[0021] Furthermore, the multi-dimensional test knowledge includes: test action description, corresponding method name, code snippet, UI element information, parameter rules, applicable scenarios, and semantic vector; the semantic vector is generated by the algorithm semantic model and is used for semantic similarity judgment.

[0022] In this embodiment, multi-dimensional test knowledge needs to be stored according to test modules (cockpit, chassis, ADAS, etc.). Each knowledge entry needs to contain the following 7 types of information and comply with the specific specifications in the automotive testing field: 1. Test Action Description Definition: A standardized description of test steps, prefixed by test type to distinguish step attributes, is the core basis for subsequent semantic retrieval and AI generation. It must be prefixed with "P_" (preconditions), "A_" (execution steps), or "E_" (expected results) to ensure clear identification of step types.

[0023] Example: P_ category (preconditions): "P_ vehicle is in P gear, ignition switch is on"; Class A (Execution Steps): "A_Press the volume + button on the steering wheel" "A_Voice command 'Turn on the air conditioning'"; E_ (Expected Result): "E_ Media volume increases by 2 levels, volume bar displayed on screen" "E_ Air conditioner vent temperature drops to 24℃".

[0024] 2. Corresponding method name Definition: A code method name that corresponds one-to-one with the test action description. It must follow programming language naming conventions to ensure direct invocation. Python naming conventions (lowercase letters + underscores) can be used. The method name should intuitively reflect the meaning of the action and avoid ambiguity.

[0025] Example: For "A_Press the steering wheel volume+ button": pressSteeringWheelVolumeUp(); For "P_Vehicle is in P gear": checkVehicleInPGear(); For "E_Increase media volume by 2 levels": verifyMediaVolumeIncrease().

[0026] 3. Code snippet Definition: Reusable code that implements the functionality of the corresponding method must conform to the UI operation standards for automotive testing, ensuring that it can run without modification or with only minor adjustments.

[0027] Strictly adhere to the "four-stage standard for UI operation"—initialize the adb device → update the UI automation tool → obtain UI elements → execute the operation, while also including error reporting and logging logic for the test framework (such as CVTest, SVW adaptation library).

[0028] Example (corresponding to the code snippet "A_press the steering wheel volume + button"): def pressSteeringWheelVolumeUp(): #1. Initialize the ADB device (connect to the vehicle's infotainment system) ad=svw.ivi().adb #2. Update the UI automation tool (ensure it recognizes the latest UI elements). ad.updateUiAutomator() #3. Retrieve UI elements (read the pre-stored element ID from the knowledge base) volume_up_btn=ad.getNodesById("steering_wheel_volume_up") if not volume_up_btn: cvtest.fail("Steering wheel volume+ button element not found, ID: steering_wheel_volume_up") #Framework error #4. Perform the operation (click) volume_up_btn[0].click() cvtest.logi("Executed: Pressed the steering wheel volume+ button") # Log record.

[0029] 4. UI element information Definition: UI control properties related to the test action are the core basis for the "get UI element" step in the code snippet and need to be associated with the specific application scenario.

[0030] The data can be stored in the format of "element ID|module|applicable scenario" to ensure that the test module and scenario can be quickly matched during retrieval.

[0031] Example: "steering_wheel_volume_up|steering wheel control module|cabin media volume adjustment scenario"; “screen_volume_bar|Cockpit display module|Media volume verification scenario”; "air_conditioner_temp_btn|cabin air conditioning module|air conditioning temperature adjustment scenario".

[0032] 5. Parameter Rules Definition: A specification of constraints on the parameters required by a method, including parameter types, required / optional attributes, default values, etc., to ensure that the parameters are valid when the method is called.

[0033] Required parameters (without default values) and optional parameters (including default values) must be clearly marked, and the parameter types must conform to Python data types (such as int, str).

[0034] Example: The method corresponding to "A_Press the steering wheel volume + button N times" is pressSteeringWheelVolumeUpNtimes(click_count=1): The parameter rule is "click_count (optional parameter, int type, default value 1, value range 1-5)"; The corresponding method for "A_Set Air Conditioner Temperature" is setAirConditionerTemp(temp=25): The parameter rule is "temp(optional parameter, int type, default value 25, value range 16-30)".

[0035] 6. Applicable Scenarios Definition: This indicates the test module and business scenario to which the test action applies, avoiding misuse across scenarios and improving the accuracy of knowledge reuse.

[0036] The scenario descriptions must be specific and unambiguous, taking into account the module division of vehicle testing (cabin, ADAS, chassis, etc.) and specific business functions (such as media control, air conditioning adjustment, automatic parking).

[0037] Example: "Cockpit-Media Control Scene" (corresponding to volume adjustment action); "Cockpit-Air Conditioning Control Scene" (corresponding temperature setting action); "ADAS-Automatic Parking Scenario" (corresponding to the "Activate Automatic Parking Function" action).

[0038] 7. Semantic Vectors Definition: The numerical vector converted from the "test action description" is used to quantify the semantic similarity between actions and is the core basis for the "internal RAG retrieval process" to achieve accurate retrieval.

[0039] Generated by the "algorithm semantic model" (a semantic matching algorithm based on English similarity), the vector dimension must be consistent (the document does not specify the dimension, but it must ensure that the vectors of different actions can be used to calculate similarity).

[0040] Example: For “A_Press the steering wheel volume+ button”, the semantic vector generated by the algorithm's semantic model is “[-0.12,0.34,0.21,-0.08,0.56,...]” (the vector length is consistent with the model dimension). For "A_Press the steering wheel volume up button", the generated semantic vector has a similarity of ≥0.85 with the above vector (document threshold), and can be judged as a "semantically similar action".

[0041] In this embodiment, the generation and function of semantic vectors are as follows: 1. Generation of semantic vectors In this embodiment, the semantic vector is generated by an algorithmic semantic model, which is a "semantic matching algorithm model based on English similarity"—first, the Chinese "test action description" is translated into standardized English (e.g., "A_press steering wheel volume up button" is translated into "A_press steering wheel volume up button"), and then the English description is converted into a fixed-dimensional numerical vector through an algorithm (e.g., Word2Vec, BERT) to ensure that the vector can reflect the semantic connotation of the action (rather than just literal matching).

[0042] 2. The core role of semantic vectors The core value of semantic vectors is to solve the problem of action retrieval that is "similar in meaning but different in literal sense," and it is specifically applied to two key processes: Process 1: Reranking of the internal RAG retrieval process In the "concurrent retrieval during the recall process" stage, the Rag Flow engine first filters out knowledge items related to the search terms. Then, based on the "semantic vector", the similarity between the items and the search terms (such as cosine similarity) is calculated. The items are then reordered in descending order of similarity to ensure that items with more similar meanings (such as "press the volume + button" and "press the volume up button") are ranked first, thereby improving retrieval accuracy.

[0043] Process 2: Strict matching judgment generated concurrently within the script When determining "reusable keywords", the semantic vector similarity between the action to be reused and the current step is compared. If the similarity is greater than or equal to the preset threshold (0.85), it is determined to be "reusable", thus avoiding the omission of effective knowledge due to literal differences (such as "press down" and "press").

[0044] In this embodiment, multi-dimensional test knowledge is fully stored by storing 7 types of information plus semantic vectors, providing full-process data support for subsequent "three-stage pipeline concurrent processing", "enhanced AI generation process" and "intelligent unified verification" - which not only solves the problem of traditional knowledge dispersion, but also realizes "semantic-level reuse" through semantic vectors, and is the "data foundation" of the entire test code automatic generation method.

[0045] S200 extracts test case information from the test data source to build a standardized issue dictionary containing test case identifiers, test levels, step types, and associated scenarios.

[0046] In this embodiment, test cases are read from Excel spreadsheets or test management tools such as Jira, and basic information (such as test case ID "Cockpit_Media_001", test level P0, execution time limit 10s), step information (P_preconditions, A_execution steps, E_expected results), and context information (such as the "Cockpit-Media Control" module) are extracted and organized into a standardized question_dict. The example dictionary contains test case identifiers, test levels, step types, original text, and associated scenarios, clearly defining the core information and application scenarios of each step.

[0047] Furthermore, the test data source is an Excel spreadsheet or a test management tool, and the extracted test case information includes basic information, step information, and context information. The basic information includes the test case ID and the upper limit of execution time, and the step information includes the preconditions, execution steps, and expected results.

[0048] 1. Test the reading of the data source Excel Spreading: For common test case Excel templates (with fixed column structure), this code uses Python's pandas library to read the file and extract data by column index. For example, if the Excel columns include "Test Case ID," "Test Level," "Preconditions," "Execution Steps," "Expected Result," "Maximum Execution Time," and "Module," the code loads the data using `df=pd.read_excel("testcase.xlsx")` and then extracts all test case identifiers using `df["test case ID"].values`.

[0049] Test management tool reading: For tools like Jira, data is retrieved via their open APIs (such as Jira's REST API). For example, calling the GET / rest / api / 2 / issue / {issueId} interface extracts the test case fields defined in the attachments from the returned JSON data, such as fields.customfield_10001 (corresponding to "Test Case ID"), fields.customfield_10002 (corresponding to "Execution Steps"), etc., ensuring consistency with the fields extracted from the Excel spreadsheet.

[0050] 2. Extracted test case information and its structured processing In this embodiment, three types of information can be extracted and structured to ensure the consistency of subsequent "problem dictionary construction": Basic Information: Includes two core components Test Case ID: Uniquely identifies a test case. The format must reflect the module and function, such as the example in the attachment "Cockpit_Media_001" ("Cockpit" represents the cockpit module, "Media" represents the media function, and "001" is the serial number). Maximum execution time: The maximum allowed execution time for a test case, in seconds, such as "10s" (used for subsequent script execution timeout checks).

[0051] Example: {"case_id":"Cockpit_Media_001","max_duration":10}.

[0052] Step information: Extracted according to the "P_ / A_ / E_" classification criteria, corresponding to the three core steps of the test cases: Preconditions (P_): The state that must be met before the test can be executed. They are prefixed with "P_", such as the example in the attachment: "P_ The vehicle is in P gear and the ignition switch is on". Execution steps (A_): Specific operation actions, prefixed with "A_", such as "A_ press the steering wheel volume + button 2 times"; Expected Result (E_): The expected state after the operation, prefixed with "E_", such as "E_ media volume increased by 2 levels, volume bar displayed on screen".

[0053] Example: {"steps":[{"step_type":"P","original_text":"P_Vehicle is in P gear..."},{"step_type":"A","original_text":"A_Press the steering wheel volume + button twice"},{"step_type":"E","original_text":"E_Media volume increases by 2 levels..."}]}.

[0054] Contextual Information: Supplementary information to illustrate the test scenario, including "Module", "Associated UI Elements", and "Business Scenario", such as "Cockpit - Media Control Module", "Associated UI Elements: steering_wheel_volume_up, screen_volume_bar", and "Business Scenario: User adjusts media volume while driving". Example: {"context":"Module: Cockpit - Media Control; Associated UI Elements: steering_wheel_volume_up, screen_volume_bar; Business Scenario: User adjusts media volume while driving"}.

[0055] 3. Integration after information extraction After extracting the above information, it is integrated into a unified data structure according to the "standardized problem dictionary" format, as shown in the example below: question_dict={ "case_id":"Cockpit_Media_001", "max_duration":10, "steps":[ {"step_type":"P","original_text":"P_Vehicle is in P gear, ignition switch is on","context":"Initialize vehicle status"}, {"step_type":"A","original_text":"A_Press the steering wheel volume+ button twice","context":"Adjust media volume, associated UI element: steering_wheel_volume_up"}, {"step_type":"E","original_text":"E_Media volume increased by 2 levels, screen volume bar displayed","context":"Validate adjustment result, associate UI element: screen_volume_bar"} ], "module":"Cockpit-Media Control", "business_scene": "User adjusts media volume while driving" }

[0056] In this embodiment, by clearly defining the test data source type and the structured standards for information extraction, the pain points of traditional test data—namely, "disorganized format, incomplete information, and difficulty in automated processing"—are effectively addressed. On the one hand, it supports Excel spreadsheets and test management tools as data sources, eliminating the need to modify existing test data storage systems. This perfectly adapts to the existing workflows of test teams, reducing the threshold and learning cost of method implementation and avoiding application obstacles caused by data source compatibility issues. On the other hand, extraction is categorized into "basic information + step information + context information," ensuring coverage of all key data required for test code generation. The test case ID guarantees the uniqueness and traceability of the script, the execution time limit provides a constraint standard for script execution, and the step information categorized as P_ / A_ / E_ aligns with specific specifications in the automotive testing field, providing accurate and standardized input for subsequent stages such as voice intent recognition, issue expansion, and RAG retrieval, avoiding processing errors caused by inconsistent data formats. Simultaneously, context information helps improve the accuracy of semantic retrieval and scenario adaptation, making the subsequently generated test code more closely aligned with actual business scenarios. Overall, this improves the smoothness and accuracy of the automated test code generation process, laying a solid data foundation for the efficient generation of compliant test code.

[0057] S300, new test keyword codes are generated by sequentially performing script-based concurrent preprocessing, recall process concurrent retrieval, and script-based concurrent generation on the standardized question dictionary.

[0058] Concurrent preprocessing by script: For each step, voice intent recognition (distinguishing between "voice operation / other", such as determining "pressing the volume button" as a non-voice operation) and problem rewriting and expansion (generating multi-dimensional search terms such as "pressing the steering wheel volume + button media volume adjustment UI element click operation") are performed simultaneously, and the processing results are cached.

[0059] Concurrent retrieval during the recall process: Based on the expanded search terms, both the regular knowledge base and the UI knowledge base are searched simultaneously. The results are then aggregated through the internal RAG retrieval process, and reusable knowledge is selected.

[0060] Concurrent generation within the script: Check the search results. If there are reusable keywords with a similarity of ≥0.85 and the UI elements are adapted (such as steering_wheel_volume_up adapted to media control scenarios), then reuse them directly; otherwise, trigger the enhanced AI generation process.

[0061] Furthermore, the concurrent preprocessing by script includes: concurrently performing voice intent recognition and question rewriting and expansion for each step; the voice intent recognition distinguishes whether a step is a voice operation, and the question rewriting and expansion generates multi-dimensional search terms containing main search terms, scene terms, and technical terms.

[0062] In this embodiment, concurrent preprocessing by script is the first core step of the three-stage pipeline. It improves efficiency through parallel processing and provides accurate input for subsequent retrieval. The specific implementation strictly follows the pipeline processing mode and LLM calling specification in the appendix: 1. Perform speech intent recognition and question rewriting / expansion concurrently for each step. A multi-threaded concurrent architecture (such as Python's threading library) is adopted to simultaneously start two processing threads for each step (such as P_, A_, E_) in the standardized problem dictionary, avoiding the time-consuming serial waiting, as follows: (1) Speech Intent Recognition (LLM Call 1: Intent Recognition) The purpose of this step is to distinguish whether a step is a voice operation, providing a basis for subsequent code generation (such as voice command calls to dedicated APIs).

[0063] You can call up the Large Model (LLM) and input the "Intention Recognition Prompt" defined in the attachment, in the format: "Please determine whether the following test steps are voice operations, and output the following format: [{"step":"Step Text","intention":"Voice Input / Voice Output / Other","origin_step":"Original Step"}] .

[0064] Example: Input the step "A_voice command 'Turn on the air conditioner'", LLM output: [{"step":"A_voice command 'Turn on the air conditioner'","intention":"voice input","origin_step":"A_voice command 'Turn on the air conditioner'"}]; Input the step "A_Press the steering wheel volume+ button", LLM output: [{"step":"A_Press the steering wheel volume+ button","intention":"Other (non-voice operation)","origin_step":"A_Press the steering wheel volume+ button"}).

[0065] (2) Problem rewriting and expansion (LLM call 2: problem expansion) The purpose of this step is to convert the original text into multi-dimensional search terms, enrich the search dimensions, and improve the accuracy of subsequent recall.

[0066] You can call a large model (LLM), input a predefined "prompt for expanding the question", and request the generation of search terms containing three types of words: Main search term: core actions of the steps (e.g., "press the volume + button on the steering wheel"); Scenario keywords: the test module or business scenario to which it belongs (e.g., "cockpit media control"); Technical terms: Operation type (e.g., "UI element click" or "physical button operation").

[0067] Example: Input the step "A_Press the steering wheel volume + button twice", and combine it with the context information ("Cockpit - Media Control Module") to output multi-dimensional search terms: "Press the steering wheel volume + button, cockpit media control scenario, UI element click operation, physical button press, volume adjustment". At the same time, generate alternative search terms (such as "steering wheel volume button press, media volume adjustment, hardware operation") to avoid missing detections due to a single search term.

[0068] In this embodiment, through concurrent processing and multi-dimensional search optimization, the pain points of low efficiency and missed detections caused by single search terms in traditional preprocessing are specifically addressed: On the one hand, voice intent recognition and question rewriting and expansion are performed concurrently for each step, reducing the preprocessing time of a single script by more than 50% (from the traditional serial 30 minutes / script to within 15 minutes), significantly improving the overall efficiency of the pipeline; on the other hand, the multi-dimensional search terms (main search term + scene term + technical term) generated by question rewriting and expansion break through the limitations of traditional single keyword retrieval, expanding the retrieval dimension from "action literal" to "scene + technical type". Combined with concurrent retrieval of dual knowledge bases, it ensures coverage of methods and UI element information associated with test actions, avoiding missed detections of reusable knowledge due to missing information, providing a high-quality candidate set for the subsequent RAG retrieval process, and improving semantic matching accuracy to ≥0.85; at the same time, the classification results of voice intent recognition provide a basis for subsequent code generation (such as voice operation calls). The Command() interface (and the click() interface for non-voice operations) provides accurate data, reducing the randomness of AI generation, further lowering the code error rate, and laying a key foundation for the efficiency and high accuracy of automatic test code generation.

[0069] Furthermore, the concurrent retrieval process of the recall process is based on the multi-dimensional search terms and simultaneously retrieves the conventional test knowledge base and the UI knowledge base. The concurrent retrieval process of the recall process is implemented through an internal RAG retrieval process. The internal RAG retrieval process includes Rag Flow retrieval, Rerank re-ranking, Top-K result filtering and strict matching model judgment in sequence, and filters out reusable knowledge with semantic similarity greater than or equal to a preset threshold.

[0070] In this embodiment, the concurrent retrieval process for the recall process is based on multi-dimensional search terms and simultaneous retrieval of two knowledge bases. After the speech intent recognition and question rewriting and expansion are completed, based on the generated multi-dimensional search terms, a dual-thread concurrent retrieval of the two core knowledge bases defined in the attachment is initiated: Standard test knowledge base: Stores "action-method" related knowledge such as test action descriptions, corresponding method names, and code snippets (e.g., the mapping between "A_press volume+" and press Volume Up()). UI Knowledge Base: Stores information such as UI element ID, module, and applicable scenarios (e.g., "steering_wheel_volume_up|steering wheel module|volume adjustment").

[0071] By initiating search requests simultaneously through multiple threads (such as using concurrent.futures.ThreadPoolExecutor), the search results from the two knowledge bases are returned independently and then aggregated as input for the subsequent "internal RAG search process," thus avoiding the accumulation of time caused by serial searches.

[0072] The concurrent retrieval process in the recall stage achieves accurate knowledge retrieval through an internal retrieval-enhanced generation (RAG) retrieval workflow. It is the core link between the preprocessing and generation stages, as detailed below: 1. Rag Flow search (initial recall) Based on multi-dimensional search terms generated by "concurrent preprocessing by script" (such as "pressing the steering wheel volume + button, cockpit media control, UI, element click"), the Rag Flow engine is invoked to perform a preliminary search on the structured test knowledge base (including the regular test knowledge base and the UI knowledge base).

[0073] Implementation: The Rag Flow engine uses keyword matching and basic semantic analysis to filter out knowledge items related to the search terms from the knowledge base, without limiting the number, to ensure coverage of all potentially relevant content.

[0074] Example: For the search terms "press the steering wheel volume + button, cockpit media control", Rag Flow returned 50 relevant entries, including knowledge entries corresponding to action descriptions such as "A_press the steering wheel volume + button", "A_press the steering wheel volume up button", and "A_click the steering wheel volume + button", as well as UI element information such as "steering_wheel_volume_up" and "steering_volume_plus".

[0075] 2. Rerank (exact sorting) For the entries returned by Rag Flow retrieval, semantic similarity is calculated based on a preset "algorithm semantic model", and then the entries are reordered in descending order of similarity.

[0076] Implementation: The algorithmic semantic model (such as the BERT-based fine-tuning model) converts the search terms and the "test action descriptions" of knowledge entries into semantic vectors, calculates the vector similarity using the cosine similarity formula (range 0-1, the higher the value, the closer the semantics), and sorts them from high to low similarity.

[0077] Example: After calculating the similarity of the above 50 items, "A_Press the steering wheel volume + button" (similarity 0.98), "A_Press the steering wheel volume increase button" (similarity 0.92), and "A_Click the steering wheel volume + button" (similarity 0.88) are ranked at the top, while the item related to "air conditioning adjustment" (similarity 0.12) is ranked at the bottom.

[0078] 3. Top-K Result Filtering (Focusing on Highly Relevant Items) Select the top K items (default K=5) from the sorted entries as candidate results to reduce the amount of data for subsequent processing and focus on highly relevant knowledge.

[0079] Implementation: Take the top 5 items in the order after Reranking to form a candidate set, ensuring that both highly similar items are retained and data overload is avoided.

[0080] Example: Select the top 5 items in the above sorting, with a similarity of ≥0.85, and include complete information such as action description, corresponding method name (e.g., pressSteeringWheelVolumeUp()), and UI element ID (e.g., "steering_wheel_volume_up").

[0081] 4. Model Selection (Final Selection) The preset "filtering model" (based on LLM) is invoked to perform semantic consistency judgment on Top-K candidate items and filter out reusable knowledge with semantic similarity ≥ preset threshold (default 0.85).

[0082] Implementation: Input a preset "historical keyword matching prompt", in the format: "Determine whether the following two test actions are semantically completely matched: Action 1: {core action of search term}; Action 2: {action description of candidate entry}. Output similarity (0-1) and matching conclusion (yes / no)".

[0083] Example: For the core action of the search term "A_press the steering wheel volume + button" and the candidate action "A_press the steering wheel volume up button", the LLM outputs "Similarity 0.92, Matching conclusion: Yes", which is considered reusable knowledge; for the candidate "A_click the central control volume + button" (Similarity 0.78), the output is "Matching conclusion: No", which excludes the reusable set.

[0084] Finally, through the above four-step process, a retrieval report containing reusable knowledge is output (such as {"reusable_keywords":[{"method_name":"pressSteeringWheelVolumeUp()","similarity":0.92,"ui_element_id":"steering_wheel_volume_up"}]}), providing a basis for subsequent "concurrent generation within the script".

[0085] The associated information and adaptation optimization results generated during the reuse of reusable knowledge will be updated to the structured test knowledge base. At the same time, if adaptation extensions are made based on reusable knowledge (such as parameter adjustment or scenario adaptation), the extended knowledge will be added as new entries to supplement and update the knowledge.

[0086] In this embodiment, the progressive process of "Rag Flow retrieval → Reranking → Top-K filtering → strict matching judgment" solves the pain points of traditional retrieval, which "relies only on literal matching, has a rough similarity judgment, and has a high rate of missed / false detections": Rag Flow retrieval ensures the comprehensiveness of the recall scope and avoids the omission of relevant knowledge; Reranking is based on semantic vector quantification of similarity, making the ranking results more in line with semantic connotations, and solving the problem that actions that are "different in literal sense but similar in meaning" (such as "press down" and "press") are ranked lower; Top-K filtering focuses on highly relevant items and reduces the cost of processing invalid data; the strict matching model uses LLM deep semantic judgment and a preset threshold (0.85) to accurately filter reusable knowledge, improving the retrieval accuracy to ≥99%. The overall process ensures the comprehensiveness of knowledge retrieval and improves accuracy through multiple rounds of optimization, significantly reducing the frequency of subsequent AI-generated new keywords (similar action reuse rate increased to ≥80%), reducing computational resource consumption, and providing a high-quality, reusable knowledge base for test code generation, ensuring the accuracy and efficiency of generated code.

[0087] Furthermore, during concurrent generation within the script, if the search report determines that there are no reusable keywords or that the UI elements containing reusable keywords are not suitable for the current scenario, new test keyword code is generated.

[0088] In this embodiment, concurrent generation within the script is the final generation stage of the three-stage pipeline. The logic of "reuse priority, generation fallback" ensures efficient output of test keyword code. The generation of new test keyword code is achieved through an enhanced AI generation process, which provides high-precision generation capabilities for scenarios without reusable knowledge. 1. Triggering judgment for concurrent generation within the script Based on the retrieval report output by the "Concurrent Retrieval in the Recall Process", two judgments are executed concurrently for each test step (multi-threaded parallel processing): Reusable keyword existence determination: Check if there are reusable keywords in the search report with a semantic similarity ≥ a preset threshold (default 0.85). For example, if the similarity between "pressSteeringWheelVolumeUp()" and the current step "A_press the steering wheel volume+ button" in the search report is 0.92 (≥0.85), then it is determined that "reusable keywords exist".

[0089] UI element compatibility assessment: If reusable keywords exist, further verify whether their associated UI elements are suitable for the current scenario. For example, if the UI element ID associated with the keyword is "steering_wheel_volume_up_v1", but the current test scenario is "2024 vehicle infotainment system" (the UI element has been updated to "steering_wheel_volume_up_v2"), then it is determined that "the UI element is not compatible".

[0090] When both judgment results are "no reusable keywords exist" or "exists but UI elements are not suitable", the enhanced AI generation process is triggered.

[0091] 2. Enhanced AI Generation Process (Five Core Steps) (1) Break down the test steps into sub-steps and perform multi-database searches. Sub-step decomposition: The Large Model (LLM) is invoked, and the complex steps are decomposed into atomic sub-steps based on the "step decomposition prompt" to ensure that each sub-step corresponds to a single operation.

[0092] Example: Break down "A_Press the steering wheel volume + button twice" into 3 sub-steps: ①“P_Confirm the vehicle is in P gear and the ignition switch is on (preliminary check)”; ②“A_Location of the UI element for the steering wheel volume+ button”; ③ "A_Execute the press operation, press twice consecutively."

[0093] Multi-base retrieval: For each sub-step, the three knowledge bases defined in the attachment (regular test knowledge base + UI knowledge base + code snippet library) are searched simultaneously to obtain the basic methods, UI element information, and code templates corresponding to the sub-step. For example, sub-step ③ retrieves the "single press" template from the code snippet library: def pressButton(button_id, click_count=1):...

[0094] (2) Filter the best matching results of the sub-steps The LLM is invoked to select the optimal match for each sub-step from the multi-database search results based on the "best match filtering rules" (prioritizing results with semantic similarity ≥ 0.9 and process consistency ≥ 0.8).

[0095] Example: In the search results of sub-step ②, "steering_wheel_volume_up_v2 in UI knowledge base (similarity 0.95)" is better than "old version element ID (similarity 0.7)" and is selected as the best match.

[0096] (3) Extend the basic method parameters Based on the specific requirements of the sub-steps (such as the number of operations and the target value), the parameters of the selected basic methods are expanded, following the "parameter rules" (clearly defining required / optional parameters, default values, and value ranges).

[0097] Example: For sub-step ③ "press twice consecutively", the basic method pressButton(button_id,click_count=1) is expanded to pressButton(button_id,click_count=2), and the parameter rule is marked as "click_count: optional parameter, int type, default 1, value 1-5".

[0098] (4) Generate keyword definitions Integrate sub-step information, expanded parameters, and applicable scenarios to generate standardized keyword definitions (keyword definition format), including: Method name (e.g., pressSteeringWheelVolumeUpTwice()); Function description ("Press the volume+ button on the steering wheel a specified number of times to adjust the media volume"); Parameter description ("button_id: ID of the steering wheel volume + button UI element; click_count: number of times it is pressed"); Applicable scenarios ("Cockpit media control scenario, 2024 vehicle infotainment system").

[0099] (5) Generate new test keyword code according to UI operation specifications Initialize the adb device (ad=svw.ivi().adb); Update the UI automation tool (ad.updateUiAutomator()); Get UI elements (based on the best-matching element ID); The operation after executing the extended parameters (pressing click_count=2 to execute the press).

[0100] Example code: def pressSteeringWheelVolumeUpTwice(button_id="steering_wheel_volume_up_v2",click_count=2): #1. Initialize ADB devices ad=svw.ivi().adb #2. Update UI automation tools ad.updateUiAutomator() #3. Get UI Elements volume_btn = ad.getNodesById(button_id) if not volume_btn: cvtest.fail(f"UI element not found: {button_id}") #Framework error #4. Perform the operation (press the extended parameters twice). for_in range(click_count): volume_btn[0].click() time.sleep(0.5) # Anti-shake cvtest.logi(f"{click_count} times have been pressed consecutively: {button_id}") # Log recording In this embodiment, the pain points of traditional generation methods—low reusability, poor adaptability to new code, and insufficient generation accuracy—are addressed through a flexible logic of "reuse judgment-generation trigger" and an enhanced AI generation process. Concurrent generation within the script prioritizes the reuse of highly similar keywords, increasing the knowledge reuse rate in the same scenario to ≥80% and reducing redundant development. UI element adaptability judgment avoids the misuse of old version elements in new scenarios, reducing code execution failure rates. The enhanced AI generation process achieves atomic processing of complex operations through sub-step decomposition, combined with multi-database retrieval to ensure reliable knowledge support for each sub-step. Parameter expansion makes the code more tailored to specific needs, and the final code generated according to UI operation specifications conforms to testing framework standards (such as SVW API adaptation), with an error rate of <0.1%. Simultaneously, the concurrent processing mode shortens the single-step generation time to within 30 seconds, enabling rapid generation of adapted test keyword code even in new scenarios without reusable knowledge (such as the 2024 vehicle infotainment system), significantly reducing manual coding costs and meeting the core needs of rapid iteration in automotive testing scenarios.

[0101] S400, perform intelligent unified verification on the new test keyword code, and if the verification passes, obtain the keyword code that conforms to the target test specification.

[0102] In this embodiment, the CVTest→SVW API mapping can be applied (e.g., changing cvtest.click() to svw.ivi().adb.clickByNodeId()) to correct syntax errors such as indentation and mismatched parentheses, clean up unused import statements (e.g., uncalled import time) and variables, and ensure that the code conforms to automotive testing specifications.

[0103] Furthermore, the intelligent unified verification includes: Convert the generic test framework API in the new test keyword code to the test framework API adapted to the target vehicle model, and verify the consistency between the converted API and the test specifications of the target vehicle model.

[0104] In this embodiment, the core is to convert the API of the general testing framework (CVTest) into a testing framework API (such as SVW) adapted to the target vehicle model, so as to ensure that the code is compatible with the testing equipment.

[0105] Implementation: A large model (LLM) is invoked, inputting a pre-defined "API mapping prompt." This prompt contains "CVTest→SVW API mapping rules" stored in a built-in knowledge base (e.g., cvtest.click() corresponds to svw.ivi().adb.clickByNodeId(), cvtest.fail() corresponds to svw.ivi().adb.reportFail()). The LLM iterates through the generated keyword code, identifies common APIs, and replaces them with the target vehicle model's compatible API.

[0106] Example: The original generic API statement `cvtest.click(volume_up_btn)` in the code has been corrected after mapping to `svw.ivi().adb.clickByNodeId(volume_up_btn)`; the error message statement `cvtest.fail("volume key element not found")` has been corrected to `svw.ivi().adb.reportFail("volume key element not found, ID: steering_wheel_volume_up")`, which perfectly matches the requirements of the target vehicle model testing framework.

[0107] Check whether the converted API meets the "preset conditions" of the target vehicle test specification (these conditions are predefined, such as: the API method name must be in the "list of available methods" of the target vehicle test framework; the number and type of API parameters must match (e.g., clickByNodeId must pass the nodeId parameter and cannot be omitted); and the API call scenario must match (e.g., svw.ivi().adb is only used for cockpit UI operations and cannot be used for ADAS modules).

[0108] If the converted API meets the preset conditions for consistency with the target vehicle model's testing specifications, perform the following operations on the new test keyword code: If the converted API meets all preset conditions (such as correct method name, parameters, and scenario), proceed to the next verification step; if the converted API does not meet any preset conditions (such as using ADAS API to call cockpit elements), directly determine "verification failed" (subsequent steps will not be executed).

[0109] Perform syntax checks on the new test keyword code and correct Python syntax errors, including indentation errors, mismatched parentheses, and undefined variable references.

[0110] In this embodiment, syntax errors in Python code are automatically corrected, focusing on critical errors that affect code execution, while spelling errors are not addressed.

[0111] Implementation: LLM combines Python syntax rules with a "syntax correction prompt" to scan for issues such as improper indentation, mismatched parentheses, and grammatical structure errors in the code. For indentation errors, it is uniformly corrected according to Python standards (4 spaces); for unclosed parentheses or quotation marks, the corresponding symbols are automatically added; for grammatical logic errors (such as missing loop conditions or incomplete function definitions), the necessary structure is completed based on the code context.

[0112] Example: The generated code has an "indentation disorder" problem: def pressSteeringWheelVolumeUpTwice(): ad=svw.ivi().adb# Missing indentation ad.updateUiAutomator() volume_btn = ad.getNodesById("steering_wheel_volume_up") # Inconsistent indentation Revised version: def pressSteeringWheelVolumeUpTwice(): ad=svw.ivi().adb#Unify 4-space indentation ad.updateUiAutomator() volume_btn = ad.getNodesById("steering_wheel_volume_up") # Consistent indentation Remove unused import statements and unused variables from the new test keyword code.

[0113] Clean up unused import statements: Remove imported modules defined in the code but not called to reduce script redundancy and improve running efficiency.

[0114] Implementation: The LLM first scans the import statements in the code (such as `import time`, `from svw_common_utils import`), then iterates through the main code to determine whether the imported module is actually called. If no call record is found (e.g., `time.sleep()` or related functions are not used after importing `time`), the import statement is automatically deleted.

[0115] Example: If the generated code imports `import time` but the related function is not used, delete the statement after cleanup; if `from svw_common_utils import checkVehicleInPGear` and `checkVehicleInPGear()` is called in the code, keep the import statement, and the final code will only retain the necessary dependencies.

[0116] Clean up unused variables: Delete variables defined in the code but not referenced to avoid memory consumption and reduced code readability.

[0117] Implementation: The LLM analyzes the variable definitions and references in the code line by line according to the "variable cleanup prompt". For variables that are only defined but not used (such as temp_var=1, unused_element=ad.getNodesById("old_btn")), the variable definition statements are directly deleted; for variables that are defined but only assigned values ​​and not referenced, the same cleanup is performed to ensure code conciseness.

[0118] Example: If the code contains temp_check=checkVehicleInPGear() (the temp_check variable is not used after definition), delete this statement after cleaning; for volume_btn=ad.getNodesById("steering_wheel_volume_up") and volume_btn[0].click() is called subsequently, the variable definition is retained.

[0119] If the above steps are completed, the new test keyword code verification is confirmed to be successful; if the above steps are not completed, the new test keyword code verification is confirmed to be unsuccessful.

[0120] For validation to pass, the following conditions must be met simultaneously: Step 1: API consistency validation passes; Step 2: Syntax detection and correction are completed (no syntax errors that cannot be automatically corrected); Step 3: Redundant content cleanup is completed (all redundant imports / variables have been deleted).

[0121] Cases where validation fails: Case 1: API consistency validation fails in step 1; Case 2: Step 1 passes, but step 2 encounters syntax errors that cannot be automatically corrected ("The above operation is not completed"); Case 3: Steps 1 and 2 pass, but step 3 fails to complete redundancy cleanup due to abnormal code logic (such as import statements nested in conditional statements that cannot be recognized) ("The above operation is not completed").

[0122] If the consistency between the converted API and the target vehicle model's testing specifications does not meet the preset conditions, the new test keyword code verification is determined to fail.

[0123] Through the above steps, we first ensure that the code is compatible with the API of the target vehicle model, then ensure that the code syntax is correct, and finally make the code concise and without redundancy. Only when all the steps are completed and meet the requirements can the final verification be considered successful. Any step that gets stuck will directly or indirectly be judged as failing, ensuring that the generated code is both compatible with the vehicle model and standardized and executable.

[0124] In this embodiment, intelligent unified verification is the core step in ensuring the usability, compatibility, and simplicity of test keyword code. Code optimization is achieved through four standardized operations, specifically implemented as follows: In this embodiment, a standardized and automated intelligent unified verification process is used to specifically address the pain points of traditional manual verification, namely "low efficiency, error-proneness, and poor compatibility." The application of test framework API mapping achieves seamless adaptation between general code and the target vehicle model test framework, avoiding omissions and errors caused by manually modifying APIs one by one, thus improving code adaptation efficiency by 80%. Syntax error correction ensures that the code can be run directly, reducing test interruptions caused by basic errors such as indentation and parentheses. Combined with API mapping rules, the code error rate is reduced to <0.1%. The elimination of imports and variable cleanup significantly reduces the amount of redundant script code (an average reduction of 30%), improving code readability and running efficiency, and lowering subsequent maintenance costs. The entire verification process requires no manual intervention, shortening the single-keyword code verification time from the traditional 10-15 minutes to within 1 minute. Furthermore, the verification standards strictly adhere to the rules defined in the automotive testing field specifications and appendices, ensuring that the generated test code has high compatibility, high availability, and high simplicity, laying a solid foundation for subsequent script assembly and execution.

[0125] S500: Invoke the preset test case template, fill in the problem dictionary information and keyword codes that conform to the target test specifications to generate complete test code, and update the newly generated keywords to the structured test knowledge base.

[0126] Call the preset template for functional or performance testing, fill in the question_dict information and keyword code that conforms to the target test specifications, and generate a complete script such as test_Cockpit_Media_001(); at the same time, mark the newly generated keywords (including method names, code snippets, and UI element information) as "AI generated - pending verification" and update them to the structured test knowledge base.

[0127] Furthermore, when updating the newly generated keywords to the structured test knowledge base, the source of keyword generation and initial reuse priority are marked; the preset test case templates are classified according to test type and include placeholders for test case identifiers, test levels, step execution code, and result verification code.

[0128] In this embodiment, the new keyword entry rules and preset template design ensure that test knowledge is reusable and script format is consistent.

[0129] 1. Newly generated keywords are updated to the tagging rules of the structured test knowledge base. After the new test keywords pass the intelligent unified verification, they are updated to the structured test knowledge base according to the "knowledge entry process". The core operation is to add two key attributes: Generate source tags: Add a "source" field to knowledge base entries, which is divided into two categories: "AI Generated - Pending Verification": New keywords generated by the enhanced AI generation process (not verified by actual execution), such as the first generated pressSteeringWheelVolumeUpTwice(), need to be marked with this source to distinguish them from mature keywords written manually. "Manually Supplemented - Verified": If the keyword is executed more than 3 times without errors (attachment feedback mechanism), or confirmed by the test engineer, it will be updated to this label to improve its reusability.

[0130] Initial reuse priority setting: Based on the general applicability of keywords and the quality of generated code, set the initial priority in the priority field: Keywords used in common scenarios (such as "cockpit media control") and whose code fully conforms to UI operation specifications are initially set to "medium" priority; Keywords with special scenarios (such as "low temperature start test for specific vehicle models") or complex parameters (such as having more than 5 optional parameters) should be initially set to "low" priority. If the execution is successful three times in a row, the priority will be automatically increased according to the rules in the appendix (e.g., "low → medium"). If it fails, the priority will be reduced to ensure that highly reliable knowledge is reused first.

[0131] Example of data entry (complete multi-dimensional knowledge entry): { "action_desc":"A_Press the volume + button on the steering wheel twice consecutively", "method_name":"pressSteeringWheelVolumeUpTwice()", "code_snippet":"defpressSteeringWheelVolumeUpTwice(button_id=...,click_count=2):\n ad=svw.ivi().adb\n...", "ui_element_info": "steering_wheel_volume_up_v2|Steering wheel module|2024 cockpit scenario", "param_rules": "click_count: int, default 2, range 1 - 5", "scene": "Cockpit - Media volume adjustment (2024 car radio)", "semantic_vector": [-0.12, 0.34,...], / / Generated by algorithm semantic model "source": "AI generated - To be verified", / / Generation source marker "priority": "Medium" / / Initial reuse priority } 2. Classification and placeholder design of preset test case templates Preset test case templates are classified according to test types (functional testing, performance testing, compatibility testing, etc.). Each template contains fixed placeholders to ensure the unified structure and direct runnability of the generated test code: Template classification criteria: Functional testing template: Used to verify the correctness of core functions (such as "volume adjustment function") and contains basic process placeholders; Performance testing template: Adds the {execution_time_check} placeholder for inserting code to judge the upper limit of execution duration (such as if execution_time > {max_duration}: cvtest.fail("Timeout")); Compatibility testing template: Adds the {version_adaptation_code} placeholder for inserting multi - version UI element adaptation logic (such as switching UI element IDs for different car radio systems).

[0132] Core placeholder design, sample code is as follows: # Test case ID: {case_id} / / Basic information placeholder # Test level: {case_level} / / Such as P0 / P1 import cvtest import svw.ivi from generated_keywords import {keyword_list} / / Generated keyword reference placeholder def test_{case_id}(): # Pre - condition execution {precondition_code} / / Code corresponding to step P: checkVehicleInPGear() #Execution Steps {execution_code} / / Code corresponding to step A: pressSteeringWheelVolumeUpTwice(click_count=2) #Result Validation {verification_code} / / Code corresponding to step E: verifyMediaVolumeIncrease(expected_level=2) cvtest.pass("Test passed") Template population logic: Extract case_id "Cockpit_Media_001" and case_level "P0" from the standardized issue dictionary, extract precondition_code "checkVehicleInPGear()" from the validated keyword code, automatically replace placeholders, and generate a complete script that can be directly imported into Auto Studio to run.

[0133] In this embodiment, structured knowledge updates and templated script generation address the core pain points of traditional test development: "disordered knowledge accumulation, chaotic script format, and low reusability." New keywords are marked with their generation source and initial priority, improving knowledge base traceability by 90%. Combined with a dynamic priority adjustment mechanism, high-reliability knowledge is prioritized for reuse, increasing keyword reuse rate in the same scenario from the traditional 30% to ≥80%, reducing redundant development. Pre-defined templates categorized by test type unify script structure, avoiding format differences caused by manual writing, improving test code readability by 60%. Placeholder design enables efficient "data-code" binding, reducing complete script assembly time from 30 minutes / script to within 5 minutes. Automated knowledge updates and template filling form a closed loop of "generation-verification-database entry-reuse." When the vehicle system iterates, only UI element information and template adaptation logic in the knowledge base need to be updated to quickly generate test code adapted to the new system, reducing maintenance costs by 70%. This provides standardized and scalable technical support for efficient iteration of automotive testing.

[0134] The method in the above embodiments is executed as follows: Figure 2As shown in the figures; furthermore, although the steps of the method in this disclosure are described in a specific order in the figures, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps, etc.

[0135] In one exemplary embodiment, a test code automatic generation apparatus is also provided, the apparatus comprising: An initialization module is used to initialize a structured test knowledge base; the structured test knowledge base stores multi-dimensional test knowledge, which supports semantic retrieval and dynamic updates.

[0136] The test case information extraction module is used to extract test case information from the test data source, so as to build a standardized problem dictionary containing test case identifiers, test levels, step types and associated scenarios.

[0137] The question dictionary processing module is used to generate new test keyword codes by sequentially performing script-based concurrent preprocessing, concurrent retrieval during the recall process, and concurrent generation within the script on the standardized question dictionary.

[0138] The verification module is used to perform intelligent and unified verification on the new test keyword code. If the verification passes, the keyword code that conforms to the target test specification is obtained.

[0139] The calling module is used to call a preset test case template, fill in the problem dictionary information and the verified keyword code to generate complete test code, and update the newly generated keywords to the structured test knowledge base.

[0140] Furthermore, the problem dictionary processing module includes: The voice intent recognition and question rewriting unit is used to concurrently perform voice intent recognition and question rewriting for each step; the voice intent recognition distinguishes whether a step is a voice operation, and the question rewriting generates multi-dimensional search terms containing main search terms, scene terms, and technical terms.

[0141] Furthermore, the problem dictionary processing module also includes: The enhanced AI generation unit is used to generate new test keyword code when the script is generated concurrently, in cases where the search report determines that there are no reusable keywords or that the UI elements containing reusable keywords are not suitable for the current scenario.

[0142] Furthermore, the calling module includes: The tagging unit is used to tag the generation source and initial reuse priority of newly generated keywords when updating the structured test knowledge base; the preset test case template is classified according to test type and includes placeholders for test case identifier, test level, step execution code and result verification code.

[0143] In an exemplary embodiment, the method described above is applied in a vehicle-mounted system testing scenario for a smart cockpit as follows: I. Construction of a scenario-based knowledge base: focusing on the core modules of the intelligent cockpit When initializing the structured test knowledge base, the focus is on storing multi-dimensional knowledge of high-frequency test scenarios for intelligent cockpits: Media control module: Stores action descriptions such as "P_The vehicle system is in the media playback interface", "A_Rotate the central control volume knob", and "E_The screen volume bar changes synchronously". The corresponding code snippets follow the "UI operation four-stage standard" (such as calling the vehicle system ADB interface through svw.ivi().adb to obtain the volume knob UI element volume_knob). The semantic vector is generated by the algorithm model based on core semantics such as "volume adjustment" and "knob operation".

[0144] Voice interaction module: Added "voice command - API mapping" knowledge, such as the corresponding method voiceCommand("open airconditioner 24 degrees") for "A_voice command 'turn on the air conditioner to 24 degrees'", and the UI element information is associated with "voice wake-up button" and "air conditioner temperature display area".

[0145] Cross-module collaboration scenario: Store "navigation + media linkage" knowledge, such as the code snippet "reduce media volume when A_navigation broadcast" which contains inter-process communication logic. The applicable scenario is marked as "navigation voice priority scenario".

[0146] II. Test Case Information Extraction: Adapting to Smart Cockpit Test Data Format Extract information from commonly used Excel templates (including "Cockpit Module" and "Interaction Method" columns) or test management tools (such as the "Smart Cockpit Test Plan" project in Jira) to construct a standardized issue dictionary: Basic information: Use case IDs are named in the format of "module-function-serial number" (e.g., "Cockpit_Voice_AirConditioner_003"). The maximum execution time is set to "5s" according to the speech recognition response requirements (to avoid misjudgment due to timeout).

[0147] Step information: Strictly distinguish between P_ / A_ / E_ types, for example: P_Prerequisites: "P_Vehicle infotainment system connected to the network, user account logged in, air conditioning turned off"; A_Execution steps: "A_Press the voice button on the steering wheel and say 'Turn on the air conditioner to 24 degrees'"; E_ Expected Result: "E_ Air conditioner starts, screen displays current temperature 24℃, voice feedback 'Air conditioner has been turned on for you'."

[0148] Contextual information: Add "interaction method = voice + screen feedback" and "related UI elements = voice_button, ac_temp_display" to provide contextual anchors for subsequent searches.

[0149] III. Three-stage concurrent processing: Improving the efficiency of handling complex scenarios in intelligent cockpits For multi-step, cross-module test cases in smart cockpits (such as "voice-controlled navigation + media volume adjustment"), the generation cycle is shortened through concurrent processing: Concurrent preprocessing by script: Voice intent recognition: "A_Press the voice button and speak the command" is determined as "voice input" and triggers subsequent voice API adaptation; "A_Slide the screen to switch songs" is determined as "touch screen operation" and is associated with touch screen UI element retrieval.

[0150] Problem rewriting and expansion: Expand "A_Navigation broadcast lowers media volume" to "Navigation broadcast, media volume adjustment, cross-module priority, automatic volume reduction" to cover both scenario terms and technical terms.

[0151] Concurrent retrieval during the recall process: Based on multi-dimensional search terms, the "regular test knowledge base" (obtaining the "lowerMediaVolume()" method) and the "UI knowledge base" (obtaining the navigation broadcast status element navi_broadcast_status) are retrieved simultaneously. Reusable knowledge with a similarity of 0.91 (such as the code snippet "lower media volume when navigation starts") is selected through an internal RAG process.

[0152] Concurrent generation within the script: If the retrieved keywords match the current vehicle infotainment system version (e.g., the UI element navi_broadcast_status_v3 matches the 2024 model), they are directly reused; if it is a new scenario (e.g., "AR-HUD navigation broadcast"), an enhanced AI generation process is triggered. The steps are: "Detect AR-HUD startup status → Obtain current media volume value → Reduce volume by 30% during navigation playback → Restore volume after playback ends"; Generate a new keyword `adjustMediaVolumeOnARHUDNavi()`, the code of which includes the AR-HUD interface `svw.arhud().getStatus()` and volume adjustment logic.

[0153] IV. Intelligent Verification and Script Generation: Adapting to Vehicle Infotainment Testing Framework and Iteration Requirements Intelligent unified verification: The generated code is converted into a test framework API specifically for smart cockpits (e.g., converting the general cvtest.click() to svw.cockpit().clickByCoordinate(x,y) to adapt to the touch screen coordinate system), and unused redundant statements such as import svw.adb_old are cleaned up.

[0154] Preset template filling: Call the "Voice Interaction Test Template", fill in the test case ID, step code (such as voiceCommand() call) and result verification code (verifyACStatus(24)), and generate a complete script that can be directly imported into the vehicle system test tool (such as AutoStudio): def test_Cockpit_Voice_AirConditioner_003(): #Prerequisite: Check vehicle infotainment system status checkVehicleInPGear() checkCockpitNetworkConnected() #Execution steps: Voice control of the air conditioner pressVoiceButton() voiceCommand("Turn the air conditioner to 24 degrees") #Result Validation verifyACStatus(expected_temp=24) verifyVoiceFeedback("Air conditioning has been turned on for you") V. Knowledge Closed-Loop Update: Supporting Rapid Iteration of Intelligent Cockpits Newly generated keywords (such as adjustMediaVolumeOnARHUDNavi()) are updated to the knowledge base according to the rules: marked as "AI generated - pending verification", with an initial priority of "medium"; after three real vehicle tests without errors, they are automatically updated to "verified" and their priority is increased for reuse in subsequent AR-HUD model tests.

[0155] In intelligent cockpit testing, this method improves the efficiency of script development for similar scenarios by 80% through structured knowledge reuse (reducing the single script generation time from 2 hours to 20 minutes). Semantic retrieval and intelligent verification ensure a code adaptation rate of ≥95%, solving the pain points of traditional manual writing such as "difficult adaptation, slow iteration, and cumbersome cross-module collaborative testing". It supports the full-process automation of intelligent cockpit from functional verification to multi-scenario linkage testing, accelerating the iteration and launch of vehicle system.

[0156] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned test code automatic generation device, or the processor performing the method as described in any of the above embodiments.

[0157] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0158] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0159] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0160] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0161] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0162] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0163] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0164] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0165] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0166] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for automatically generating test code, characterized in that, include: Initialize the structured test knowledge base; The structured test knowledge base stores multi-dimensional test knowledge, which supports semantic retrieval and dynamic updates. Extract test case information from the test data source to build a standardized issue dictionary containing test case identifiers, test levels, step types, and associated scenarios. New test keyword codes are generated by sequentially performing script-based concurrent preprocessing, concurrent retrieval during the recall process, and concurrent generation within the script on the standardized question dictionary. The new test keyword code is intelligently and uniformly validated, and if the validation passes, the keyword code that conforms to the target test specification is obtained; The system calls a preset test case template, fills in the problem dictionary information and keyword codes that conform to the target test specifications to generate complete test code, and updates the newly generated keywords to the structured test knowledge base.

2. The test code automatic generation method according to claim 1, characterized in that, The multi-dimensional test knowledge includes: test action description, corresponding method name, code snippet, UI element information, parameter rules, applicable scenarios, and semantic vector; the semantic vector is generated by the algorithm semantic model and is used for semantic similarity judgment.

3. The test code automatic generation method according to claim 1, characterized in that, The test data source is an Excel spreadsheet or a test management tool. The extracted test case information includes basic information, step information, and context information. The basic information includes the test case ID and the upper limit of execution time. The step information includes the preconditions, execution steps, and expected results.

4. The test code automatic generation method according to any one of claims 1-3, characterized in that, The script-based concurrent preprocessing includes: For each step, voice intent recognition and question rewriting / expansion are performed concurrently; the voice intent recognition distinguishes whether a step is a voice operation, and the question rewriting / expansion generates multi-dimensional search terms containing the main search term, scenario terms, and technical terms.

5. The test code automatic generation method according to any one of claims 1-3, characterized in that, When the script is generated concurrently, if the search report determines that there are no reusable keywords or that the UI elements containing reusable keywords are not suitable for the current scenario, new test keyword code is generated.

6. The test code automatic generation method according to claim 5, characterized in that, The concurrent retrieval process of the recall process is based on the multi-dimensional search terms and simultaneously retrieves the conventional test knowledge base and the UI knowledge base. The concurrent retrieval process of the recall process is implemented through the internal RAG retrieval process. The internal RAG retrieval process includes Rag Flow retrieval, Rerank re-ranking, Top-K result filtering and model filtering in sequence, and filters out reusable knowledge with semantic similarity greater than or equal to a preset threshold.

7. The test code automatic generation method according to claim 1, characterized in that, The intelligent unified verification includes: Convert the generic test framework API in the new test keyword code to the test framework API adapted to the target vehicle model, and verify the consistency between the converted API and the test specifications of the target vehicle model; If the converted API meets the preset conditions for consistency with the target vehicle model's testing specifications, perform the following operations on the new test keyword code: Perform syntax checks on the code containing new test keywords and correct Python syntax errors, including indentation errors, mismatched parentheses, and undefined variable references. Remove unused import statements and unused variables from the code containing the new test keyword; If the above steps are completed, the new test keyword code verification is confirmed to have passed; if the above steps are not completed, the new test keyword code verification is confirmed to have failed. If the consistency between the converted API and the target vehicle model's testing specifications does not meet the preset conditions, the new test keyword code verification is determined to fail.

8. The test code automatic generation method according to claim 1, characterized in that, When updating the newly generated keywords to the structured test knowledge base, the source of the keyword generation and the initial reuse priority are marked; the preset test case template is classified according to test type and includes placeholders for test case identifier, test level, step execution code and result verification code.

9. A test code automatic generation device, characterized in that, The device includes: An initialization module is used to initialize a structured test knowledge base; the structured test knowledge base stores multi-dimensional test knowledge, and the test knowledge supports semantic retrieval and dynamic updates; The test case information extraction module is used to extract test case information from the test data source, so as to build a standardized problem dictionary containing test case identifier, test level, step type and associated scenario; The question dictionary processing module is used to generate new test keyword codes by sequentially performing script-based concurrent preprocessing, concurrent retrieval during the recall process, and concurrent generation within the script on the standardized question dictionary. The verification module is used to perform intelligent and unified verification on the new test keyword code. If the verification passes, the keyword code that conforms to the target test specification is obtained. The calling module is used to call a preset test case template, fill in the problem dictionary information and keyword codes that conform to the target test specifications to generate complete test code, and update the newly generated keywords to the structured test knowledge base.

10. An electronic device, characterized in that, It includes a processor and the test code automatic generation device as described in claim 9, or the processor performs the method as described in any one of claims 1-8.

Images