Test code generation method, device and equipment and readable storage medium

Abstract

The embodiment of the invention relates to a test code generation method, device and equipment and a readable storage medium, test codes are iteratively generated through an LLM model, coverage rate improvement is automatically verified, a compilation failure rollback mechanism and environment adaptation are combined, automatic closed-loop control of test code generation and coverage rate improvement is achieved, and the test code generation efficiency is improved. And the manual writing and debugging cost is effectively reduced. And the generated test code is subjected to multiple rounds of compilation verification, so that the grammar correctness and the execution feasibility are ensured. The generation direction is continuously optimized through a dynamic feedback mechanism, and the coverage range of unit testing on target codes is systematically improved. And finally, automatically terminating the process when a preset quality index is reached, and outputting an effective test code set which is fully verified.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of automotive electronics, and specifically to a test code generation method, device, equipment and readable storage medium. BACKGROUND

[0002] In the software project development process, unit testing is a key link to ensure code quality and reliability. Traditionally, developers need to manually write corresponding unit test code for each piece of source code. This process not only requires a deep understanding of business logic and code structure, but also needs to construct effective test cases, simulate dependent environments, execute tests and generate test reports, consuming a large amount of human and time resources. Especially in modern agile development and continuous integration processes, the cost of writing and maintaining unit tests is significant, which becomes an important factor affecting project progress.

[0003] In actual unit test development, the phenomenon of slow or even stagnant test coverage improvement often occurs, that is, the coverage percentage does not increase in proportion to the human input. This contradiction is due to high code complexity, numerous conditional branches, and difficulty in fully covering abnormal scenarios, resulting in low test efficiency and diminishing marginal benefits. In addition, manually written test cases often have duplication or omissions, making it difficult to achieve high coverage requirements systematically, thereby limiting the further improvement of software quality.

[0004] In order to solve the above problems, some automatic test generation tools and code generation schemes based on large language models (LLM) have appeared in the industry, trying to alleviate the burden of manual test writing, but these methods still have significant limitations. In particular, current large language models are prone to "hallucinations", generating test code with logical errors, syntax errors or invalid context, making it impossible to pass compilation or truly cover the target code segment at runtime, instead introducing additional debugging costs. At the same time, due to the uncertainty of the generated results, developers often need to perform multiple rounds of prompts, corrections and verifications, which consumes a large amount of computing resources and token quantity in the interactive process, but still does not fundamentally solve the problem of coverage improvement, instead forming a new contradiction between cost and effect.

[0005] Therefore, the industry urgently needs an intelligent method and system that can efficiently and accurately generate unit test code and effectively improve coverage, to overcome the shortcomings of existing technologies. SUMMARY

[0006] In view of the above problems, the present application provides a test code generation method, device, equipment and readable storage medium, which is used to solve the problem that the current large language model in the prior art is easy to generate test code with logical errors, syntax errors or invalid context, so that it cannot pass the compilation, or cannot truly cover the target code segment at runtime, but introduces additional debugging costs. At the same time, due to the uncertainty of the generation result, multiple rounds of prompting, correction and verification consume a large amount of computing resources and token quantity.

[0007] According to one aspect of the present application, a test code generation method is provided, the method comprising: obtaining a source code file, a test suite and a coverage report, and generating unit test code through a preset LLM model according to the source code file, the test suite and the coverage report; obtaining a test instruction, compiling the unit test code according to the test instruction, and running unit testing in a preset environment after the unit test code is compiled, to generate a coverage report; parsing the coverage report to obtain current coverage data, and comparing the current coverage data with the coverage data in the previously saved coverage report to determine whether the current coverage data is improved; if yes, saving the current test code and the coverage report, otherwise, regenerating and compiling the unit test code; when the coverage data reaches a set threshold or the LLM model reaches a maximum access number, stopping the test and generating target test code and target coverage report.

[0008] In some optional embodiments, generating unit test code through a preset LLM model according to the source code file, the test suite and the coverage report specifically comprises: parsing the source code file, the test suite and the coverage report, and preparing and enhancing the context of the LLM model; constructing a structured prompt of the LLM model according to the context information, inputting the structured prompt into an LLM model API interface, and generating unit test code.

[0009] In some optional embodiments, when the unit test code is not compiled in the step of compiling the unit test code according to the test instruction, the code is rolled back, the unit test code is regenerated through the LLM model, and the unit test code is recompiled.

[0010] In some optional embodiments, the preset environment is a qemu virtual environment, a Linux environment or a real vehicle environment.

[0011] In some optional embodiments, the unit test code and the source code file are tested according to a preset mapping relationship table, a coverage report is generated, and line coverage or branch coverage is obtained according to the coverage report.

[0012] In some optional embodiments, when the current coverage data is improved compared with the previously saved coverage data, the current test data and the coverage report are saved, and the current test data at least includes test cases and test code.

[0013] In some optional embodiments, when the current coverage data is not improved compared with the previously saved coverage data, the test code is rolled back, error information is recorded, the unit test code is generated again as a prompt word prompt to the LLM model, and the unit test code is compiled.

[0014] According to another aspect of the embodiments of the present application, a test code generation device is provided, and the device comprises: a test code generation module configured to obtain a source code file, a test suite and a coverage report, and generate unit test code through a preset LLM model according to the source code file, the test suite and the coverage report; a compilation and running module configured to obtain a test instruction, compile the unit test code according to the test instruction, and run unit testing in a preset environment after the unit test code is compiled, to generate a coverage report; a promotion judgment module configured to analyze the coverage report to obtain current coverage data, and compare the current coverage data with coverage data in a previously saved coverage report to determine whether the current coverage data is improved; if yes, the current test code and the coverage report are saved, otherwise, the unit test code is regenerated and compiled; and a target test code generation module configured to stop testing and generate target test code and a target coverage report when the coverage data reaches a set threshold or the LLM model reaches a maximum access number.

[0015] According to another aspect of the embodiments of the present application, a test code generation device is provided, and the device comprises: a processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete communication with each other through the communication bus; The memory is configured to store at least one executable instruction, and the executable instruction causes the processor to perform the operations of the test code generation method as described above.

[0016] According to a further aspect of the embodiments of the present application, a readable storage medium is provided, wherein at least one executable instruction is stored in the storage medium, and the executable instruction, when executed on the test code generation device as described above, causes the test code generation device to perform the operations of the test code generation method as described above.

[0017] The test code generation method, device, equipment and readable storage medium provided by the present application have the beneficial effect that: the present application iteratively generates test code through an LLM model and automatically verifies coverage improvement, in combination with a compilation failure rollback mechanism and environment adaptation, the present application realizes automatic closed-loop control of test code generation and coverage improvement, effectively reducing the cost of manual writing and debugging. The generated test code is verified through multiple rounds of compilation, ensuring its syntax correctness and execution feasibility. The generation direction is continuously optimized through a dynamic feedback mechanism, systematically improving the coverage range of unit testing on the target code. Finally, the process is automatically terminated when the preset quality index is reached, and an effective test code set that has been fully verified is output.

[0018] The above description is only a summary of the technical solutions of the embodiments of the present application, in order to more clearly understand the technical means of the embodiments of the present application, the embodiments can be implemented in accordance with the content of the description, and in order to make the above and other purposes, features and advantages of the embodiments of the present application more obvious and easy to understand, the specific embodiments of the present application are described below. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings are only used to illustrate the embodiments and are not considered as limiting the present application. Moreover, the same reference signs are used to represent the same parts throughout the drawings. In the drawings: Figure 1 A first flowchart of the test code generation method of embodiment 1 provided by the present application is shown; Figure 2 A second flowchart of the test code generation method of embodiment 1 provided by the present application is shown; Figure 3 A flowchart of generating unit test code according to the source code file, test suite and coverage report through a preset LLM model provided by the present application is shown; Figure 4 A structure diagram of the test code generation device of embodiment 2 provided by the present application is shown; Figure 5 A structure diagram of the test code generation device of embodiment 3 provided by the present application is shown. DETAILED DESCRIPTION

[0020] Exemplary embodiments of the present application will be described in greater detail below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it is to be understood that the present application can be embodied in various forms without being limited by the embodiments set forth herein.

[0021] Embodiment 1: Figure 1 An embodiment of a test code generation method of the present application is shown, which is used to solve the problem that the current large language model in the prior art is prone to generate test code with logical errors, syntax errors or invalid context, which cannot pass the compilation, or cannot truly cover the target code segment at runtime, but introduces additional debugging costs. At the same time, due to the uncertainty of the generation result, multiple rounds of prompting, correction and verification consume a large amount of computing resources and token quantity, etc. The method specifically includes: 110, obtaining a source code file, a test suite and a coverage report, and generating unit test code through a preset LLM model according to the source code file, the test suite and the coverage report; in step 110, the source code file refers to the original program code file to be tested, which can be implemented by using engineering files written in C, C++, Java or Python as the basic input for generating test code. The test suite refers to a file set containing test framework configuration and dependent items, which can be the test data saved in the previous round, and can be implemented by using JUnit, pytest or GoogleTest framework configuration file to define the test running environment and constraint conditions. The coverage report refers to a document reflecting the code execution path coverage, which can be implemented by using XML or HTML format files generated by gcov, lcov or JaCoCo tools to quantify the test effect. The LLM model receives the source code file, the test suite and the historical coverage report as input to generate unit test code meeting the current demand. According to the source code file, the test suite and the coverage report, unit test code is generated through a preset LLM model, specifically including: parsing the source code file, the test suite and the coverage report, and preparing and enhancing the context of the LLM model; constructing the structured prompt of the LLM model according to the context information, inputting the structured prompt into the LLM model API interface to generate the unit test code.

[0022] 120, obtain a test instruction, compile the unit test code according to the test instruction, and run the unit test in a preset environment after the unit test code is compiled, and generate a coverage report; in step 120, the preset environment refers to an isolated execution space for running the unit test, which can be implemented by using a qemu virtual environment or a Linux operating system environment to ensure controllability and repeatability of the test process. The newly generated code is executed in the isolated environment after being verified by compilation and coverage data is generated and saved in the coverage report. Specifically, the unit test code and the source code file can be tested according to a preset mapping relationship table to generate a coverage report, and line coverage or branch coverage can be obtained according to the coverage report.

[0023] 130, parse the coverage report to obtain current coverage data, and compare the current coverage data with coverage data in a previously saved coverage report to determine whether the current coverage data is improved; if yes, save the current test data and the coverage report, otherwise, regenerate and compile the unit test code; in step 130, the system automatically parses the coverage value in the latest report and compares it with the previous result. If the value is improved, the current test data is retained, otherwise, the code regeneration process is triggered. When the current coverage data is improved compared with the coverage data saved last time, the current test data and the coverage report are saved, and the current test data at least includes test cases, test code, test process number and function code corresponding to the function to be tested. When the current coverage data is not improved compared with the coverage data saved last time, the test code is rolled back, error information is recorded, the unit test code is regenerated by the LLM model, and the unit test code is compiled.

[0024] 140, when the coverage data reaches a set threshold or the LLM model reaches a maximum access number, stop testing and generate target test code and target coverage report. In step 140, the set threshold refers to a predefined coverage target value, which can be set in the form of a percentage value as one of the iteration termination conditions. The maximum access number of the LLM model can also be limited to obtain the optimal target test code. Steps 110-130 are executed in a loop until the coverage meets the standard or the preset model call number limit is reached, and the verified target test code is finally output.

[0025] Referring to Figure 2Compared with the prior art, the prior scheme only generates test code in one direction and lacks a feedback optimization mechanism, the scheme constructs a closed-loop iterative system, and uses the coverage value as a key feedback parameter to guide the code generation direction. The traditional method needs manual intervention to analyze the failure reason and adjust the prompt words, the scheme significantly reduces the frequency of manual intervention through the automatic numerical comparison and regeneration mechanism. Compared with the scheme of directly using a large language model to generate test code, the method significantly improves the usability and coverage contribution of the generated code through multiple rounds of verification and screening.

[0026] Through the above technical solutions, the application realizes automatic closed-loop control of test code generation and coverage improvement, effectively reducing the cost of manual writing and debugging. The generated test code is verified through multiple rounds of compilation to ensure its syntax correctness and execution feasibility. The generation direction is continuously optimized through a dynamic feedback mechanism, systematically improving the coverage of unit testing on the target code. Finally, the process is automatically terminated when the preset quality indicators are reached, and a set of effective test codes that have been fully verified is output.

[0027] In step 110, unit test code is generated according to the source code file, test suite and coverage report through a preset LLM model, referring to Figure 2 , specifically including: 210, parsing the source code file, test suite and coverage report, and preparing and enhancing the context of the LLM model; 220, constructing a structured prompt for the LLM model according to the context information, inputting the structured prompt into the LLM model API interface to generate unit test code.

[0028] In steps 210-220, parsing the source code file, test suite and coverage report means extracting function definitions, class structures and code logic from the source code file, obtaining existing test cases and assertion rules from the test suite, and identifying uncovered code paths from the coverage report. Specifically, static code analysis tools or regular expression matching methods can be used to provide the input data basis required for the LLM model to generate test code. The context preparation and enhancement of the LLM model means converting the parsed code structure, test cases and coverage data into natural language descriptions or structured data, and supplementing information by adding code comments, exception scenario examples or boundary condition descriptions. Specifically, template filling or semantic association algorithms can be used to improve the depth of the model's understanding of the code context. Structured prompts mean integrating code context, test objectives and format requirements into guided text containing input constraints, output examples and error handling instructions based on pre-set test code generation rules. Specifically, JSON format or Markdown syntax can be used to organize, reducing the randomness of the model's generated results. LLM model API interface means calling the programming interface of the large language model service to receive structured prompts and return generated unit test code. Specifically, HTTP protocol or SDK toolkit can be used, such as OpenAI API or locally deployed model services for interaction.

[0029] Specifically, after static parsing, the source code file extracts class methods, input parameters and return value types, the assertion rules in the test suite are converted into equivalent class division descriptions, and the uncovered branches in the coverage report are marked as test targets. In the context preparation process, code elements and test requirements are converted into model-understandable prompt fragments through natural language templates, such as associating function parameter types and boundary value conditions with test case generation rules. Structured prompts further integrate code fragments, test objectives and format specifications to form a complete instruction set containing input and output examples, such as requiring the model to generate test class code that conforms to the JUnit framework. After submitting the prompts through the API interface, the model generates unit test code containing test cases and assertion logic based on the code context and test requirements.

[0030] Compared with the prior art, the traditional method directly inputs source code fragments into the model to generate test code, which lacks systematic integration of code structure, test suite and coverage data, resulting in a disconnection between the generated results and the target code logic. This scheme converts scattered code information and test requirements into a form that the model can accurately process through context preparation and structured prompts, effectively avoiding the generation of invalid or syntax error test code. For example, in the prior art, the model may miss the corresponding test case due to the failure to identify the code branch condition, while this scheme clearly identifies the uncovered paths through the analysis of the coverage report, so that the generated test code covers the target branch.

[0031] Through the technical solution, the application solves the problems of logical errors and low coverage caused by insufficient context information when the LLM model generates test code. Through structured prompts and context enhancement, the model can accurately understand the input-output constraints and uncovered paths of the code to be tested, and generate unit test code that meets the compilation requirements and effectively improves the coverage. This reduces repeated debugging and model repeated calls caused by invalid test code, reduces the consumption of computing resources and time cost, and improves the efficiency of automatic generation of unit tests.

[0032] In step 120, the application proposes that when the unit test code fails to compile according to the test instructions, the unit test code is regenerated by the LLM model, and the unit test code is compiled.

[0033] In this embodiment, the unit test code compilation failure means that the generated code has syntax errors, missing dependencies or logical conflicts, which cannot pass the static check of the compiler or interpreter. Specifically, it can be judged by the error log returned by the compiler or the status code output by the build tool. Regenerating the unit test code by the LLM model means that the code that fails to compile and its error information are input, and a revised code version is generated by calling the API interface of the LLM model. Specifically, the error log parsing module can extract key error information, and merge it with the original context to reconstruct the prompt word.

[0034] Specifically, when the compilation process is interrupted due to code errors, the error information is captured and fed back to the LLM model. The LLM model adjusts the generation strategy based on the error information, such as correcting syntax errors, supplementing missing dependencies or restructuring logical branches, so as to output new unit test code. The newly generated code enters the compilation process again, and if there are still errors, the above process is repeated until the compilation is successful or the preset number of retries is reached. This process realizes error repair through an automatic closed-loop mechanism, avoiding the efficiency loss caused by manual intervention.

[0035] Compared with the prior art, the existing scheme usually needs to manually analyze error logs and manually adjust prompts when the LLM generates test code that fails to compile, resulting in an increase in iteration period and resource consumption. The present scheme automatically captures and feeds back the compilation errors to the LLM model, so that the model can dynamically optimize the generated content, significantly reducing the frequency of manual intervention, while improving the response speed of error repair.

[0036] By the technical scheme, the application solves the problem of process stagnation caused by the compilation error of the test code generated by the traditional LLM, and realizes automatic regeneration and verification in the compilation failure scenario. The scheme can effectively reduce the test code debugging cost and shorten the test development cycle, and at the same time, the usability of the generated code is improved through continuous iteration optimization.

[0037] In addition, the preset environment in step 120 can be a qemu virtual environment or a Linux environment or a real vehicle environment. In the embodiment, the qemu virtual environment refers to a virtualization test environment based on an open source simulator, which can specifically be implemented by using a dynamic binary translation technology to simulate different processor architectures and hardware devices, and is used to verify the compatibility of the unit test code in the cross-platform scenario. The Linux environment refers to a native running environment based on the Linux operating system, which can specifically be implemented by using a physical server or a containerized deployment method, and is used to execute unit tests related to system calls and kernel modules. The real vehicle environment refers to a test environment loaded with real vehicle hardware and embedded systems, which can specifically be implemented by using a vehicle controller or hardware in a vehicle system, and is used to verify the running effect of the unit test code in the real vehicle electronic control unit.

[0038] Specifically, after the unit test code is compiled, the corresponding preset environment is selected according to the type of the system under test to perform the test. For example, for the test code of the vehicle software module, the qemu virtual environment is preferred for rapid iteration verification; when the test coverage rate reaches the intermediate threshold, further hardware-level verification is performed in the real vehicle environment. For the code module related to the operating system underlying interface, the Linux environment is switched to perform the system call test. Therefore, a complementary relationship is formed between different environments, ensuring that the test coverage gradually transitions from the simulation environment to the real hardware environment. It should be noted that the embodiment can use the virtual environment for testing in priority, which can reduce the debugging time of environment building and unstable connection.

[0039] Compared with the prior art, the traditional unit test environment usually only uses a single simulation platform or physical device, which cannot adapt to the test requirements of cross-platform code, and it is difficult to reproduce the hardware interaction scene in the real vehicle environment. The application uses the dynamic switching mechanism of the preset environment, which not only retains the efficiency of virtualization testing, but also verifies the real execution effect of the test code through the real vehicle environment, solving the problem of insufficient environment simulation in embedded system testing.

[0040] By the technical solution, the optimal test environment can be automatically matched according to the characteristics of the measured code, and test omission or misjudgment caused by environment difference can be effectively avoided. For example, hardware timing problems that cannot be reproduced in virtualization testing can be captured in a real vehicle environment, and the correctness of system resource scheduling can be verified in a Linux environment, thereby improving the reliability and scene coverage integrity of the test result.

[0041] In step 120, the application generates a coverage report by testing the unit test code and the source code file according to the preset mapping relationship table, and obtains line coverage or branch coverage according to the coverage report.

[0042] In the embodiment, the mapping relationship table refers to a structured data table storing the correspondence between the line number of the source code file and the execution path of the unit test code, and can be implemented by using a hash table or a database table structure, and is used to establish a dynamic association relationship between the source code and the test code. The line coverage comparison refers to checking whether the unit test code has executed each executable code line of the source code file, and can be implemented by using a patching technology or a static analysis tool, and is used to identify the code lines that are not covered. The branch coverage comparison refers to verifying whether the unit test code covers the branch paths of all conditional judgment statements in the source code file, and can be implemented by using a control flow analysis tool or a dynamic tracking technology, and is used to find the conditional branches that are not covered.

[0043] Specifically, in the running process of the unit test code, the test code execution path is matched with the line number and branch node of the source code file through the preset mapping relationship table. For example, when the test code executes to a specific function of the source code file, the mapping relationship table records the code lines called in the function and the conditional branches triggered. By comparing the actual execution path of the test code with the complete structure of the source code file, the line coverage value and the branch coverage value can be counted, and then a coverage report containing specific uncovered areas is generated. Therefore, the system can accurately identify the code segments that are not covered, and provide a clear optimization direction for subsequent test code generation. In a specific example, by accurately identifying the code segments that are not covered through the embodiment, the test code and the coverage report can be continuously iterated and updated to obtain the final target test code and target coverage report.

[0044] Compared with the prior art, the traditional test coverage analysis usually only relies on the coverage data generated by the compiler, and lacks structured management of the association relationship between the source code and the test code. The test generation scheme based on LLM in the prior art often directly uses the original coverage report, and cannot effectively locate the specific code area that needs to be enhanced. The present scheme can systematically identify the code lines and branch nodes that are not covered by establishing a mapping relationship table and implementing double coverage comparison, thereby guiding the LLM model to generate supplementary test cases.

[0045] By the technical solution, the application solves the problems of low coverage rate improvement efficiency and unclear test generation direction in the traditional method. Through the structured mapping and double coverage analysis, the code region that needs to be enhanced in coverage can be accurately identified, and repeated or invalid test code is avoided, thereby reducing the number of invalid calls of the LLM model and improving the resource utilization rate of the test code generation process.

[0046] In step 130, the application proposes to save the current test data and coverage report when the current coverage value is improved compared with the previously saved coverage value, and the current test data at least includes test cases and test code, wherein the test cases include a function flowchart to be tested and a corresponding serial number.

[0047] In the embodiment, the test case refers to a set of input data for verifying the logical correctness of the function to be tested, which can be implemented by using boundary values, abnormal values or regular input data combinations to trigger different execution paths of the function to be tested. The test code refers to the unit test program generated by the large language model, which can be implemented by calling the function to be tested and asserting the expected output to execute the test logic in a preset environment. The test flow serial number refers to a serial number for uniquely identifying the test iteration process, and the flow serial number is the flowchart serial number of the function to be tested, which indicates which paths of the source code function have been tested. The function code number is the correspondence between the test case ID of the test case and the function ID of the function to be tested in the DD detailed document, which is used for traceability.

[0048] Specifically, in the test round of coverage rate improvement, the test case, test code, test flow serial number and function code are stored as structured data. The test case serial number [testcaseID] is used as an index key value to bind the test input, generated code and coverage report in the same iteration period. When subsequent tests need to roll back or reuse historical data, the test case set corresponding to the function to be tested is quickly located through the test case serial number, and the historical test code version is called in combination with the test flow serial number, so as to avoid repeated generation of invalid test cases. For example, when the branch coverage rate reaches a local optimum, the system automatically saves the current test data set as a benchmark input for the next test, thereby forming an incremental optimization mechanism. It should be noted that the test flow serial number can be obtained by drawing the flowchart of the function to be tested and plantUML, and the test flow serial number of the test case is the test flow serial number. The function code is obtained by querying the corresponding function code in the DD according to the function name to be tested. The test case serial number, test code, test flow serial number and function code are all saved to the sheet table corresponding to the UTS test case file.

[0049] Compared with the prior art, the conventional test generation tool does not establish a version management mechanism for test data when coverage is improved, so that effective test cases cannot be reused. The scheme realizes the traceability of test data by structuring the storage of test process numbers and function codes, reduces the probability of similar test codes being repeatedly generated by a large language model, and reduces the consumption of computing resources.

[0050] Through the above technical solution, the present application solves the problem of repeated generation caused by discrete storage of test data, establishes an association between test processes and function codes, ensures that effective test cases are continuously accumulated and reused, thereby improving the accuracy of test code generation by a large language model and reducing the number of iterations required to reach the target coverage.

[0051] In step 130, the present application proposes that when the current coverage value and the coverage value saved last time do not improve, the test code is rolled back, the error information is recorded, the unit test code is regenerated by the LLM model generation unit, and the unit test code is compiled.

[0052] In this embodiment, rolling back the test code means restoring the currently generated test code to the previous effective version. Specifically, a version control system can be used to record snapshots of test code generated each time, and when it is detected that the coverage has not improved, a version rollback mechanism is automatically triggered to avoid the cumulative impact of invalid code on subsequent iterations. Recording error information means marking problems in the test code that fails to compile or does not meet the coverage. Specifically, a log system can be used to capture compilation error information, coverage analysis results and model generation parameters to form a structured error dataset for optimizing subsequent generation strategies. Regenerating unit test code means adjusting the model input parameters based on the error information and then calling the LLM to generate test code. Specifically, error logs and coverage data can be injected into the model prompt to guide the model to correct the code logic or supplement test cases.

[0053] Specifically, when the system detects that the coverage value is not greater than the last coverage value, the rollback mechanism is automatically triggered to restore the test code to the last effective state, and the error code, compilation failure log and coverage analysis result generated currently are stored in the error database. Then, the system adjusts the input parameters of the LLM model based on the error dataset, for example, adds emphasis annotations to the uncovered code segments or supplements boundary condition descriptions in the structured prompt, regenerates the test code and performs compilation verification. This process forms a closed-loop optimization mechanism that gradually approaches the target coverage through iterative generation and error correction.

[0054] Compared with the prior art, the traditional method often continuously generates new test codes when the coverage rate is stagnant, resulting in invalid resource consumption, while the present scheme actively interrupts the inefficient generation path through a dynamic rollback and error information feedback mechanism, and uses error data to direct optimization model output. The prior art lacks systematic processing of failed generation cases, and the present scheme significantly improves the effectiveness of LLM generated code by establishing an association between error logs and model prompts.

[0055] Through the above technical solution, the present application effectively solves the problem of coverage rate stagnation caused by model generation errors in the test code generation process, avoids invalid code accumulation through automatic rollback, optimizes the model generation strategy using error information, and reduces the number of repeated generations, thereby ensuring continuous improvement of test coverage rate while reducing computational resource consumption.

[0056] Embodiment 2: Figure 4 An embodiment of a test code generation device of the present application is shown, which is used to execute a test code generation method of embodiment 1. The test code generation device 400 includes a test code generation module 410, a compilation and running module 420, an improvement judgment module 430, and a target test code generation module 440.

[0057] The test code generation module is used to execute step 110 in embodiment 1, specifically including: the source code file refers to the original program code file to be tested, which can be implemented by using engineering files written in C, C++, Java or Python as the basic input for generating test codes. The test suite refers to a file collection containing test framework configuration and dependencies. The test suite can be the test data saved in the previous time, which can be implemented by using JUnit, pytest or GoogleTest framework configuration files to define the test running environment and constraint conditions. The coverage report refers to a document reflecting the code execution path coverage, which can be implemented by using XML or HTML format files generated by gcov, lcov or JaCoCo tools to quantify the test effect. The LLM model receives the source code file, test suite and historical coverage report as input to generate unit test codes meeting the current needs. According to the source code file, test suite and coverage report, unit test codes are generated through a preset LLM model, specifically including: parsing the source code file, test suite and coverage report, and preparing and enhancing the context of the LLM model; constructing the structured prompt of the LLM model according to the context information, inputting the structured prompt into the LLM model API interface to generate unit test codes.

[0058] The compiling running module is configured to execute step 110 in Embodiment 1, and specifically includes that the preset environment refers to an isolated execution space for running the unit test, and specifically can be implemented by using a qemu virtual environment or a Linux operating system environment to ensure controllability and repeatability of the test process. The newly generated code is executed in the isolated environment after being verified by compiling, and coverage data is generated and saved in a coverage report. Specifically, the unit test code and the source code file can be tested according to a preset mapping relationship table to generate a coverage report, and line coverage or branch coverage can be obtained according to the coverage report.

[0059] The promotion judgment module is configured to execute step 110 in Embodiment 1, and specifically includes that the system automatically analyzes the coverage value in the latest report and compares it with the previous result. If the value is improved, the current test data is retained, otherwise the code regeneration process is triggered. When the current coverage data is improved compared with the previously saved coverage data, the current test data and the coverage report are saved, and the current test data at least includes the test case and the test code. When the current coverage data is not improved compared with the previously saved coverage data, the test code is rolled back, error information is recorded, the unit test code is regenerated by using the LLM model, and the unit test code is compiled.

[0060] The target test code generation module is configured to execute step 110 in Embodiment 1, and specifically includes that the threshold value refers to a predefined coverage target value, which can be set in the form of a percentage value as one of the iteration termination conditions. The maximum access number of the LLM model can also be limited to obtain the optimal target test code. Steps 110-130 are executed in a loop until the coverage meets the requirement or the preset model call number limit is reached, and finally the verified target test code is output.

[0061] Embodiment 3 Figure 5 An embodiment of a test code generation device of the present application is shown in a structural schematic diagram, and the specific embodiments of the present application do not limit the specific implementation of the test code generation device.

[0062] As shown in Figure 5 , the test code generation device can include a processor, a communications interface, a memory, and a communications bus.

[0063] The processor 510, the communication interface 540, and the memory 520 can communicate with each other through the communication bus 530. The communication interface is configured to communicate with other devices such as a client or another server. The processor is configured to execute the program 550, and specifically can execute the related steps in the above-described vehicle key storage method embodiments.

[0064] Specifically, the program can include program code including computer-executable instructions.

[0065] The processor can be a central processing unit (CPU) or an application-specific integrated circuit (ASIC) or one or more integrated circuits configured to implement embodiments of the present application. The one or more processors of the test code generation device can be the same type of processor, such as one or more CPUs; or different types of processors, such as one or more CPUs and one or more ASICs.

[0066] The memory is configured to store the program. The memory can include a high-speed RAM memory and can also include a non-volatile memory such as at least one disk memory.

[0067] The program can specifically be invoked by the processor to cause the test code generation device to perform Figure 1 steps 110-130.

[0068] Embodiment 4: The embodiments of the present application provide a readable storage medium, and the storage medium stores at least one executable instruction, which, when executed on a test code generation device, causes the test code generation device to perform the test code generation method of embodiment 1.

[0069] The executable instruction can specifically be used to cause the test code generation device to perform the following operations: 110, obtaining a source code file, a test suite, and a coverage report, and generating unit test code according to the source code file, the test suite, and the coverage report through a preset LLM model; 120, obtaining a test instruction, compiling the unit test code according to the test instruction, and running the unit test in a preset environment after the unit test code is compiled, to generate a coverage report; 130, parsing the coverage report to obtain current coverage data, and comparing the current coverage data with coverage data in a previously saved coverage report to determine whether the current coverage data is improved; if yes, saving the current test data and the coverage report, otherwise, regenerating and compiling the unit test code; 140, when the coverage data reaches a set threshold or the LLM model reaches a maximum number of accesses, stop the test and generate the target test code and target coverage report.

[0070] The application discards the traditional instruction mode, uses the streamlit mode, integrates the Agent application, writes the simple UI, and displays in the html mode; realizes the local running deployment of the project code, can be remotely operated, and is convenient for transplantation and operation. The AI Agent can also be replaced by a deep learning unit test component, which can generate test code OK; high or low efficiency, whether it can be compiled through needs to see the ability of AI or component, but can quickly switch to realize iteration; create a virtual environment of qemu, exclude the influence of car machine and connection, reduce the debugging time, can directly run app / native layer unit test, generate coverage report, convenient and fast. In the environment creation stage, AI or rule script can be used, errors are automatically identified after running, necessary so libraries are copied by themselves, etc., which can also be integrated into the docker compilation environment of each project, packaged together with the AI Agent application system; can also be integrated in CI, realize the automatic writing of unit test of the project in idle time, automatic test, self-generation of coverage report and test case document, generation of UML flowchart for DD detailed document comparison, etc., greatly reduce the labor input.

[0071] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other apparatus. Furthermore, embodiments of the application are not described in terms of any particular programming language.

[0072] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the application can be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been described in detail in order to avoid obscuring the understanding of this description. Like numbers refer to like elements throughout the description. Reference

[0073] As will be appreciated by one skilled in the art, aspects of the embodiments can be embodied as a system, method or computer program product. Accordingly, aspects of the present embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "service", "module" or "component". Furthermore, aspects of the present embodiments can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk memory, CD-ROM, optical, and / or magnetic storage media, etc.).

[0074] It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in a claim. The word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The application can be implemented by means of both hardware and software, and any combination thereof. In a unitary claim, several devices, apparatuses or means can be listed, comprising means for carrying out a certain task. The use of the term'means' in a claim is intended to refer to a combination of devices, apparatuses or means for carrying out a task. The word 'first','second', 'third', etc. do not imply any order. The use of these terms is to be construed as an indication of particular embodiments. Steps in the above-described embodiments, unless otherwise specified, are not to be construed as necessarily limiting the order in which the steps are performed.

Claims

1. A test code generation method characterized by, The method comprises: acquiring a source code file, a test suite and a coverage report, and generating unit test code through a preset LLM model according to the source code file, the test suite and the coverage report; acquiring a test instruction, compiling the unit test code according to the test instruction, and running unit testing in a preset environment after the unit test code is compiled, to generate a coverage report; parsing the coverage report to acquire current coverage data, and comparing the current coverage data with coverage data in a previously saved coverage report to determine whether the current coverage data is improved; if yes, saving the current test code and the coverage report, and otherwise, regenerating and compiling the unit test code; stopping testing and generating target test code and a target coverage report when the coverage data reaches a set threshold or the LLM model reaches a maximum access number.

2. The test code generation method according to claim 1, characterized by, The method of generating unit test code through a preset LLM model according to a source code file, a test suite and a coverage report comprises: parsing the source code file, the test suite and the coverage report, and preparing and enhancing a context of the LLM model; constructing a structured prompt of the LLM model according to the context information, inputting the structured prompt into an LLM model API interface, and generating unit test code.

3. The test code generation method according to claim 1, characterized by, In the process of compiling the unit test code according to the test instruction, when the unit test code fails to pass the compilation, the unit test code is regenerated through the LLM model, and the unit test code is compiled.

4. The test code generation method according to claim 1, characterized by, The preset environment is a qemu virtual environment, a Linux environment or a real vehicle environment.

5. The test code generation method according to any one of claims 1 to 4, characterized by, The unit test code and the source code file are tested according to a preset mapping relationship table, a coverage report is generated, and line coverage or branch coverage is obtained according to the coverage report.

6. The test code generation method according to claim 1, wherein When the current coverage data is improved compared with the coverage data saved last time, the current test data and the coverage report are saved, and the current test data at least includes a test case and test code.

7. The test code generation method of claim 1, wherein, When the current coverage data is not improved compared with the coverage data saved last time, the test code is rolled back, error information is recorded, the unit test code is regenerated through the LLM model, and the unit test code is compiled.

8. A test code generation apparatus characterized by comprising: The device comprises: a test code generation module configured to acquire a source code file, a test suite and a coverage report, and generate unit test code through a preset LLM model according to the source code file, the test suite and the coverage report; a compilation and running module configured to acquire a test instruction, compile the unit test code according to the test instruction, and run unit testing in a preset environment after the unit test code is compiled, to generate a coverage report; an improvement determination module configured to parse the coverage report to acquire current coverage data, compare the current coverage data with coverage data in a previously saved coverage report to determine whether the current coverage data is improved, save the current test code and the coverage report if yes, and otherwise, regenerate and compile the unit test code; and a test code generation module configured to acquire a source code file, a test suite and a coverage report, and generate unit test code through a preset LLM model according to the source code file, the test suite and the coverage report. And a target test code generation module is configured to stop testing and generate a target test code and a target coverage report when the coverage data reaches a set threshold or the LLM model reaches a maximum access number.

9. A test code generation device characterized by comprising: Comprise: A processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete communication with each other through the communication bus; The memory is used to store at least one executable instruction, and the executable instruction makes the processor execute the operation of the test code generation method as claimed in any one of claims 1-7.

10. A readable storage medium, characterized by, The storage medium has at least one executable instruction stored therein, and the executable instruction, when executed on the test code generation device as claimed in claim 9, causes the test code generation device to execute the operation of the test code generation method as claimed in any one of claims 1-7.

Images