Vehicle-side software test case generation method and device, equipment and storage medium

Abstract

The invention relates to a vehicle end software test case generation method and device, equipment and a storage medium. The method comprises the steps of obtaining test demand description information matched with a test request in response to the test request for the vehicle-side software; obtaining vehicle end test case data matched with the test demand description information from a pre-constructed vehicle end test case knowledge base, and obtaining vehicle signal constraints matched with the test demand description information from a pre-constructed vehicle signal knowledge graph; and on the basis of the vehicle-side test case data, the vehicle signal constraint and the test demand description information, constructing a cue word, inputting the cue word into a pre-constructed large language model, and generating a target test case for the vehicle-side software through the large language model. By adopting the method, the accuracy of the generated vehicle end software test case can be improved.

Description

Technical Field

[0001] This application relates to the field of vehicle-side testing technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for generating test cases for vehicle-side software. Background Technology

[0002] With the development of vehicle-side testing technology, a technique has emerged to test vehicle-side software using test cases. Vehicle-side test cases can standardize the testing process by clearly defining inputs, operation steps, and expected results, thereby ensuring the rigor and repeatability of the test.

[0003] Currently, in order to improve the efficiency of generating test cases for vehicle-side software, test cases can be generated through large language models. However, test cases generated directly through large language models may have problems such as easy signal tampering, and therefore cannot meet the high-precision business requirements of the test scenario. The accuracy of test cases generated by large language models for vehicle-side software is currently low. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for generating vehicle-side software test cases that can improve the accuracy of vehicle-side software test cases generated from large language models, in order to address the aforementioned technical problems.

[0005] Firstly, this application provides a method for generating test cases for vehicle-side software, including:

[0006] In response to a test request for the vehicle-side software, obtain test requirement description information that matches the test request;

[0007] From the pre-built vehicle-side test case knowledge base, obtain vehicle-side test case data that matches the test requirement description information, and from the pre-built vehicle signal knowledge graph, obtain vehicle signal constraints that match the test requirement description information.

[0008] Based on the vehicle-side test case data, vehicle signal constraints, and test requirement description information, prompt words are constructed. The prompt words are then input into a pre-constructed large language model, which generates target test cases for the vehicle-side software.

[0009] In one embodiment, obtaining vehicle-side test case data matching the test requirement description information from a pre-built vehicle-side test case knowledge base includes: obtaining a text vector corresponding to the test requirement description information; obtaining first vehicle-side test case data matching the text of the test requirement description information from the vehicle-side test case knowledge base, and obtaining second vehicle-side test case data similar to the text vector; sorting the first vehicle-side test case data and the second vehicle-side test case data according to their relevance to the test requirement description information, and obtaining vehicle-side test case data matching the test requirement description information based on the sorting result.

[0010] In one embodiment, the vehicle-side test case knowledge base consists of multiple pre-labeled sample vehicle-side test case data. Each sample test case data carries a test case description field, which stores sample test requirement description information corresponding to each sample test case data. The step of obtaining first vehicle-side test case data matching the test requirement description information text from the vehicle-side test case knowledge base, and obtaining second vehicle-side test case data similar to the text vector, includes: obtaining the text correlation between the test requirement description information and each sample test requirement description information, and obtaining the first vehicle-side test case data from the sample vehicle-side test case data based on the text correlation; obtaining the vector similarity between the text vector and the sample text vectors corresponding to each sample test requirement description information, and obtaining the second vehicle-side test case data from the sample vehicle-side test case data based on the vector similarity.

[0011] In one embodiment, obtaining vehicle signal constraints that match the test requirement description information from a pre-built vehicle signal knowledge graph includes: obtaining vehicle signal data that matches the test requirement description information text from the vehicle signal knowledge graph; the vehicle signal data carries multiple signal data fields; obtaining target vehicle signal data corresponding to the target signal data field from the vehicle signal data, and constructing the vehicle signal constraints based on the target vehicle signal data.

[0012] In one embodiment, the vehicle signal knowledge graph consists of multiple pre-labeled sample vehicle signal data, each sample vehicle signal data carrying a vehicle signal description field, which is used to store sample vehicle signal description information for each sample vehicle signal data; the step of obtaining vehicle signal data that matches the test requirement description information text from the vehicle signal knowledge graph includes: obtaining the text correlation between the test requirement description information and each sample vehicle signal description information, and obtaining the vehicle signal data that matches the test requirement description information text from the sample vehicle signal data based on the text correlation.

[0013] In one embodiment, the step of obtaining test requirement description information matching the test request in response to a test request for vehicle-side software includes: in response to the test request, obtaining original test requirement description information input for the test request; the original test requirement description information includes either a test requirement text dialogue or a test requirement document; if the original test requirement description information is a test requirement text dialogue, performing query rewriting processing on the original test requirement description information, and using the query rewritten original test requirement description information as the test requirement description information; if the original test requirement description information is a test requirement document, performing segmentation processing on the original test requirement description information to obtain the smallest requirement unit contained in the original test requirement description information, and using the smallest requirement unit as the test requirement description information.

[0014] In one embodiment, the step of constructing prompt words based on the vehicle-side test case data, vehicle signal constraints, and test requirement description information, inputting the prompt words into a pre-built large language model, and generating target test cases for the vehicle-side software through the large language model includes: inputting the test case data, vehicle signal constraints, and test requirement description information into a pre-built prompt word template to obtain the prompt words; the prompt words carry role information and test case output standard information; inputting the prompt words into the large language model, using the role represented by the role information, combining the test case data, vehicle signal constraints, and test requirement description information to generate target test cases, and outputting the target test cases according to the test case output standard information.

[0015] Secondly, this application also provides a vehicle-side software test case generation device, comprising:

[0016] The requirement description acquisition module is used to respond to a test request for the vehicle software and acquire test requirement description information that matches the test request.

[0017] The input parameter acquisition module is used to acquire vehicle-side test case data that matches the test requirement description information from a pre-built vehicle-side test case knowledge base, and to acquire vehicle signal constraints that match the test requirement description information from a pre-built vehicle signal knowledge graph.

[0018] The test case generation module is used to construct prompt words based on the vehicle-side test case data, vehicle signal constraints, and the test requirement description information, input the prompt words into a pre-built large language model, and generate target test cases for the vehicle-side software through the large language model.

[0019] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any embodiment of the first aspect.

[0020] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any embodiment of the first aspect.

[0021] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any embodiment of the first aspect.

[0022] The aforementioned vehicle-side software test case generation method, apparatus, computer equipment, computer-readable storage medium, and computer program product, in response to a test request for the vehicle-side software, acquire test requirement description information matching the test request; acquire vehicle-side test case data matching the test requirement description information from a pre-built vehicle-side test case knowledge base, and acquire vehicle signal constraints matching the test requirement description information from a pre-built vehicle signal knowledge graph; construct prompt words based on the vehicle-side test case data, vehicle signal constraints, and test requirement description information, input the prompt words into a pre-built large language model, and generate target test cases for the vehicle-side software through the large language model. When this application receives a test request from the vehicle-side software, it can respond to the request and obtain the corresponding test requirement description information. Then, it can obtain vehicle-side test case data matching the test requirement description from a pre-built vehicle-side test case knowledge base, and obtain vehicle signal constraints matching the test requirement description from a pre-built vehicle signal knowledge graph. Then, it can combine the vehicle-side test case data, vehicle signal constraints, and test requirement description to generate target test cases for the vehicle-side software through a large language model. By combining the vehicle-side test cases provided by the vehicle-side test case knowledge base and the vehicle signal constraints provided by the vehicle signal knowledge graph when generating target test cases for the vehicle-side software through the large language model, this application can avoid the problem of easy signal tampering, thus improving the accuracy of the generated vehicle-side software test cases. Attached Figure Description

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

[0024] Figure 1 This is a flowchart illustrating a method for generating test cases for vehicle-side software in one embodiment;

[0025] Figure 2 This is a flowchart illustrating the process of obtaining vehicle-side test case data in one embodiment;

[0026] Figure 3 This is a schematic diagram of the process for obtaining test requirement description information in one embodiment;

[0027] Figure 4 This is a flowchart illustrating the process of generating target test cases in one embodiment;

[0028] Figure 5This is a structural block diagram of a vehicle-side software test case generation device in one embodiment;

[0029] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0031] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0032] In one embodiment, such as Figure 1 As shown, a method for generating test cases for vehicle-side software is provided. This embodiment illustrates the method by applying it to a server. It is understood that this method can also be applied to a terminal, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0033] Step S101: In response to a test request for the vehicle-side software, obtain test requirement description information that matches the test request.

[0034] Test requirement description information is used to describe the test requirements for the vehicle-side software, while test request is a request initiated by the user to test the vehicle-side software. Specifically, when a user needs to test the vehicle-side software, they can input the test requirement description for the vehicle-side software into the server. At this time, the server can respond to the request and obtain the test requirement description information that matches the test request.

[0035] Step S102: Obtain vehicle-side test case data that matches the test requirement description information from the pre-built vehicle-side test case knowledge base, and obtain vehicle signal constraints that match the test requirement description information from the pre-built vehicle signal knowledge graph.

[0036] The vehicle-side test case knowledge base refers to a pre-built knowledge base used to store various standard vehicle-side test case data, while the vehicle signal knowledge graph is a pre-built knowledge graph used to store various standard vehicle signal information. Specifically, after obtaining the test requirement description information, the server can query the pre-built vehicle-side test case knowledge base to find vehicle-side test case data that matches the test requirement description information, and query the pre-built vehicle signal knowledge graph to find vehicle signal information that matches the test requirement description information, thereby constructing vehicle signal constraints.

[0037] Step S103: Construct prompt words based on vehicle-side test case data, vehicle signal constraints, and test requirement description information. Input the prompt words into a pre-built large language model and generate target test cases for the vehicle-side software through the large language model.

[0038] Hint words are information used to prompt the large language model to generate test cases for vehicle-side software. After the server obtains vehicle-side test case data that matches the test requirement description information and vehicle signal constraints, it can also combine the vehicle-side test case data, vehicle signal constraints, and test requirement description information to construct corresponding hint words. These hint words are then input into the pre-built large language model, which generates target test cases for the vehicle-side software based on the hint words. Because the hint words contain vehicle signal constraints, problems such as signal tampering in the vehicle-side software test cases generated by the large language model can be avoided, thus improving the accuracy of vehicle-side software test case generation.

[0039] In the above-mentioned method for generating test cases for vehicle-side software, in response to a test request for the vehicle-side software, test requirement description information matching the test request is obtained; vehicle-side test case data matching the test requirement description information is obtained from a pre-built vehicle-side test case knowledge base, and vehicle signal constraints matching the test requirement description information are obtained from a pre-built vehicle signal knowledge graph; prompt words are constructed based on the vehicle-side test case data, vehicle signal constraints, and test requirement description information, and the prompt words are input into a pre-built large language model to generate target test cases for the vehicle-side software. When this application receives a test request from the vehicle-side software, it can respond to the request and obtain the corresponding test requirement description information. Then, it can obtain vehicle-side test case data matching the test requirement description from a pre-built vehicle-side test case knowledge base, and obtain vehicle signal constraints matching the test requirement description from a pre-built vehicle signal knowledge graph. Then, it can combine the vehicle-side test case data, vehicle signal constraints, and test requirement description to generate target test cases for the vehicle-side software through a large language model. By combining the vehicle-side test cases provided by the vehicle-side test case knowledge base and the vehicle signal constraints provided by the vehicle signal knowledge graph when generating target test cases for the vehicle-side software through the large language model, this application can avoid the problem of easy signal tampering, thus improving the accuracy of the generated vehicle-side software test cases.

[0040] In one embodiment, such as Figure 2 As shown, step S102 may further include:

[0041] Step S201: Obtain the text vector corresponding to the test requirement description information;

[0042] Step S202: Obtain first vehicle-side test case data that matches the test requirement description information text from the vehicle-side test case knowledge base, and obtain second vehicle-side test case data that is similar to the text vector.

[0043] A text vector refers to the vector corresponding to the test requirement description information. In this embodiment, the test requirement description information can be composed of text information. The server can calculate the vector corresponding to the text information to obtain the text vector corresponding to the test requirement description information.

[0044] The first vehicle-side test case data refers to the vehicle-side test case data obtained by matching the test requirement description information text in the vehicle-side test case knowledge base, while the second vehicle-side test case data refers to the vehicle-side test case data obtained by similarity matching of text vectors in the vehicle-side test case knowledge base.

[0045] Specifically, after obtaining the test requirement description information, the server can retrieve the vehicle-side test case knowledge base in two ways to obtain matching vehicle-side test case data: sparse retrieval and dense retrieval. The sparse retrieval method directly uses the test requirement description information to retrieve the vehicle-side test case knowledge base, thereby obtaining the first vehicle-side test case data with text matching. The dense retrieval method uses the text vector corresponding to the test requirement description information to retrieve the vehicle-side test case knowledge base, thereby obtaining the second vehicle-side test case data with similar text vectors.

[0046] Step S203: Sort the first vehicle-side test case data and the second vehicle-side test case data according to their relevance to the test requirement description information, and obtain the vehicle-side test case data that matches the test requirement description information based on the sorting results.

[0047] After obtaining the first and second vehicle-side test case data, the first and second vehicle-side test case data can be sorted according to their relevance to the test requirement description information. Then, the vehicle-side test case data that matches the test requirement description information can be selected according to the sorting results. For example, the top K vehicle-side test case data can be used as the vehicle-side test case data that matches the test requirement description information.

[0048] In this embodiment, vehicle-side test case data in the vehicle-side test case knowledge base can be retrieved through both text matching and vector similarity matching. Furthermore, the query results obtained from the two methods can be reordered to obtain vehicle-side test case data that matches the test requirement description information. This method can further improve the accuracy of vehicle-side test case data query.

[0049] Furthermore, the vehicle-side test case knowledge base consists of multiple pre-labeled sample vehicle-side test case data. Each sample test case data carries a test case description field, which is used to store the sample test requirement description information corresponding to each sample test case data. Step S202 may further include: obtaining the textual correlation between the test requirement description information and the test requirement description information of each sample, and obtaining the first vehicle-side test case data from the sample vehicle-side test case data based on the textual correlation; obtaining the vector similarity between the text vector and the sample text vector corresponding to the test requirement description information of each sample, and obtaining the second vehicle-side test case data from the sample vehicle-side test case data based on the vector similarity.

[0050] Sample vehicle-side test case data refers to pre-annotated vehicle-side test case data. This annotation can be based on requirements documents, test cases, and feature lists. After the sample vehicle-side test case data is annotated, it can be stored in a vector database to build a vehicle-side test case knowledge base. The test case description field is a field in the sample vehicle-side test case data used to store information related to the requirements document. Therefore, it can be used to store the test requirement description information corresponding to the sample test case data, i.e., the sample test requirement description information.

[0051] Specifically, the vehicle-side test case knowledge base can consist of multiple pre-labeled sample vehicle-side test case data, and each sample vehicle-side test case data contains a test case description field. This test case description field stores the test requirement description information corresponding to the sample test case data. Therefore, when retrieving vehicle-side test case data, the textual correlation between the test requirement description information and the sample test requirement description information of each sample vehicle-side test case data in the vehicle-side test case knowledge base can be calculated, thereby retrieving the first vehicle-side test case data with text matching based on the textual correlation.

[0052] For text vector matching, the similarity between the text vector describing the test requirements and the sample text vectors of various sample vehicle test case data in the vehicle test case knowledge base can be calculated. The second vehicle test case data with similar text vectors can then be retrieved based on the vector similarity.

[0053] In this embodiment, a vehicle-side test case knowledge base can also be constructed using pre-annotated sample vehicle-side test case data. The sample vehicle-side test case data can carry a test case description field, which can store the sample test requirement description information corresponding to each sample test case data. Therefore, by performing text relevance matching and vector similarity calculation on the sample test requirement description information, the first vehicle-side test case data and the second vehicle-side test case data can be retrieved. This method can improve the relevance between the retrieved vehicle-side test case data and the test requirement description information.

[0054] In one embodiment, step S102 may further include: obtaining vehicle signal data that matches the test requirement description information text from the vehicle signal knowledge graph; the vehicle signal data carries multiple signal data fields; obtaining target vehicle signal data corresponding to the target signal data field from the vehicle signal data, and constructing vehicle signal constraints based on the target vehicle signal data.

[0055] In this embodiment, the vehicle signal knowledge graph can store vehicle signal data corresponding to various vehicle signals, and each vehicle signal data can contain multiple signal data fields. For example, a vehicle signal data can carry fields such as: signal file name (FileName), signal row (row), signal ID (rowId), signal name (signalName), signal description (signalDescription), bus minimum value (signalMin.ValueHex), bus maximum value (signalMax.ValueHex), signal initial value (initialValueHex), signal invalid value (invalidValueHex), unit (unit), and signal value description (valueDescription). The target signal data field refers to the signal data field used as a reference for constructing vehicle signal constraints among the multiple signal data fields, and the target vehicle signal data refers to the data stored in the target signal data field.

[0056] Specifically, after obtaining the test requirement description information, the server can also use the test requirement description information to perform text matching on the various vehicle signal data stored in the vehicle signal knowledge graph, thereby querying the vehicle signal data that matches the text of the test requirement description information. Then, it can obtain the data corresponding to the target signal data field in the vehicle signal data as the target vehicle signal data, and use the target vehicle signal data to construct vehicle signal constraints.

[0057] In this embodiment, vehicle signal data can also be retrieved from the vehicle signal knowledge graph by text matching, and then the content of the target signal data field in the vehicle signal data can be used to construct vehicle signal constraints. This method can ensure the accuracy of vehicle signal constraints.

[0058] Furthermore, the vehicle signal knowledge graph consists of multiple pre-labeled sample vehicle signal data. Each sample vehicle signal data carries a vehicle signal description field, which is used to store the sample vehicle signal description information of each sample vehicle signal data. Obtaining vehicle signal data that matches the test requirement description information text from the vehicle signal knowledge graph may further include: obtaining the textual correlation between the test requirement description information and the description information of each sample vehicle signal, and obtaining the vehicle signal data that matches the test requirement description information text from the sample vehicle signal data based on the textual correlation.

[0059] Sample vehicle signal data refers to the vehicle signal data stored in the vehicle signal knowledge graph. This sample vehicle signal data can be extracted from the structured document of vehicle signal data to construct the vehicle signal knowledge graph. Furthermore, among the multiple signal data fields carried by this sample vehicle signal data, there may be a vehicle signal description field. The vehicle signal description information stored in this field is mainly used to describe the signal type corresponding to the sample vehicle signal data, such as a radar system fault status signal or a remaining maintenance mileage signal. Therefore, the vehicle signal data matching the test requirement description information can be identified through the vehicle signal description information. For example, if the test requirement description information is to query the remaining maintenance mileage, then the vehicle signal data obtained through text matching can be the vehicle signal data associated with the remaining maintenance mileage signal.

[0060] Specifically, after obtaining the test requirement description information, the server can use the test requirement description information to perform text relevance matching with the sample vehicle signal description information of the sample vehicle signal data in each vehicle signal knowledge graph. In this way, the server can query the sample vehicle signal data that matches the text of the test requirement description information based on the text relevance.

[0061] In this embodiment, the vehicle signal data matching the test requirement description information can also be retrieved from the sample vehicle signal data based on the textual correlation between the test requirement description information and the signal description information of each sample vehicle. This method can improve the accuracy of vehicle signal data retrieval.

[0062] In one embodiment, such as Figure 3 As shown, step S101 may further include:

[0063] Step S301: In response to the test request, obtain the original test requirement description information input for the test request; the original test requirement description information includes either a test requirement text dialogue or a test requirement document.

[0064] The original test requirement description information is the test requirement description information directly input by the user when initiating a test request for the vehicle-side software. In this embodiment, the test requirement description information used to match the knowledge base and knowledge graph can be obtained by preprocessing the original test requirement description information input by the user. The types of original test requirement description information input by the user can also be the following two: test requirement text dialogue and test requirement document. That is, the user can initiate a test request for the vehicle-side software through test requirement text dialogue or test requirement document.

[0065] Specifically, after a user inputs the original test requirement description information to initiate a test request for the vehicle-side software, the server can respond to the request and obtain the original test requirement description information, which can be a test requirement text dialogue or a test requirement document.

[0066] Step S302: When the original test requirement description information is a test requirement text dialogue, the original test requirement description information is queried and rewritten, and the queried and rewritten original test requirement description information is used as the test requirement description information.

[0067] If the original test requirement description is a text dialogue entered by the user, the server can rewrite the original test requirement description to transform the colloquial and ambiguous input into a clearer and easier-to-understand query. This process can be achieved by pre-constructing a thesaurus, mapping different expressions of client-side terminology to standard terms, and then iterating through the query terms and replacing them with the standard terms from the thesaurus. In this way, the rewritten original test requirement description can be obtained and used as the test requirement description.

[0068] Step S303: When the original test requirement description information is a test requirement document, the original test requirement description information is segmented to obtain the smallest requirement unit contained in the original test requirement description information, and the smallest requirement unit is used as the test requirement description information.

[0069] If the original test requirement description information is a test requirement document input by the user, such as a test requirement specification, then the original test requirement description information needs to be segmented. The segmentation method can be to identify the document's logical structure, such as titles, lists, tables, etc., and segment it according to semantic units to obtain the smallest requirement unit contained in the original test requirement description information. Then, the server can use the smallest requirement unit obtained by the above segmentation process as the test requirement description information.

[0070] In this embodiment, upon receiving a test request, the original test requirement description information input in response to the test request can be obtained. The original test requirement description information is then preprocessed to obtain test requirement description information that is easier to query. If the original test requirement description information is a test requirement text dialogue, it can be queried and rewritten. If the original test requirement description information is a test requirement document, it is segmented. This method can obtain test requirement description information that is easier to query, further improving the accuracy of knowledge base and knowledge graph queries.

[0071] In one embodiment, such as Figure 4As shown, step S103 may further include:

[0072] Step S401: Input the test case data, vehicle signal constraints, and test requirement description information into the pre-built prompt word template to obtain prompt words; the prompt words carry role information and test case output standard information.

[0073] In this embodiment, the prompt word template can include role information and test case output standard information. Therefore, the generated prompt words can also include the aforementioned role information and test case output standard information. The role information can be used to define the role played by the large language model. For example, the large language model can be set as a professional automotive software test engineer to more accurately generate vehicle-side software test cases. The test case output standard information is used to define the output format of the test cases. For example, the test cases can be defined to be output in JSON array format.

[0074] Specifically, the server can input test case data, vehicle signal constraints, and test requirement description information into a pre-built prompt template. The prompt template can also carry role information and test case output standard information. Therefore, the generated prompt can simultaneously carry test case data, vehicle signal constraints, test requirement description information, role information, and test case output standard information.

[0075] Step S402: Input the prompt words into the large language model. Use the role information represented by the role information in the large language model to generate target test cases by combining test case data, vehicle signal constraints and test requirement description information. Output the target test cases according to the test case output standard information.

[0076] After generating the prompt words, they can be input into the large language model. The large language model can then generate target test cases by combining the test case data, vehicle signal constraints, and test requirement description information input in the prompt words, according to the role represented by the role information. The target test cases are then output in the format represented by the test case output standard information.

[0077] In this embodiment, test case data, vehicle signal constraints, and test requirement description information can also be input into a pre-built prompt word template to obtain prompt words. Then, by using the role information represented by the role in the prompt words, combined with the above-mentioned test case data, vehicle signal constraints, and test requirement description information, test cases can be generated and output according to the test case output standard format in the prompt words. This method can further improve the accuracy and usability of the obtained target test cases.

[0078] In one embodiment, a method for automatically generating vehicle-side test cases based on a knowledge base and knowledge graph is also provided. The specific process may include the following steps:

[0079] Step 1: Data acquisition and preprocessing.

[0080] 1. Vehicle-side data collection:

[0081] Collect product requirements, test data, signals, and related data for various automotive projects, including common automotive-related areas such as:

[0082] (1) Voice Project: Includes test case sets, functional requirement list and requirement specification for each vehicle model of the vehicle voice recognition project. Data format: word, excel.

[0083] (2) Instrumentation Project: Includes test case sets, functional requirement list, requirement specification, and signal function correspondence table for each vehicle model. Data format: Word, Excel.

[0084] (3) Network Project: Includes test case sets, functional requirement list, requirement specification, and signal function correspondence table for each model of the network project. Data format: word, excel.

[0085] 2. Data labeling:

[0086] Using product requirements documents, test cases, and feature lists as input, and after manual annotation, output a structured annotated data table in the following unified format for knowledge base construction.

[0087] Example: Based on the specific vehicle model requirements specification and test cases, construct a test case knowledge base data. Key feature fields include: Test Case ID (id), Project Name (projectName), Module Name (moduleName), Function Name (functionName), Domain (domain), Test Case Level (level), Test Case Generation Method (method), Module Description (scenario description from the requirements specification + function definition, detailed description at the last level of the PRD document) (functionDes), Function Breakdown (function), Test Case Title (title), Preconditions (preconditions), Test Case Steps (steps), and Expected Test Case Result (expect). For example, the data annotation for a specific test case can be shown in Table 1.

[0088] Table 1. Test Case Data Annotation Diagram

[0089]

[0090] Quality Assurance: Automatically check whether signals in the labeled data, such as "0x3A1: Vcu_highVoltageSuccess=0x1: HIGH_VOLT_UP", exist in the "Signal Function Correspondence Table for a Certain Vehicle Model". If they do not exist, the test case needs to be manually reviewed.

[0091] Step 2: Building a test case knowledge base.

[0092] Using manually annotated test cases as input, a vectorized knowledge base is built. The specific process is as follows:

[0093] Knowledge processing:

[0094] The knowledge processing module primarily performs knowledge slicing and vectorization on the information extracted from documents. The specific implementation steps are as follows:

[0095] (1) Document slicing:

[0096] Since each test case is presented as a single line representing the complete content of that test case, this approach aims to ensure the integrity of the context and avoid truncating critical information.

[0097] Based on the traditional slicing strategy using the number of tokens, such as (512 + 10% token, which can be adjusted according to actual needs), a two-layer constraint slicing architecture is constructed by combining row-level logical unit slicing. The specific logic is as follows:

[0098] 1. Data acquisition.

[0099] 2. Configure the slicing parameter baseline, as shown in Table 2.

[0100] Table 2. Slice Parameter Baseline Schematic Table

[0101]

[0102] 3. Complete document slicing by configuring the slicing parameters.

[0103] By configuring the baseline for slice parameters, content integrity protection is provided for use cases while strictly meeting token restrictions, thus solving the problem of information truncation in document slicing.

[0104] (2) Vector index construction:

[0105] 1. Generate a standardized data format adapted to the vector database, perform vectorization preprocessing on text blocks, and define a standardized JSON format. For example:

[0106] {

[0107] "id": "1",

[0108] "projectName": "BM5",

[0109] "moduleName": "Instrument - Combination Trigger - Alarm and Indicator Light Illumination",

[0110] "domain": "instrument",

[0111] "level": "L1",

[0112] "method": "Equivalence class partitioning",

[0113] "functionDes": "Verifies whether the low oil pressure indicator and limited energy recovery alarm can be triggered normally in this scenario."

[0114] "function": "Simulates scenarios of low oil pressure and limited energy recovery, and tests the triggering of corresponding indicator lights and alarms",

[0115] Title: "Situation where both the low oil pressure indicator light and the limited energy recovery alarm are triggered",

[0116] "preconditions": "1. KL15 ON",

[0117] "steps":"1. Send 0x3A1: Vcu_highVoltageSuccess=0x1(HIGH_VOLT_UP) \n2. Send 0x37E: Ecu_state=0x3 (running) \n3. Oil pressure hardline low level for 3s",

[0118] "expect": "1. [None] \n2. [None] \n3. Low oil pressure indicator light will appear, and a pop-up alarm sound will be heard."

[0119] }

[0120] 2. Embedded vectorized preprocessing pipeline.

[0121] Text filtering and standardization, including:

[0122] Character filtering: Removes invisible characters and spaces.

[0123] Standardize the terminology used in vehicle-side technologies. Construct a thesaurus to map different expressions of vehicle-side terminology to the standard terminology.

[0124] For example: CAN bus → CAN; Vehicle Stability System → ESP.

[0125] Unit standardization: Converting all physical quantity units to standard units to avoid semantic ambiguity. For example:

[0126] Remaining mileage for vehicle maintenance: 1000 meters → 1 km; 1000 meters → 1 km.

[0127] 3. Signal data feature enhancement. Explicitly emphasize key signal elements in the text to help the model better understand their importance.

[0128] Add special markers to key information "signals".

[0129] For example: Signal Name: IC_VehRemMntnMile is converted to [SIG_IC_VehRemMntnMile].

[0130] Context injection: For the corresponding abbreviation or shorthand, inject the complete description within parentheses to facilitate understanding by the larger model later.

[0131] For example: Input: ESP, MCU → Input: ESP (Electronic Stability Program), MCU (Microcontroller Unit)

[0132] 4. Store the data in the vector database. Upload the processed test case data to the vector database.

[0133] For example:

[0134] {

[0135] "id": "1",

[0136] "projectName": "BM5",

[0137] "moduleName": "Instrument - Combination Trigger - Alarm and Indicator Light Illumination",

[0138] "domain": "instrument",

[0139] "level": "L1",

[0140] "method": "Equivalence class partitioning",

[0141] "functionDes": "Verifies whether the low oil pressure indicator and limited energy recovery alarm can be triggered normally in this scenario."

[0142] "function": "Simulates scenarios of low oil pressure and limited energy recovery, and tests the triggering of corresponding indicator lights and alarms",

[0143] Title: "Situation where both the low oil pressure indicator light and the limited energy recovery alarm are triggered",

[0144] "preconditions": "1. KL15 ON",

[0145] "steps":"1. Send 0x3A1: Vcu_highVoltageSuccess=0x1 (HIGH_VOLT_UP) \n2. Send 0x37E: Ecu_state=0x3 (running) \n3. Oil pressure hardline low level for 3 seconds",

[0146] "expect": "1. [None] \n2. [None] \n3. Display low oil pressure indicator light, sound one alarm tone in pop-up window A",

[0147] "user_id": "test_jjm_0001__1234",

[0148] "kb_id": "yy111111-1111-1111-1111-2820fb0ea001",

[0149] "file_id": "94ad78da44594df0b0401e6307bcb151",

[0150] "file_name": "instrument.xlsx"

[0151] }

[0152] Step 3: Constructing a signal knowledge graph.

[0153] 1. Document slicing:

[0154] Since signal data, such as CAN matrix signal data, is a highly structured document with each row representing a complete description of a signal, the "row-level logical unit" slicing strategy can be directly used. The specific steps are as follows:

[0155] Data source preparation: Obtain the raw CAN matrix signal data (Excel file).

[0156] Row-level slicing: follows the rule of "one row = one signal" and does not perform additional slicing.

[0157] Save the entire line as a JSON document. The main feature information fields include: signal file name (FileName), signal row (row), signal ID (rowId), signal name (signalName), signal description (signalDescription), bus minimum value (signalMin.ValueHex), bus maximum value (signalMax.ValueHex), signal initial value (initialValueHex), signal invalid value (invalidValueHex), unit (unit), and signal value description (valueDescription).

[0158] Example:

[0159] {

[0160] "fileName": "sf5canfile224",

[0161] "row": "1",

[0162] "rowId": "a4f2c9e8d1b3e7f9",

[0163] "signalName": "mrr_SystemFailureSt",

[0164] "signalDescription": "Radar system fault status",

[0165] " signal Min. Value Hex ": " 0x0 ",

[0166] " signal Max. ValueHex ": " 0x3 ",

[0167] "initialValueHex": "0x0",

[0168] "invalidValueHex": "",

[0169] "unit": "",

[0170] "valueDescription": "0x0: No prompt; 0x1: ACC activated;..."

[0171] }

[0172] 2. Information extraction:

[0173] Perform information extraction (structured data → triples).

[0174] Parsing the ValueDescription field:

[0175] Use regular expressions to extract “0x0: No prompt” → (value=0, description=No prompt).

[0176] Numerical normalization:

[0177] Convert a Hex string to an integer: parse_hex("0xA") → 10.

[0178] Generate triples:

[0179] • (Signal:mrr_SystemFailureSt, hasMinValue, 0)

[0180] • (Signal:mrr_SystemFailureSt, hasMaxValue, 3)

[0181] • (Signal:mrr_SystemFailureSt, hasValueDesc, ValueDesc_0x0)

[0182] • (ValueDesc_0x0, value, 0)

[0183] • (ValueDesc_0x0, description, "No prompt")

[0184] Data cleaning and quality inspection:

[0185] Deduplication: If the same SignalName appears in multiple lines, keep the latest version of the data.

[0186] Threshold validation: minimum value ≤ value ≤ maximum value.

[0187] Invalid or non-enabled values ​​that are empty are uniformly set to null.

[0188] Map storage: Import the cleaned data into the map in batches.

[0189] Step 4: Test requirements analysis.

[0190] The process involves parsing the input text dialogue content or requirements document, performing data cleaning and preprocessing to obtain high-quality text characters. The specific workflow is as follows:

[0191] (1) Input routing and multimodal parsing.

[0192] Input routing: Determine the input type and distribute it to different parsing subprocesses. Check the input file extension (e.g., .pdf, .docx); if no file is attached, it is determined to be plain text dialogue input.

[0193] (2) Dialogue input query rewriting.

[0194] Optimize the test requirements parsing results by transforming colloquial and vague inputs into clearer and easier-to-understand query statements.

[0195] 1. Construct a thesaurus of synonyms to map different expressions of vehicle-side terminology to standard terminology.

[0196] 2. Operation: Traverse the query terms and replace them with standard terms from the thesaurus.

[0197] Signal Name

[0198] Use regular expressions to match descriptions related to signals in the query.

[0199] The knowledge graph is invoked to map the functional descriptions to specific signal names.

[0200] Example:

[0201] Enter: "Check remaining maintenance mileage"

[0202] Rewritten: "Query the remaining maintenance mileage of the entire vehicle [SIG_IC_VehRemMntnMile]".

[0203] (3) Document-based requirements analysis.

[0204] Input: "Instrument Requirements Specification.word" Supports common requirement document formats such as Word, Excel, and PDF. Recognizes the document's logical structure (titles, lists, tables, etc.) and segments it according to semantic units.

[0205] 1. Format parsing and text extraction:

[0206] Parse PDF, Word, and Excel files, preserving text position and layout information. Parse titles, paragraphs, and tables; extract structured data from tables.

[0207] 2. Document structure analysis:

[0208] The layout information recognition model is used to parse heading levels (e.g., H1, H2), body text, tables, lists, headers, etc. Preliminary segmentation is then performed based on the smallest heading level. For example:

[0209] Boot animation

[0210] Scene Description

[0211] Each time the vehicle is powered on, the instrument panel needs to display a startup animation before entering self-test and working mode, showcasing the brand image and providing a transition for the start-up waiting period.

[0212] Function definition:

[0213] 1) Prerequisites:

[0214] The CDC power supply is OFF.

[0215] 2) Triggering conditions:

[0216] The CDC power supply status changes from OFF to ON.

[0217] 3) Exit conditions:

[0218] The boot animation is complete.

[0219] 4) Requirements Description:

[0220] a) When the CDC power status changes from OFF to ON, the instrument panel display starts playing the startup animation.

[0221] b) The startup animation should not be interrupted by vehicle speed or alarm messages.

[0222] c) During the power-on animation, the instrument panel display must not show any alarm symbols; both text and sound alarms must be disabled.

[0223] d) The instrument performs a self-test after the startup animation finishes playing.

[0224] e) The boot animation plays only once per sleep cycle.

[0225] f) When power is off, the power-on animation playback must be stopped immediately, and the power-off animation playback requires the minimum testable unit segmentation.

[0226] 3. Identify document structure:

[0227] Extract the core requirement description, ignoring auxiliary information such as scenario description, preconditions, triggering conditions, exit conditions, and headers. For example:

[0228] a) When the CDC power status changes from OFF to ON, the instrument panel display starts playing the startup animation.

[0229] b) The startup animation should not be interrupted by vehicle speed or alarm messages.

[0230] c) During the power-on animation, the instrument panel display must not show any alarm symbols; both text and sound alarms must be disabled.

[0231] d) The instrument performs a self-test after the startup animation finishes playing.

[0232] e) The startup animation is played only once in a sleep cycle.

[0233] f) When powering off, the startup animation playback must be ended immediately, and the minimum testable unit for the shutdown animation playback needs to be split.

[0234] 4. Sentence-level splitting:

[0235] Adopt a four-layer progressive splitting strategy of "punctuation splitting → conjunction splitting → dependency syntactic analysis → semantic integrity verification".

[0236] Punctuation splitting: The splitting delimiters are ['.', '!', '?', ';', ';'] and line breaks. Note: Commas, and the Chinese comma 、 are not used as splitting delimiters.

[0237] Conjunction splitting: Identify conjunctions indicating parallelism, progression, or contrast, and split compound sentences into atomic sentences. Among them, the corresponding relationships between each conjunction and its type are shown in Table 3.

[0238] Table 3 Conjunction illustration table

[0239]

[0240] Dependency syntactic analysis verification: Judge whether conjunctions such as "and" and "and" connect verbs or nouns to avoid incorrect splitting.

[0241] Example: Sentence: "Block text and sound alarms".

[0242] Use LTP to parse its dependency syntactic tree:

[0243] Object (alarm).

[0244] Attribute (text).

[0245] Attribute (sound).

[0246] Conclusion:

[0247] Both "text" and "sound" are attributes of "alarm".

[0248] The "and" connects two attributes, not two verbs.

[0249] Should not be split → Remain as "Block text and sound alarms".

[0250] Semantic integrity repair: After splitting, there may be incomplete sentences with missing subjects or conditions.

[0251] Original sentence: "When the power is turned on, play the startup animation and block the alarm."

[0252] After splitting:

[0253] 1. Play the boot animation

[0254] 2. Alarm blocking

[0255] Repair strategy:

[0256] Subject inheritance: Inherited from the subject of the previous sentence ("power source").

[0257] Conditional inheritance: Inherits the nearest "when..." condition.

[0258] Repair strategy: → Disable alarms → Disable alarms when power is on.

[0259] Step 5: Knowledge Retrieval.

[0260] The rewritten sentence or the smallest segmented requirement unit (e.g., "When the power is on, disable the alarm") is used as the query input, and a mixed search is performed in the knowledge base (test case labeled data).

[0261] 1. Hybrid Search:

[0262] By combining sparse and dense retrieval techniques, a list of documents most relevant to the query is returned.

[0263] Sparse retrieval: Using the BM25 algorithm to retrieve text (such as text, SignalName).

[0264] Dense retrieval: Using the same embedding model as vectorization, the rewritten query is converted into a vector. Approximate nearest neighbor search (ANN) is performed on the vector database to calculate the cosine similarity between the query vector and all document block vectors.

[0265] 2. Retrieval Rearrangement:

[0266] The results obtained from sparse and dense searches are reordered according to relevance to obtain the top-K results.

[0267] Step 6: Constructing prompts.

[0268] Combine the rewritten query sentence or the smallest segmented requirement unit with the relevant test case data retrieved from the knowledge base to design a clear and unambiguous prompt word.

[0269] Example:

[0270] <Character>

[0271] You are a professional automotive software test engineer. Your task is to generate complete, accurate, and executable test cases based on the provided <requirements description>, <test cases>, and <signal information>. Test cases must strictly conform to the requirements and follow the provided "Test Case Format".

[0272] <Test Case Format Requirements>

[0273] Test cases must be output in the following JSON array format, containing only JSON objects without any further interpretation: [

[0275] {

[0276] "id": "Unique test case ID, formatted as 'System_Function_Serial Number'",

[0277] "title": "Test case title, concise and to the point",

[0278] "preconditions": "Conditions that must be met before the test can be performed, such as vehicle status, environmental settings, etc."

[0279] "steps": "Clear and actionable descriptions of actions",

[0280] "expect": "The final expected output of the entire test case"

[0281] } ]

[0283] <Requirements Description>

[0284] Requirement: "Check remaining maintenance mileage"

[0285] <Signal Information>

[0286] CAN signal: Remaining maintenance mileage signal is "(Signal:mrr_SystemFailureSt, ValueDesc_0x0, description, "No prompt")

[0287] <Reference Information>

[0288] <Test Cases>:

[0289] {

[0290] "test_case_id": "TC_MNT_001",

[0291] "title": "Check Remaining Maintenance Mileage",

[0292] "preconditions": "Vehicle has been started, maintenance system has completed initialization, maintenance schedule has been set".

[0293] "steps": "1. Send 0x239: mrr_SystemFailureSt=0x1 (temporaryfailure)",

[0294] "expect": "The vehicle will accurately display the remaining maintenance mileage information."

[0295] }

[0296] Step 7: LLM inference and structured output.

[0297] 1. Model selection:

[0298] Choose a model that is suitable for test case generation and structured output.

[0299] Parameter configuration: For deterministic tasks such as generating test cases, model parameters such as Temperature, Top P, Top K, frequency penalty, presence penalty, and maximum number of tokens (max_new_tokens) are adjusted to find the most suitable parameters for test case generation.

[0300] How to use: Send the constructed prompts to the LLM via the API and get the returned results.

[0301] Returned results: Structured parsing and post-processing.

[0302] 2. Structured output

[0303] The output of LLM may be "JSON-like," which needs to be parsed into a workable data structure and validated. Specific validation steps are as follows:

[0304] Schema validation: Use the jsonschema library to verify that the output fully conforms to our defined JSON Schema.

[0305] Signal validity check: Checks whether the correct CAN signal is being used.

[0306] After verification, the final structured output is:

[0307] Example:

[0308] {

[0309] "test_case_id": "TC_MNT_001",

[0310] "title": "Check Remaining Maintenance Mileage",

[0311] "preconditions": "Vehicle has been started, maintenance system has completed initialization, maintenance schedule has been set".

[0312] "steps": "1. Send 0x239: mrr_SystemFailureSt=0x1 (temporaryfailure)",

[0313] "expect": "The vehicle will accurately display the remaining maintenance mileage information."

[0314] }

[0315] In this embodiment, by combining knowledge fusion, knowledge graph constraint injection, and large models, the core pain point of "inaccurate generation" of large models in the automotive testing field is solved, achieving highly accurate test case generation. The automated process reduces the test case writing time to the minute level and has cross-vehicle reuse capability, achieving a dual improvement in test case writing efficiency and knowledge reuse rate. Furthermore, it changes the mode of LLM that only relies on parameter adjustment, enabling it to use structured knowledge for reasoning and generate test cases that are more in line with actual testing specifications.

[0316] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0317] Based on the same inventive concept, this application also provides a vehicle-side software test case generation device for implementing the above-described vehicle-side software test case generation method. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more vehicle-side software test case generation device embodiments provided below can be found in the limitations of the vehicle-side software test case generation method described above, and will not be repeated here.

[0318] In one embodiment, such as Figure 5 As shown, a device for generating test cases for vehicle-side software is provided, comprising: a requirement description acquisition module 501, an input parameter acquisition module 502, and a test case generation module 503, wherein:

[0319] The requirement description acquisition module 501 is used to acquire test requirement description information that matches the test request in response to a test request for vehicle software.

[0320] The input parameter acquisition module 502 is used to acquire vehicle-side test case data that matches the test requirement description information from a pre-built vehicle-side test case knowledge base, and to acquire vehicle signal constraints that match the test requirement description information from a pre-built vehicle signal knowledge graph.

[0321] The test case generation module 503 is used to construct prompt words based on the vehicle-side test case data, vehicle signal constraints, and the test requirement description information, input the prompt words into a pre-built large language model, and generate target test cases for the vehicle-side software through the large language model.

[0322] In one embodiment, the input parameter acquisition module 502 is further configured to acquire the text vector corresponding to the test requirement description information; acquire first vehicle-side test case data matching the test requirement description information text from the vehicle-side test case knowledge base, and acquire second vehicle-side test case data similar to the text vector; sort the first vehicle-side test case data and the second vehicle-side test case data according to their relevance to the test requirement description information, and obtain vehicle-side test case data matching the test requirement description information based on the sorting result.

[0323] In one embodiment, the vehicle-side test case knowledge base consists of multiple pre-labeled sample vehicle-side test case data. Each sample test case data carries a test case description field, which is used to store sample test requirement description information corresponding to each sample test case data. The input parameter acquisition module 502 is further used to acquire the text correlation between the test requirement description information and each sample test requirement description information, and to acquire the first vehicle-side test case data from the sample vehicle-side test case data based on the text correlation; to acquire the vector similarity between the text vector and the sample text vector corresponding to each sample test requirement description information, and to acquire the second vehicle-side test case data from the sample vehicle-side test case data based on the vector similarity.

[0324] In one embodiment, the input parameter acquisition module 502 is further configured to acquire vehicle signal data matching the test requirement description information text from the vehicle signal knowledge graph; the vehicle signal data carries multiple signal data fields; acquire target vehicle signal data corresponding to the target signal data field from the vehicle signal data, and construct the vehicle signal constraint based on the target vehicle signal data.

[0325] In one embodiment, the vehicle signal knowledge graph consists of multiple pre-labeled sample vehicle signal data, each of which carries a vehicle signal description field. The vehicle signal description field is used to store the sample vehicle signal description information of each of the sample vehicle signal data. The input parameter acquisition module 502 is further used to acquire the textual correlation between the test requirement description information and each of the sample vehicle signal description information, and to acquire the vehicle signal data whose text matches the test requirement description information from the sample vehicle signal data based on the textual correlation.

[0326] In one embodiment, the requirement description acquisition module 501 is further configured to, in response to the test request, acquire original test requirement description information input in response to the test request; the original test requirement description information includes either a test requirement text dialogue or a test requirement document; if the original test requirement description information is a test requirement text dialogue, the original test requirement description information is rewritten through query, and the rewritten original test requirement description information is used as the test requirement description information; if the original test requirement description information is a test requirement document, the original test requirement description information is segmented to obtain the smallest requirement unit contained in the original test requirement description information, and the smallest requirement unit is used as the test requirement description information.

[0327] In one embodiment, the test case generation module 503 is further configured to input the test case data, vehicle signal constraints, and test requirement description information into a pre-built prompt word template to obtain the prompt word; the prompt word carries role information and test case output standard information; the prompt word is input into the large language model, and the large language model uses the role represented by the role information, combined with the test case data, vehicle signal constraints, and test requirement description information to generate target test cases, and outputs the target test cases according to the test case output standard information.

[0328] Each module in the aforementioned vehicle-side software test case generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0329] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores test case data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for generating test cases for vehicle-mounted software.

[0330] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0331] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0332] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0333] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0334] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0335] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0336] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0337] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for generating test cases for vehicle-side software, characterized in that, The method includes: In response to a test request for the vehicle-side software, obtain test requirement description information that matches the test request; From the pre-built vehicle-side test case knowledge base, obtain vehicle-side test case data that matches the test requirement description information, and from the pre-built vehicle signal knowledge graph, obtain vehicle signal constraints that match the test requirement description information. Based on the vehicle-side test case data, vehicle signal constraints, and test requirement description information, prompt words are constructed. The prompt words are then input into a pre-constructed large language model, which generates target test cases for the vehicle-side software.

2. The method according to claim 1, characterized in that, The step of obtaining vehicle-side test case data that matches the test requirement description information from a pre-built vehicle-side test case knowledge base includes: Obtain the text vector corresponding to the test requirement description information; From the vehicle-side test case knowledge base, obtain first vehicle-side test case data that matches the test requirement description information text, and obtain second vehicle-side test case data that is similar to the text vector; The first vehicle-side test case data and the second vehicle-side test case data are sorted according to their relevance to the test requirement description information, and the vehicle-side test case data that matches the test requirement description information are obtained based on the sorting results.

3. The method according to claim 2, characterized in that, The vehicle-side test case knowledge base consists of multiple pre-labeled sample vehicle-side test case data. Each sample test case data carries a test case description field, which stores the sample test requirement description information corresponding to each sample test case data. The step of retrieving first vehicle-side test case data that matches the test requirement description information text from the vehicle-side test case knowledge base, and retrieving second vehicle-side test case data that is similar to the text vector, includes: Obtain the textual correlation between the test requirement description information and each of the sample test requirement description information, and obtain the first vehicle-side test case data from the sample vehicle-side test case data based on the textual correlation; Obtain the vector similarity between the text vector and the sample text vector corresponding to each of the sample test requirement description information, and obtain the second vehicle-side test case data from the sample vehicle-side test case data based on the vector similarity.

4. The method according to claim 1, characterized in that, The step of obtaining vehicle signal constraints that match the test requirement description information from a pre-built vehicle signal knowledge graph includes: Vehicle signal data matching the test requirement description text is obtained from the vehicle signal knowledge graph; the vehicle signal data carries multiple signal data fields. From the vehicle signal data, obtain the target vehicle signal data corresponding to the target signal data field, and construct the vehicle signal constraint based on the target vehicle signal data.

5. The method according to claim 4, characterized in that, The vehicle signal knowledge graph consists of multiple pre-labeled sample vehicle signal data, each of which carries a vehicle signal description field. This vehicle signal description field stores the sample vehicle signal description information for each sample vehicle signal data. The step of retrieving vehicle signal data from the vehicle signal knowledge graph that matches the test requirement description text includes: The textual correlation between the test requirement description information and the signal description information of each sample vehicle is obtained, and the vehicle signal data that matches the text of the test requirement description information is obtained from the sample vehicle signal data based on the textual correlation.

6. The method according to claim 1, characterized in that, The step of responding to a test request for vehicle-side software by obtaining test requirement description information matching the test request includes: In response to the test request, obtain the original test requirement description information input for the test request; the original test requirement description information includes either a test requirement text dialogue or a test requirement document; When the original test requirement description information is a test requirement text dialogue, the original test requirement description information is queried and rewritten, and the queried and rewritten original test requirement description information is used as the test requirement description information. If the original test requirement description information is a test requirement document, the original test requirement description information is segmented to obtain the smallest requirement unit contained in the original test requirement description information, and the smallest requirement unit is used as the test requirement description information.

7. The method according to any one of claims 1 to 6, characterized in that, The step of constructing prompt words based on the vehicle-side test case data, vehicle signal constraints, and test requirement description information, inputting the prompt words into a pre-built large language model, and generating target test cases for the vehicle-side software through the large language model includes: The test case data, vehicle signal constraints, and test requirement description information are input into a pre-built prompt word template to obtain the prompt word; the prompt word carries role information and test case output standard information. The prompt words are input into the large language model. The large language model uses the role represented by the role information to generate target test cases by combining the test case data, vehicle signal constraints and the test requirement description information. The target test cases are then output according to the test case output standard information.

8. A device for generating test cases for vehicle-side software, characterized in that, The device includes: The requirement description acquisition module is used to respond to a test request for the vehicle software and acquire test requirement description information that matches the test request. The input parameter acquisition module is used to acquire vehicle-side test case data that matches the test requirement description information from a pre-built vehicle-side test case knowledge base, and to acquire vehicle signal constraints that match the test requirement description information from a pre-built vehicle signal knowledge graph. The test case generation module is used to construct prompt words based on the vehicle-side test case data, vehicle signal constraints, and the test requirement description information, input the prompt words into a pre-built large language model, and generate target test cases for the vehicle-side software through the large language model.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images