Fuzzy Test Driver Generation System Based on Large Language Model

Abstract

The application discloses a large language model-based fuzzy test driver generation system, which comprises a constraint analysis module, an initial program generation module, a verification analysis and decision module and a repair iteration module. The application can automatically verify and repair codes and generate a fuzzy test driver for deep learning library testing, improves the success rate of API calling code generated by the large language model, and effectively improves the generation quality of the fuzzy test driver and the success rate of the large model code generation task.

Description

Technical Field

[0001] This invention relates to a technology in the field of software testing, specifically a fuzzy test driver generation system based on a large language model. Background Technology

[0002] As a key component supporting the development and deployment of artificial intelligence applications, deep learning libraries provide developers with convenient application interfaces and high execution performance through high-level encapsulation of the underlying computational process. However, such software systems are typically composed of multi-language, multi-layered modules, with complex internal implementations and a large number of interfaces. During rapid iteration and performance optimization, they are highly susceptible to introducing various defects and security vulnerabilities. Summary of the Invention

[0003] This invention addresses the shortcomings of existing technologies, which typically fix the logical structure and input patterns of generated test code during the generation phase. This lack of co-evolution with fuzzing engines makes it difficult to fully explore the program's state space during continuous testing. Furthermore, existing fuzzing relies on manually written test drivers, while automated generation schemes suffer from difficulties in meeting interface usage constraints and low code generation success rates. This invention proposes a fuzzing driver generation system based on a large language model. This system automates code verification and repair, generating fuzzing drivers for deep learning library testing. It improves the success rate of generating API call code from a large language model, effectively enhancing the quality of fuzzing driver generation and the success rate of large model code generation tasks.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a fuzzy test driver generation system based on a large language model, comprising: a constraint analysis module, an initial program generation module, a verification analysis and decision module, and a repair iteration module. The constraint analysis module collects the official documentation and sample code of the target test API, and uses a large language model to parse the API documentation and sample code to obtain the constraint rules that the target API calls must follow. The initial program generation module decomposes the initial version of the basic fuzzy test driver code into three parts: a data generation function, a target test function, and an entry point function. It then calls the coding large language model to generate the corresponding parts and finally constructs the complete fuzzy test driver. The verification analysis and decision module uses code verification methods including early termination checks, static analysis, and dynamic analysis to verify the fuzzy test driver. Simultaneously, it uses a problem diagnosis and decision module based on the large language model to analyze quality problems in the fuzzy test driver and make decisions. The repair iteration module repairs the fuzzy test driver according to the requirements based on the problem report and decision results output by the verification analysis and decision module.

[0006] The aforementioned constraint rules include:

[0007] 1) Parameter specifications, including data structure, data type, value range, tensor dimension, and default value;

[0008] 2) Parameter constraints, including dependencies and mutual exclusions;

[0009] 3) Compare examples, including valid examples and incorrect examples;

[0010] 4) Return value, including data type;

[0011] 5) Context dependencies, including pre-operations and module import statements.

[0012] The aforementioned basic fuzzing driver code is the specific code used to implement the target API call. It also transforms the random mutation input generated by the fuzzing engine (Atheris) into a data type acceptable to the target API and passes it to the target API to support fuzzing checks on its underlying code. Furthermore, the program must include the import of modules required for the target API call (such as `import torch`, `import tf`), module and function instrumentation code (`withatheris.instrument_imports()`, `@atheris.instrument_func`), and fuzzing tool initialization configuration code (`atheris.Setup()`, `atheris.Fuzz()`).

[0013] The task decomposition divides the basic fuzzing driver code into a data generation function, a test objective function, and an entry point function. The data generation function transforms the random mutation input generated by the fuzzing engine into parameters required by the target API and verifies the data generation results according to API constraints. The test objective function designs the target API call and exception handling code, parses the parameter data returned by the data generation function, and passes it as input to the test target API. The entry point function sequentially calls the data generation function and the test objective function to complete the program logic. The system uses a large language model to generate the above functions sequentially, ultimately completing the missing code to build a complete fuzzing driver program.

[0014] The verification analysis and decision-making module includes an early termination check unit, a static analysis unit, a dynamic analysis unit, a problem diagnosis unit, and a decision-making unit. Specifically: the early termination check unit first converts the fuzzy test driver program generated by the large language model into an abstract syntax tree (AST), and then terminates the program generation process when a serious problem exists through the AST's traversal and query mechanism; the static analysis unit uses the Ruff static analysis tool to analyze the code that passes the early termination check, identifies and attempts to automatically fix potential problems in the fuzzy test driver program, generates an analysis report, and outputs the problems that could not be fixed; the dynamic analysis unit uses the Atheris fuzzing tool to perform a one-minute actual test on the generated fuzzy test driver program, and simultaneously applies Atheris and the coverage.py tool to track changes in coverage, including the underlying C / C++ code and Python layer code; the problem diagnosis unit uses the large language model to analyze and identify potential problems in the output results of the static and dynamic analyses; and the decision-making unit calls the large language model to parse the results based on the analysis results of the problem diagnosis unit and generates the final decision.

[0015] The serious problems mentioned include: 1) no specific implementation code is provided; 2) lack of import of basic dependent modules; 3) lack of definition of data generation function, test target function and entry point function; 4) function signature error; 5) lack of function or module instrumentation statement; 6) lack of fuzz test initialization code.

[0016] The analysis and identification of potential problems specifically includes:

[0017] Step i combines static analysis logs to identify problems in the fuzz test driver that are identified by the Ruff tool but cannot be automatically fixed.

[0018] Step ii determines whether there are any abnormal signals based on the output of the fuzz test, including compilation-level syntax errors detected by the Python interpreter, UserWarning prompts triggered by the deep learning library, uncaught exceptions caused by improper exception handling, runtime crashes of unknown types, and frequently repeated log output content.

[0019] Step iii analyzes the coverage report generated during the test to determine whether the fuzz test driver successfully called the target API during actual operation and whether the coverage increased during the test.

[0020] Step iv identifies potential problems in the fuzz test driver based on the analysis results, and provides a problem description, error log, problem code, error location, root cause analysis, and repair suggestions.

[0021] The final decision includes: acceptance, rejection, and repair. Accepted fuzzing drivers will be put into actual long-term fuzzing, fuzzing drivers that need repair will be handed over to the repair module to improve code quality, and rejected programs will be directly discarded and will not enter the subsequent repair process.

[0022] The aforementioned repair refers to: based on the repair information in the final decision, taking the problem diagnosis results as input, calling the large language model to automatically repair the fuzzy test driver, and then re-analyzing the repaired fuzzy test driver through the verification analysis and decision module until the maximum number of repairs in the system is reached and then terminated.

[0023] The constraint analysis module is updated in the following ways: based on the text description in the API documentation and the API normal call patterns implied in the sample code, it constructs large model prompt words, analyzes the data types and value ranges of API parameters, constraints between API parameters, constructs valid and invalid API call code examples, specifies API output specifications, and identifies API call context dependencies and module import dependencies.

[0024] The initial program generation module is updated in the following way: based on the characteristics of the fuzz test driver, the fuzz test driver is split into a data generation function, a test target function, and an entry point function, thereby reducing the complexity of the large model code generation task.

[0025] The verification analysis and decision-making module is updated in the following ways: First, based on the structural characteristics of the fuzz test driver, static matching rules are set, including module calls, code instrumentation, API calls, data generation function declarations, test target function declarations, and entry point function declarations. This ensures that the fuzz test driver generated by the large model meets design expectations and avoids errors caused by model forgetting and illusion problems. Second, the Ruff tool is used to identify basic syntax errors and achieve automated repair. Finally, fuzz test verification is introduced, and coverage analysis is used to determine the effectiveness of the fuzz test driver based on whether the coverage rate continues to increase and whether the target API is successfully called. Simultaneously, large model prompts are designed to parse the verification output, identify program errors, and provide system processing decisions.

[0026] The aforementioned repair iteration module is updated in the following way: based on the errors identified in the verification phase, additional large-scale model prompts are designed, and automated repair is performed based on the results of attribution analysis and error localization. Simultaneously, the prompt design requires the model to maintain the original code design principles, avoiding any disruption to the original program design requirements caused by attempting to resolve errors.

[0027] Technical effect

[0028] This invention improves the success rate of generating API call code from large language models through API constraint analysis, effectively enhancing the generation quality of fuzz test drivers and avoiding meaningless errors in practical applications. It also decouples the basic architecture of fuzz test drivers through task decoupling, effectively improving the success rate of large model code generation tasks. Furthermore, this invention implements an automated code verification and repair mechanism, enabling automated generation of fuzz test drivers. Based on a large language model, a multi-agent architecture is designed, realizing an automated generation method for fuzz test drivers oriented towards deep learning library testing, providing technical support for automated vulnerability detection. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the system of the present invention;

[0030] Figure 2 This is a flowchart of an implementation example;

[0031] Figure 3 This is a schematic diagram illustrating the effect of an example. Detailed Implementation

[0032] This embodiment relates to a fuzzy test driver generation system based on a large language model, comprising: a constraint analysis module, an initial program generation module, a verification analysis and decision-making module, and a repair iteration module. Specifically: the constraint analysis module, based on the target deep learning library and the specific deep learning APIs to be tested, addresses the issue of code errors caused by the large language model's inability to effectively consider API usage constraints during code generation through API constraint analysis; the initial program generation module, during the first round of fuzzy test driver generation, decomposes the basic architecture of the fuzzy test driver, improving the success rate of large language model code generation through task decoupling; the verification analysis and decision-making module and the repair iteration module combine automated verification, diagnosis, decision-making, and repair strategies to automate the generation of fuzzy test drivers, improving the success rate of generating effective drivers.

[0033] like Figure 1 As shown, this embodiment illustrates the fuzz test driver generation method based on the aforementioned system. After crawling API documentation and sample code according to the user's test request, the test objective function, data constructor function, and entry point function are generated through constraint analysis. A complete test program is then synthesized and subjected to static and dynamic analysis. After decision analysis and repair, the fuzz test driver is obtained.

[0034] The constraint analysis specifically includes:

[0035] Step 1: Based on the test object, collect the official documentation and sample code of the target API. This method uses the Scrapy web scraping framework to implement a tool for extracting documentation and sample code for the Python layer API interfaces provided to developers by the two major deep learning frameworks, PyTorch and TensorFlow. The tool first identifies the deep learning library version corresponding to the target test API from the official websites of the two frameworks (https: / / docs.pytorch.org / and https: / / www.tensorflow.org / ), identifies the documentation links for the target API from their API lists, extracts all content from the corresponding documentation, and identifies the API signature, text description, and sample code according to predefined rules, caching them to the local system.

[0036] Step 2: Build a test sandbox environment based on the target deep learning library version. Specifically, this involves cloning the target deep learning library's GitHub repository to the local system using a pre-defined Dockerfile template, and replacing the deep learning library and version in the Dockerfile template with the PyTorch framework and its corresponding version. This creates a virtualized Docker sandbox environment for subsequent code generation testing and execution. Specifically, during the sandbox environment construction process, the PyTorch deep learning library's implementation source code will be cloned to the local system via its GitHub repository (https: / / github.com / pytorch / pytorch), and the corresponding deep learning library version will be switched using Git version control commands. Then, the deep learning library source code will be compiled and installed using the clang compiler. During installation, ASAN memory analysis will be started, and LLVM SanitizerCoverage will be used to instrument the target source code, enabling subsequent fuzzing to support coverage detection of its underlying C / C++ code implementation. After the virtual environment is built, the information collection tool based on the Scrapy web crawling framework is called to detect the official documentation links of the target API in the PyTorch official documentation, identify the API function signatures, function descriptions, parameter definitions and other documentation information, and extract the API usage example code given in the documentation and save it to the Docker container of the local system.

[0037] Step 3: Fill the collected API signatures, documentation descriptions, and sample code into the prompt word template to construct the specific large-scale model prompt words for API constraint analysis. Specifically, the prompt words consist of two parts: system prompt words and user prompt words. The system prompt words define the model's role and overall task description, requiring the large model, acting as a deep learning expert, to generate a complete API usage constraint analysis report based on the crawled API documentation and sample code. The user prompt words input the collected API signatures, documentation descriptions, and sample code information, requiring the large model to generate specific constraints including parameter analysis, inter-parameter analysis, valid and invalid API usage examples, API output specifications, API usage context dependencies, and module dependencies, and output the constraint analysis report in Markdown format.

[0038] The following table shows examples of constraint analysis prompt templates:

[0039] The first round of generated fuzz test driver code is obtained in the following way:

[0040] Step a involves calling the large language model's data generation function, target test function, and entry point function, concatenating them, and completing the missing code to build a complete fuzzing driver program. The prompt template used in this process still includes both system prompts and user prompts. The system prompts require the large model, acting as a fuzzing expert and deep learning application expert, to design the functions for each part of the fuzzing driver program. The user prompts provide the specific task requirements for each stage.

[0041] Step b generates the test target function. This step requires the large language model to generate a function with the signature `FuzzTarget(**kwargs)`. This function needs to design API call code and context dependency code according to the API usage specifications. Specifically, all inputs and parameters required for the target API call must be obtained from the function input `kwargs` dictionary using the form `kwargs.get(keyword, default_value)`. Then, based on the API call requirements, forward dependency statements, API call statements, backward dependency statements, and exception handling (try-except) statements are designed. The function should also include resource cleanup code to ensure the test continues and guarantees the normal termination of the code.

[0042] The following table shows examples of prompt word templates generated by the test objective function:

[0043] Step c involves designing a data generation function with the signature `data_constructor(input)` based on the generated test target function. Specifically, this step requires the large language model to generate and validate the input and parameters required for the API call, according to the generated test target function and API usage specifications. This part utilizes the `FuzzedDataProvider` class provided by the Atheris fuzzing framework to convert the mutated input generated by the fuzzing engine into a data format acceptable to the target API. Simultaneously, parameter validation code is designed based on the API call constraints. Finally, all parameters required for the API call are encapsulated into a `kwargs` dictionary and returned for the test target function to call.

[0044] The following table shows examples of prompt word templates generated by the data generation function:

[0045] Step d constructs an entry point function with the signature `entry_point(input)`. This function must include at least: 1) `kwargs = data_constructor(input)` and 2) `return FuzzTarget(**kwargs)`, thus completing the logic from data construction to target testing. Simultaneously, this large language model needs to supplement missing code in the fuzz test driver, such as module imports (`import atheris`, `import sys`, `from Atheris import FuzzedDataProvider`, `import torch`), module and function instrumentation (`with atheris.instrument_imports()`, `@atheris.instrument_func`), and fuzz test configuration and startup code (`atheris.Setup`, `atheris.Fuzz`), etc., to construct a complete fuzz test driver.

[0046] A complete example of a prompt word template for building a fuzz test driver is shown in the table below:

[0047] The verification analysis and decision-making process includes:

[0048] Step i involves early termination checks to identify situations where the output deviates significantly from the design expectations due to model illusion and forgetting issues: First, the fuzzy test driver generated by the large language model is converted into an abstract syntax tree. Then, through the traversal query mechanism of the abstract syntax tree, the program generation process is terminated when a serious problem exists.

[0049] Step ii: Static Analysis: Using the Ruff static analysis tool, identify and attempt to automatically fix potential problems in the fuzz test driver. Generate an analysis report, outputting issues that could not be fixed.

[0050] Step iii: Dynamic Analysis: The generated fuzz test driver was subjected to a 1-minute live test using the fuzz testing tool Atheris, and the coverage changes of both Python and underlying C / C++ code were tracked. Simultaneously, the coverage.py tool was used to track changes in Python code line coverage during code execution.

[0051] Step iv uses a large language model to analyze the output of the dynamic and static analysis to identify potential problems in the fuzz test driver code, specifically including:

[0052] 4.1 By combining static analysis logs, identify problems in the fuzz test driver that are identified by the Ruff tool but cannot be automatically fixed.

[0053] The following table shows an example of a static analysis result parsing prompt word template:

[0054] 4.2 Based on the output of the fuzz test, determine whether there are any abnormal signals, including compilation-level syntax errors detected by the Python interpreter, UserWarning prompts triggered by the deep learning library, uncaught exceptions caused by improper exception handling, runtime crashes of unknown types, and frequently repeated log output content.

[0055] The following table shows an example of a fuzz test output result parsing prompt word template:

[0056] 4.3 Analyze the coverage reports generated during the testing process to determine whether the fuzz test driver successfully called the target API during actual operation, and whether the coverage increased during the testing process.

[0057] The following table shows an example of a coverage parsing prompt word template:

[0058] 4.4 Based on the analysis results, identify potential problems in the fuzz test driver, and provide a problem description, error log, problem code, error location, root cause analysis, and repair suggestions.

[0059] Step v calls the large language model for parsing based on the analysis results of the problem diagnosis unit, and gives a final decision, including acceptance, rejection and repair. Among them: accepted fuzz test drivers will be put into actual long-term fuzz testing, fuzz test drivers that need to be repaired will be handed over to the repair module to improve code quality, and rejected programs will be directly discarded and will not enter the subsequent repair process.

[0060] The following table shows examples of prompt word templates used in the decision-making module:

[0061] The aforementioned repair iteration refers to: based on the problem diagnosis input large language model in the repair decision, automatically repairing the original fuzzy test driver program, and then re-passing the verification analysis and decision until the maximum number of repairs in the system is reached and terminated.

[0062] The aforementioned fix requires the large model to maintain the original basic design requirements of the fuzz test driver and resolve the issues identified by the previous modules, thereby generating an effective fuzz test driver. The fixed code, after verification, can be used in actual fuzz testing, thus achieving fully automated fuzz testing.

[0063] The following table shows examples of prompt word templates used by the repair module:

[0064] Through practical application experiments, in a deep learning library API security testing environment, the fuzz test driver generation system based on a large language model of this invention was run, and the experimental data obtained are as follows:

[0065] The success rate of the test program generation is shown in the table below:

[0066] Examples of fuzzing drivers generated using the torch.nn.AdaptiveLogSoftmaxWithLoss API and examples of vulnerabilities discovered are as follows: Figure 3 As shown.

[0067] Compared with existing technologies, the success rate of generating fuzz test drivers in this invention is improved by 35.47-54.34% in the PyTorch deep learning library and by 34.66-54.66% in the TensorFlow deep learning library, demonstrating a significant improvement in the generation effect of fuzz test drivers.

[0068] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A fuzzy test driver generation system based on a large language model, characterized in that, include: The system comprises a constraint analysis module, an initial program generation module, a verification analysis and decision-making module, and a repair iteration module. Specifically: the constraint analysis module collects the official documentation and sample code of the target test API, uses a large language model to parse the API documentation and sample code, and obtains the constraint rules that the target API calls must follow; the initial program generation module decomposes the initial version of the basic fuzz test driver code into three parts: a data generation function, a target test function, and an entry point function, and calls the large language model to generate the corresponding parts, ultimately constructing a complete fuzz test driver; the verification analysis and decision-making module employs code verification methods including early termination checks, static analysis, and dynamic analysis to verify the fuzz test driver, while simultaneously using a problem diagnosis and decision-making module based on a large language model to analyze quality issues in the fuzz test driver and make decisions. The repair iteration module, based on the problem report and decision results output by the verification analysis and decision module, repairs the fuzz test driver according to requirements.

2. The fuzzy test driver generation system based on a large language model according to claim 1, characterized in that, The aforementioned basic fuzzing driver code is the specific code used to implement the target API call. It also transforms the random mutation input generated by the fuzzing engine (Atheris) into a data type acceptable to the target API and passes it to the target API to support fuzzing checks on its underlying code. In addition, the program also needs to include the import of the modules required for the target API call (such as import torch, import tf), module and function instrumentation code (with atheris.instrument_imports(), @atheris.instrument_func), and fuzzing tool initialization configuration code (atheris.Setup(), atheris.Fuzz()).

3. The fuzzy test driver generation system based on a large language model according to claim 1, characterized in that, The task decomposition divides the basic fuzz test driver code into a data generation function, a test target function, and an entry point function. Specifically: the data generation function transforms the random mutation input generated by the fuzz test engine into parameters required by the target API and verifies the data generation results according to API constraints; the test target function designs the target API call and exception handling code, parses the parameter data returned by the data generation function, and passes it as input to the test target API; the entry point function sequentially calls the data generation function and the test target function to complete the program logic. The system uses a large language model to sequentially generate the above functions, ultimately completing the missing code to build a complete fuzz test driver program.

4. The fuzzy test driver generation system based on a large language model according to any one of claims 1-3, characterized in that, The verification analysis and decision-making module includes an early termination check unit, a static analysis unit, a dynamic analysis unit, a problem diagnosis unit, and a decision-making unit. Specifically: the early termination check unit first converts the fuzzy test driver program generated by the large language model into an abstract syntax tree (AST), and then terminates the program generation process when a serious problem exists through the AST's traversal and query mechanism; the static analysis unit uses the Ruff static analysis tool to analyze the code that passes the early termination check, identifies and attempts to automatically fix potential problems in the fuzzy test driver program, generates an analysis report, and outputs the problems that could not be fixed; the dynamic analysis unit uses the Atheris fuzzing tool to perform a one-minute actual test on the generated fuzzy test driver program, and simultaneously applies Atheris and the coverage.py tool to track changes in coverage, including the underlying C / C++ code and Python layer code; the problem diagnosis unit uses the large language model to analyze and identify potential problems in the output results of the static and dynamic analyses; and the decision-making unit calls the large language model to parse the results based on the analysis results of the problem diagnosis unit and generates the final decision.

5. The fuzzy test driver generation system based on a large language model according to claim 4, characterized in that, The serious issues mentioned include: 1) no specific implementation code provided; 2) missing imports of basic dependent modules; 3) missing definitions of data generation functions, test target functions, and entry point functions; 4) function signature errors; 5) missing function or module instrumentation statements; and 6) missing fuzz test initialization code. The analysis and identification of potential problems specifically includes: Step i combines static analysis logs to identify problems in the fuzz test driver that are identified by the Ruff tool but cannot be automatically fixed; Step ii determines whether there are any abnormal signals based on the output of the fuzz test, including compilation-level syntax errors detected by the Python interpreter, UserWarning prompts triggered by the deep learning library, uncaught exceptions caused by improper exception handling, runtime crashes of unknown types, and frequently repeated log output content. Step iii analyzes the coverage report generated during the test to determine whether the fuzz test driver successfully called the target API in actual operation and whether the coverage increased during the test. Step iv identifies potential problems in the fuzz test driver based on the analysis results, and provides a problem description, error log, problem code, error location, root cause analysis, and repair suggestions; The final decision includes: acceptance, rejection, and repair. Accepted fuzzing drivers will be put into actual long-term fuzzing, fuzzing drivers that need repair will be handed over to the repair module to improve code quality, and rejected programs will be directly discarded and will not enter the subsequent repair process. The aforementioned repair refers to: based on the repair information in the final decision, taking the problem diagnosis results as input, calling the large language model to automatically repair the fuzzy test driver, and then re-analyzing the repaired fuzzy test driver through the verification analysis and decision module until the maximum number of repairs in the system is reached and then terminated.

6. The fuzzy test driver generation system based on a large language model according to claim 1, characterized in that, The constraint analysis module is updated in the following ways: based on the text description in the API documentation and the API normal call patterns implied in the sample code, it constructs large model prompt words, analyzes the data types and value ranges of API parameters, constraints between API parameters, constructs valid and invalid API call code examples, specifies API output specifications, and identifies API call context dependencies and module import dependencies.

7. The fuzzy test driver generation system based on a large language model according to claim 1, characterized in that, The initial program generation module is updated in the following way: based on the characteristics of the fuzz test driver, the fuzz test driver is split into a data generation function, a test target function, and an entry point function, thereby reducing the complexity of the large model code generation task.

8. The fuzzy test driver generation system based on a large language model according to claim 1, characterized in that, The verification analysis and decision-making module is updated in the following ways: First, based on the structural characteristics of the fuzz test driver, static matching rules are set, including module calls, code instrumentation, API calls, data generation function declarations, test target function declarations, and entry point function declarations. This ensures that the fuzz test driver generated by the large model meets the design expectations and avoids errors caused by model forgetting and illusion problems. Second, the Ruff tool is used to identify basic syntax errors and achieve automated repair. Finally, fuzz test verification is introduced, and coverage analysis is used. The effectiveness of the fuzz test driver is judged based on whether the coverage rate continues to increase and whether the target API is successfully called. At the same time, large model prompt words are designed to parse the verification output, identify program errors, and provide system processing decisions.

9. The fuzzy test driver generation system based on a large language model according to claim 1, characterized in that, The repair iteration module is updated in the following way: based on the errors identified in the verification phase, additional large model prompt words are designed, and automatic repair is performed based on the results of attribution analysis and error localization. At the same time, the prompt word design requires the model to maintain the original design principles of the code to avoid destroying the original design requirements of the program due to the need to solve errors.

10. A method for generating a fuzz test driver based on the system of any one of claims 1-9, characterized in that, After crawling API documentation and sample code based on user test requests, the test objective function, data constructor function, and entry point function are generated through constraint analysis, and then a complete test program is synthesized. Static and dynamic analysis are performed, and after decision analysis and repair, a fuzz test driver program is obtained.

Images