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

Abstract

The invention discloses a vehicle-mounted software test case generation method and device, equipment and a medium, and relates to the technical field of software test.The method comprises the steps that a demand document and a test point list of vehicle-mounted software are obtained; based on the demand document, the test point list and the first cue word, performing test case generation operation through the first large model, and generating a first-version test case; based on the first-version test case, the demand document, the test point list and the second cue word, analyzing the first-version test case through a second large model to generate an analysis result; and based on the first-version test case, the analysis result and a third prompt word, performing test case modification operation on the first-version test case through a third model, and generating a target test case.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a method, apparatus, device and medium for generating test cases for vehicle-mounted software. Background Technology

[0002] As the automotive industry rapidly evolves towards intelligence and connectivity, the complexity and integration of in-vehicle electronic systems continue to increase, leading to increasingly complex scale and functional logic in in-vehicle software. Simultaneously, the development cycle for vehicle models and software iterations is constantly shortening, placing higher demands on the testing efficiency and quality assurance of in-vehicle software. The traditional method, which relies primarily on test engineers manually writing test cases, is not only inefficient and time-consuming, but its quality also heavily depends on individual experience, making it difficult to guarantee the comprehensiveness and consistency of testing. This has become a bottleneck restricting the high-quality and rapid delivery of in-vehicle software. Therefore, a new method for generating test cases for in-vehicle software is urgently needed to address the aforementioned problems. Summary of the Invention

[0003] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solutions, nor is it intended to determine the scope of protection of the claimed technical solutions.

[0004] Firstly, this application provides a method for generating test cases for in-vehicle software, including: Obtain the requirements document and test point list for the in-vehicle software; Based on the requirements document, the test point list, and the first prompt word, test cases are generated using the first major model to produce the first version of test cases. Based on the initial test cases, the requirements document, the test point list, and the second prompt words, the initial test cases are analyzed using the second major model to generate analysis results. Based on the initial test cases, the analysis results, and the third prompt, the initial test cases are modified using the third major model to generate target test cases.

[0005] In some implementations, the first large model, the second large model, and the third large model are the same large language model; or, at least two of the first large model, the second large model, and the third large model are different large language models.

[0006] In some implementations, before generating the first version of test cases using the first large model based on the requirements document, the test point list, and the first prompt word, the process includes: The requirement document is preprocessed into blocks to generate multiple partial requirement documents; Based on a preset structured format, each of the aforementioned partial requirement documents is converted to generate a target requirement document corresponding to each of the aforementioned partial requirement documents. The preset structured format includes JSON format or Markdown format. Based on the requirements document, the test point list, and the first prompt word, the test case generation operation is performed through the first major model to generate the first version of test cases, including: Based on all the target requirement documents, the test point list, and the first prompt word, test case generation is performed using the first large model to generate the first version of test cases.

[0007] In some implementations, the step of generating initial test cases based on the requirements document, the test point list, and the first prompt word, using a first large model, includes: Based on the first prompt, determine the role definition for test case generation and the test case format specifications; Based on the test case generation role definition, the test case format specification, the requirement document, and the test point list, test case generation is performed through the first large model to generate the first version of test cases.

[0008] In some implementations, the analysis of the initial test cases based on the first version of the test cases, the requirements document, the test point list, and the second prompt words, using a second large model, generates analysis results, including: Based on the second prompt, the definition of the review role and multiple preset review dimensions are determined; Based on the defined review roles, the multiple preset review dimensions, the initial test cases, the requirements document, and the test point list, the second major model is used to perform a quantitative evaluation of the initial test cases, generating quantitative results and the causes of problems. The analysis results are generated based on the quantification results and the causes of the problem.

[0009] In some implementations, the step of modifying the initial test cases based on the first version of the test cases, the analysis results, and the third prompt words, using a third major model, to generate target test cases includes: Based on the analysis results, the identifiers of the test cases to be modified and the corresponding reasons for modification in the first version of the test cases are determined; Based on the third prompt word, determine the role definition and test case modification specifications for test cases; Based on the test case identifier to be modified, the reason for modification, the role definition for test case modification, and the test case modification specifications, the first version of the test case is modified using the third major model to generate the target test case.

[0010] In some implementations, the large language model is a pre-trained language model based on the Transformer architecture.

[0011] Secondly, this application proposes an in-vehicle software test case generation device, comprising: The vehicle requirements acquisition unit is used to acquire the requirements document and test point list for vehicle software. The first version test case generation unit is used to generate the first version of test cases based on the requirements document, the test point list and the first prompt word, through the first major model. The first version test case analysis unit is used to analyze the first version test cases based on the first version test cases, the requirements document, the test point list, and the second prompt words, and generate analysis results through the second major model. The target test case generation unit is used to modify the first version of the test cases based on the initial test cases, the analysis results, and the third prompt words, and generate target test cases by using the third major model.

[0012] Thirdly, an electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program stored in the memory to implement the steps of the vehicle software test case generation method of any one of the first aspects.

[0013] Fourthly, this application also proposes a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the vehicle software test case generation method of any one of the first aspects.

[0014] In summary, this application provides a method for generating test cases for automotive software. By obtaining the requirements document and test point list of the automotive software, and sequentially using a large model to perform test case generation, analysis, and modification operations, a fully automated generation process from original requirements to high-quality test cases is achieved. This method improves the efficiency of test case generation, enabling the rapid production of first-version test cases that conform to specifications. By automatically analyzing the first-version test cases from multiple dimensions and generating analysis results, a basis for subsequent optimization is provided. Finally, based on the analysis results, the large model is driven to complete targeted modifications, effectively ensuring the accuracy and completeness of the output target test cases. The overall process reduces manual intervention while improving the automation level of automotive software testing.

[0015] The method for generating test cases for in-vehicle software proposed in this application, along with other advantages, objectives, and features of this application, will be partly apparent from the following description and partly understood by those skilled in the art through study and practice of this application. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This application provides a schematic flowchart of a method for generating test cases for in-vehicle software. Figure 2 A schematic diagram of the structure of an in-vehicle software test case generation device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an in-vehicle software test case generation device provided in an embodiment of this application. Detailed Implementation

[0017] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0018] Please see Figure 1 This is a schematic diagram of a method for generating test cases for in-vehicle software provided in an embodiment of this application, which may specifically include: S110. Obtain the requirements document and test point list for the vehicle software; For example, in step S110, obtaining the requirements document and test point list for the in-vehicle software is the first step in initiating the automated test case generation process. The requirements document comprehensively describes the various functions, performance indicators, and system constraints that the in-vehicle software needs to implement, providing a functional scope and business logic basis for test case generation; the test point list, based on the requirements analysis, extracts the specific test items that need to be verified, clarifying the core elements and key scenarios of test coverage. These two types of inputs together constitute the goals and boundaries of test case generation, ensuring that the subsequent automated generation process can align with the actual testing needs of the in-vehicle software.

[0019] S120. Based on the requirements document, test point list, and first prompt word, perform test case generation operation through the first major model to generate the first version of test cases; For example, in step S120, based on the acquired requirements document, test point list, and preset first prompt words, the first large model performs a test case generation operation to obtain the first version of test cases. The first prompt words define key generation elements such as the role positioning, skill requirements, task objectives, and test case format specifications for test case generation, guiding the large model to automatically construct an initial test case set covering core functions and scenarios based on structured requirements input and clearly defined test points.

[0020] S130: Based on the initial test cases, requirements document, test point list, and second prompt words, the initial test cases are analyzed using the second major model to generate analysis results. For example, in step S130, based on the generated initial test cases, original requirements document, test point list, and preset second prompt words, an analysis operation is performed on the initial test cases through the second large model. This analysis operation evaluates the test cases in terms of requirement coverage completeness, test point coverage sufficiency, and test case structure standardization, according to the review roles defined by the second prompt words and preset review dimensions, thereby generating analysis results that include quantitative scores and specific problem causes.

[0021] S140. Based on the initial test cases, analysis results, and third prompt words, modify the initial test cases using the third major model to generate target test cases.

[0022] For example, in step S140, based on the generated initial test cases, the analysis results obtained in the preceding steps, and the preset third prompt words, the modification operation of the initial test cases is performed through the third model. This operation, based on the specific content to be modified indicated by the analysis results and its reasons, combined with the modification goals and specifications defined by the third prompt words, specifically corrects and optimizes the problems existing in the initial test cases, thereby generating target test cases that meet the final quality requirements.

[0023] In summary, this application's embodiments construct a complete automated test case generation process by acquiring the requirements document and test point list of the in-vehicle software, and sequentially utilizing a large model to perform test case generation, analysis, and modification operations. This method first rapidly generates initial test cases covering core scenarios based on structured requirement input and targeted prompts, improving the initial efficiency of test case writing. By introducing a multi-dimensional quantitative analysis mechanism, the initial test cases are evaluated, generating analysis results containing specific problem-solving objectives. Finally, based on the analysis results, the large model is used to make targeted corrections to the test cases, effectively improving the accuracy and completeness of the output target test cases. The entire process reduces manual intervention while ensuring the consistency of test case quality, providing an efficient and reliable automated solution for the testing and verification of in-vehicle software under rapid iteration cycles.

[0024] In some instances, the first, second, and third largest models are the same large language model; or, at least two of the first, second, and third largest models are different large language models.

[0025] For example, two typical deployment strategies are used for configuring large model resources during the processes of generating, analyzing, and modifying test cases. The first strategy uses a single large language model instance, loading different prompt word projects to sequentially complete the three sub-tasks with different task objectives and technical requirements: test case generation, analysis and review, and modification and optimization. This approach simplifies the system architecture and unifies model management. The second strategy allows for configuring independent large model instances for each of the three stages: generation, analysis, and modification. These instances can be models with the same basic architecture but fine-tuned for different task data, or models based on completely different architectures or parameter scales. This approach allows for selecting the most suitable model for the specific needs of each stage. For example, a model better suited for logical reasoning can be selected for the analysis stage, a more creative model for the generation stage, and a large model skilled in instruction following and text optimization can be selected for the modification task, thereby optimizing task execution. Both strategies are based on the core capabilities of large language models, achieving high-quality generation of automotive software test cases through task decoupling and specialized division of labor.

[0026] In summary, by adopting the aforementioned large-model configuration scheme, the embodiments of this application can flexibly select the optimal model deployment mode based on the resource constraints and performance requirements of the actual application scenario. When using a single model, it has the advantages of simple deployment and uniform resource overhead; while when using a combination of heterogeneous models, it can fully leverage the performance advantages of different models in specific subtasks. This flexibility ensures the wide applicability of this method under different computing resource conditions and different quality requirements.

[0027] In some instances, before generating the initial test cases based on the requirements document, test point list, and first prompt words using the first major model, the following steps are also included: The requirements document is preprocessed into blocks to generate multiple partial requirements documents; Based on a preset structured format, the format conversion operation is performed on each part of the requirement document to generate a target requirement document corresponding to each part of the requirement document. The preset structured format includes JSON format or Markdown format. Based on the requirements document, test point list, and initial prompt, test cases are generated using the first major model, resulting in the initial version of test cases, including: Based on the complete target requirements document, test point list, and first prompt words, test cases are generated using the first major model to produce the first version of test cases.

[0028] For example, the requirements document is preprocessed into multiple parts, resulting in a segmented requirements document. This preprocessing operation aims to address the technical problem that large language models struggle to process complete requirements documents in one go due to context length limitations. By dividing the lengthy original requirements document into multiple structurally independent but content-complete segments based on functional modules or business logic boundaries, this step ensures that each document segment has a moderate information density, aligning with the single-processing capacity of the large model, while maintaining the inherent coherence of the requirements' business logic.

[0029] The purpose of this format conversion is to transform unstructured natural language requirement descriptions into machine-readable structured data. When JSON format is selected, the hierarchy and relationships between requirement elements are expressed through key-value pairs; when Markdown format is selected, standard syntax elements such as headings, lists, and code blocks are used to define the logical structure of the requirement content. This standardized conversion improves the understanding of requirement documents and the efficiency of information extraction by large models.

[0030] Based on the complete target requirement documents, test point list, and initial prompts, test cases are generated using the first main model, producing the initial version of test cases. In this step, the preprocessed and structured target requirement documents, along with the test point list, serve as the context information for the generation task and are input into the first main model.

[0031] In summary, this application's embodiments, by implementing the aforementioned requirements document preprocessing and structured transformation process, provide high-quality, easily understandable standardized input for generating test cases from the subsequent large model. By improving the structure and logical clarity of the input information, it directly promotes improvements in the completeness of requirements coverage and the accuracy of business logic in the generated test cases.

[0032] In some instances, based on the requirements document, test point list, and initial prompt, test case generation is performed using the first major model to generate the initial version of test cases, including: Based on the first prompt word, determine the role definition for test case generation and the test case format specifications; Based on the role definition, test case format specification, requirements document and test point list generated by the test case generation role, the first version of test cases is generated through the first major model.

[0033] For example, based on the first prompt, the role definition and format specification for test case generation are determined. The first prompt is a pre-designed set of text instructions used to guide the large model in executing the test case generation task. In this step, the first prompt is parsed to extract the key elements regarding the role definition and format specification. The role definition for test case generation clarifies the virtual role that the large model should play when performing the generation task, such as "senior automotive software test engineer." This definition typically includes a detailed description of the skill areas, knowledge background, and task responsibilities required for this role, thereby setting the professional domain and capability boundaries for the large model's response behavior. Simultaneously, the test case format specification parsed from the first prompt provides a structured output template for the generated test cases. This specification clearly defines the components that each test case must include, such as test case identifier, test title, preconditions, test step sequence, expected results, and possible test data, and sets uniform requirements for the expression style, level of detail, and arrangement order of each element, thereby ensuring the structural consistency and standardization of the generated content.

[0034] Based on the test case generation role definition, test case format specification, requirements document, and test point list, the first main model performs test case generation operations to generate the initial version of test cases. In this step, the test case generation role definition and test case format specification determined in the previous steps, along with the complete requirements document and test point list as contextual information, are input into the first main model. Based on its internally pre-trained language understanding and generation capabilities, the first main model, under the constraints of the role definition, simulates the thought process of a test engineer, comprehensively analyzing the functional logic in the requirements document and the verification requirements in the test point list. Following the structure specified in the format specification, the model automatically constructs an initial set of test cases covering the main functional scenarios and test points—the initial version of test cases. This process ensures that the generated test cases not only meet the specific requirements of the in-vehicle software but also that their output format conforms to the preset standardization requirements.

[0035] In summary, this application's embodiments, by implementing the aforementioned test case generation process based on prompt word parsing and large model-driven approaches, achieve automated and standardized construction of the initial test cases. This method, by defining generation roles and output formats, effectively guides the generation behavior of the large model, improving the initial quality of the initial test cases in terms of business logic accuracy and structural standardization. Simultaneously, it reduces reliance on testers manually writing basic test cases, thereby improving the overall efficiency of test preparation.

[0036] In some instances, based on the initial test cases, requirements document, test point list, and second prompt words, a second major model is used to analyze the initial test cases and generate analysis results, including: Based on the second prompt, the definition of the review role and multiple preset review dimensions are determined; Based on the definition of review roles, multiple preset review dimensions, the first version of test cases, requirements documents and test point list, the second major model is used to perform quantitative evaluation of the first version of test cases, generating quantitative results and the cause of problems. Based on the quantitative results and the causes of the problems, analysis results are generated.

[0037] For example, based on the second prompt, the review role definition and multiple preset review dimensions are determined. The second prompt is a pre-defined set of text instructions used to guide the test case analysis process. By parsing the second prompt, the core content regarding the review role definition and review dimensions is extracted. The review role definition clarifies the professional role that the second major model should play when performing analysis tasks, such as a senior test review expert. This definition typically includes a description of the testing experience, review methodology, and responsibilities required for this role, setting a professional benchmark for the model's analysis perspective and evaluation criteria. Multiple preset review dimensions constitute the specific evaluation framework for the analysis operation. These dimensions include, but are not limited to, requirement coverage, test point coverage, and test case structure standardization. Each dimension has a pre-defined weight score in the overall evaluation and detailed deduction criteria. For example, requirement coverage is used to evaluate the coverage of all functional points in the requirement document by the test cases; test point coverage is used to evaluate the coverage of all verification items in the test point list; and test case structure standardization is used to evaluate the format, element completeness, and expression standardization of the test cases. These preset dimensions provide a systematic and measurable indicator system for subsequent quantitative evaluation.

[0038] Based on the defined reviewer roles, multiple preset review dimensions, initial test cases, requirements documents, and a list of test points, a second-large model is used to quantitatively evaluate the initial test cases, generating quantitative results and cause-of-failure analyses. In this step, the defined reviewer roles and multiple preset review dimensions, the initial test cases as the analysis objects, and the requirements documents and test point lists as the evaluation benchmarks are all input into the second-large model. Guided by the defined reviewer roles, the second-large model reviews the initial test cases according to the preset review dimensions and their scoring criteria. This quantitative evaluation outputs two core components: quantitative results, which are the scores for each review dimension and the total score calculated based on weights, objectively reflecting the quality level of the initial test cases in each dimension and overall; and cause-of-failure analyses, which specifically indicate the test case number that caused the deduction and the detailed reason for the deduction, such as indicating that a test case did not cover a specific requirement item or that its step description did not meet the specification requirements. Based on the quantitative results and cause-of-failure analyses, analysis results are generated. The analysis results are the final output of the quantitative evaluation process, integrating the overall and sub-item quality scores reflected in the quantitative results, as well as the specific location and nature of the defects revealed by the cause of the problem. This analysis provides an objective quantitative evaluation of the quality status of the initial test cases.

[0039] In summary, this application's embodiments, by introducing a quantitative evaluation mechanism based on preset dimensions, transform the traditionally subjective experience-dependent test case review process into an objective and repeatable automated analysis workflow. This method not only improves review efficiency but, more importantly, by providing detailed reasons for problems down to each test case number and deduction point, enables subsequent modification and optimization work to pinpoint and correct issues. This effectively ensures the continuous improvement of test case quality and the quality of the final target test case generation.

[0040] In some instances, based on the initial test cases, analysis results, and third-party prompts, the initial test cases are modified using a third-party model to generate target test cases, including: Based on the analysis results, the identifiers of the test cases to be modified and the corresponding reasons for modification were determined in the first version of the test cases; Based on the third prompt word, determine the role definition for test case modification and the test case modification specifications; Based on the test case identifier, reason for modification, role definition for test case modification, and test case modification specifications, the third major model is used to modify the first version of the test cases and generate the target test cases.

[0041] For example, based on the analysis results, the identifiers of test cases to be modified and the corresponding reasons for modification are determined in the initial version of the test cases. This step specifically involves parsing the quantitative evaluation conclusions and problem descriptions included in the analysis results to extract the unique identifiers of the test cases with quality defects, i.e., the test case identifiers to be modified. Simultaneously, the specific defect descriptions that cause each identifier's corresponding test case to be judged as needing modification are identified, i.e., the reasons for modification. These reasons for modification are directly related to the deduction points defined in the previous review dimensions, such as issues like missing requirement coverage, incomplete test procedure descriptions, or discrepancies between expected and actual results.

[0042] Based on the third cue word, the roles for test case modification and the test case modification specifications are determined. This step extracts two key elements guiding the test case modification task through the analysis of the third cue word. The role definition for test case modification clarifies the professional role that the third model should follow when performing modification tasks, as well as the required domain knowledge and modification skills. The test case modification specifications detail the specific output standards and quality requirements that must be followed in the modification operation, including but not limited to the fact that the modified test cases must completely cover all previously missing requirements, correct all identified logical inconsistencies, and ensure that the final output test case structure conforms to the preset completeness and standardization standards.

[0043] Based on the test case identifier, the reason for modification, the role definition for test case modification, and the test case modification specifications, the first version of the test cases is modified using the third major model to generate target test cases. This step inputs all the previously determined modification criteria and requirements into the third major model. Under the constraints of the role definition, and according to the modification specifications, the model, for the specific test cases pointed to by the test case identifier, performs content correction, logic optimization, and structural improvement based on the corresponding modification reasons, outputting a set of target test cases that meet the preset quality standards in terms of requirement coverage, logical correctness, and format compliance.

[0044] In summary, this application's embodiments, by implementing the aforementioned modification mechanism based on analysis results, effectively locate and correct problems in the initial version of test cases. By transforming specific issues output in the early analysis phase into clear modification instructions, the large model is guided to undergo targeted optimization, effectively avoiding omissions or misunderstandings that may occur during traditional manual modifications. This approach not only improves the final quality of test cases but also reduces the reliance on manual intervention in the test case generation process by automating the modification tasks.

[0045] In some instances, large language models are pre-trained language models based on the Transformer architecture.

[0046] For example, this model learns the linguistic patterns and general knowledge contained in massive amounts of text data during its pre-training phase, gaining powerful natural language understanding and generation capabilities, thus providing a technical foundation for generating, analyzing, and modifying test cases. Specifically, the model utilizes its internal Transformer architecture based on a self-attention mechanism to effectively capture long-distance dependencies and complex semantic associations in the input text, including requirements documents, test point lists, prompt words, and the test cases themselves. Through its encoder-decoder structure or decoder-only structure, it achieves understanding of the input information and outputs text sequences. The first major model generates a structured initial version of test cases based on the first prompt word, requirements document, and test point list. The second major model completes the quantitative evaluation of the test cases and generates analysis results based on the second prompt word, the initial version of test cases, requirements document, and test point list. The third major model performs test case modification and optimization based on the third prompt word, the initial version of test cases, and the analysis results, ultimately generating high-quality target test cases. This application of a pre-trained language model based on the Transformer architecture ensures that the entire automated process has the necessary semantic understanding accuracy and logical coherence when processing in-vehicle software testing.

[0047] Please see Figure 2 The diagram below illustrates the structure of an in-vehicle software test case generation device provided in this application embodiment, comprising: The vehicle requirements acquisition unit 21 is used to acquire the requirements document and test point list of the vehicle software. The first version of test case generation unit 22 is used to generate the first version of test cases based on the requirements document, test point list and first prompt words, through the first major model. The first version test case analysis unit 23 is used to analyze the first version test cases based on the first version test cases, requirements document, test point list and second prompt words, and generate analysis results through the second major model; The target test case generation unit 24 is used to modify the first version of the test cases based on the initial test cases, analysis results, and third prompt words, and generate target test cases through the third major model.

[0048] Please see Figure 3 This application also provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements the steps of the vehicle software test case generation method.

[0049] Since the electronic device described in this embodiment is the device used to implement the vehicle software test case generation device in the embodiment of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in the embodiment of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application is within the scope of protection of this application.

[0050] In practice, when the computer program 311 is executed by the processor, it can implement any of the embodiments corresponding to the first aspect.

[0051] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0052] Those skilled in the art will understand that embodiments of this application can provide methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media containing computer-readable program code.

[0053] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0054] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0055] These computer program instructions can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0056] This application also provides a computer program product, which includes computer software instructions that, when executed on a processing device, cause the processing device to perform... Figure 1 The flowchart of a method for generating test cases for in-vehicle software in a corresponding embodiment.

[0057] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any usable medium that a computer can store or a data storage device such as a server or data center that integrates one or more usable media. The usable medium may be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0058] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0059] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Furthermore, the mutual couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0061] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in the form of hardware and / or software functional units.

[0062] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, magnetic disks, or optical disks.

[0063] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0064] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications that fall outside the scope of this specification.

[0065] Obviously, those skilled in the art can make various modifications to this specification without departing from its spirit and scope. Therefore, this specification also intends to include any modifications that fall within the scope of the claims and their equivalents.

Claims

1. A method for generating test cases for in-vehicle software, characterized in that, include: Obtain the requirements document and test point list for the in-vehicle software; Based on the requirements document, the test point list, and the first prompt word, test cases are generated using the first major model to produce the first version of test cases. Based on the initial test cases, the requirements document, the test point list, and the second prompt words, the initial test cases are analyzed using the second major model to generate analysis results. Based on the initial test cases, the analysis results, and the third prompt, the initial test cases are modified using the third major model to generate target test cases.

2. The method according to claim 1, characterized in that, The first large model, the second large model, and the third large model are the same large language model; or, at least two of the first large model, the second large model, and the third large model are different large language models.

3. The method according to claim 1, characterized in that, Before generating the first version of test cases based on the requirements document, the test point list, and the first prompt word using the first large model, the process also includes: The requirement document is preprocessed into blocks to generate multiple partial requirement documents; Based on a preset structured format, each of the aforementioned partial requirement documents is converted to generate a target requirement document corresponding to each of the aforementioned partial requirement documents. The preset structured format includes JSON format or Markdown format. Based on the requirements document, the test point list, and the first prompt word, the test case generation operation is performed through the first major model to generate the first version of test cases, including: Based on all the target requirement documents, the test point list, and the first prompt word, test case generation is performed using the first large model to generate the first version of test cases.

4. The method according to claim 1, characterized in that, Based on the requirements document, the test point list, and the first prompt word, the test case generation operation is performed through the first major model to generate the first version of test cases, including: Based on the first prompt, determine the role definition for test case generation and the test case format specifications; Based on the test case generation role definition, the test case format specification, the requirement document, and the test point list, test case generation is performed through the first large model to generate the first version of test cases.

5. The method according to claim 1, characterized in that, Based on the initial test cases, the requirements document, the test point list, and the second prompt words, the second major model is used to analyze the initial test cases and generate analysis results, including: Based on the second prompt, the definition of the review role and multiple preset review dimensions are determined; Based on the defined review roles, the multiple preset review dimensions, the initial test cases, the requirements document, and the test point list, the second major model is used to perform a quantitative evaluation of the initial test cases, generating quantitative results and the causes of problems. The analysis results are generated based on the quantification results and the causes of the problem.

6. The method according to claim 1, characterized in that, Based on the initial test cases, the analysis results, and the third prompt word, the third major model is used to modify the initial test cases and generate target test cases, including: Based on the analysis results, the identifiers of the test cases to be modified and the corresponding reasons for modification in the first version of the test cases are determined; Based on the third prompt word, determine the role definition and test case modification specifications for test cases; Based on the test case identifier to be modified, the reason for modification, the role definition for test case modification, and the test case modification specifications, the first version of the test case is modified using the third major model to generate the target test case.

7. The method according to claim 2, characterized in that, The large language model is a pre-trained language model based on the Transformer architecture.

8. A device for generating test cases for vehicle-mounted software, characterized in that, include: The vehicle requirements acquisition unit is used to acquire the requirements document and test point list for vehicle software. The first version test case generation unit is used to generate the first version of test cases based on the requirements document, the test point list and the first prompt word, through the first major model. The first version test case analysis unit is used to analyze the first version test cases based on the first version test cases, the requirements document, the test point list, and the second prompt words, and generate analysis results through the second major model. The target test case generation unit is used to modify the first version of the test cases based on the initial test cases, the analysis results, and the third prompt words, and generate target test cases by using the third major model.

9. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program stored in the memory, implements the steps of the vehicle software test case generation method as described in 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 the processor, it implements the steps of the vehicle software test case generation method as described in any one of claims 1 to 7.

Images