Fuzzy test driving program generation method based on multi-dimensional API sequence construction
By constructing multi-dimensional API sequences and scheduling coverage-guided time, MASFuzzer generates high-quality fuzz test drivers, addressing the shortcomings of existing methods in coverage depth and resource utilization efficiency, and achieving efficient fuzz testing.
Patent Information
- Application Number
- CN202511631400.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-10
- Publication Date
- 2026-01-23
AI Technical Summary
Existing fuzz test-driven generation methods have shortcomings in terms of coverage depth and sequence construction effectiveness. They are particularly inefficient when testing large and complex libraries, and their resource allocation is unreasonable, resulting in low-value drivers wasting resources.
MASFuzzer, a fuzz test driver generation method built using multi-dimensional API sequences, integrates multi-dimensional API sequences with LLM to construct rich contextual information and combines time scheduling and mutation strategies to cover bootstrapping, thereby optimizing driver generation and resource utilization.
It significantly improves the coverage and resource utilization efficiency of fuzz testing, enhances the ability to explore deep logic, reduces human intervention, and achieves efficient fuzz testing.
Smart Images
Figure CN121387746A_ABST
Abstract
Description
Technical Field
[0001] This invention provides a method for generating fuzzy test drivers based on multi-dimensional API sequences, belonging to the field of software engineering technology. Background Technology
[0002] In the field of software testing, automating the generation of high-coverage fuzz drivers has become an important research direction for improving library security and robustness. Traditional methods mainly rely on developers manually writing test drivers, which is inefficient and difficult to cover deep logic. In recent years, with the widespread application of Large Language Models (LLMs) in code generation tasks, researchers have begun to explore automated driver generation methods based on LLMs to overcome the limitations of manual writing.
[0003] One representative technical solution is PromptFuzz, which directly generates compileable and runnable fuzz test drivers by providing the LLM with basic context information about the target library API—such as function signatures, parameter types, and structure definitions. Another important work is CKGFuzzer, which further constructs a code knowledge graph, explicitly models the call relationships between APIs, and introduces an intelligent agent mechanism to handle errors during compilation and the generation of initial test seeds, effectively improving the usability and coverage of the driver.
[0004] Besides pure LLM-driven methods, some studies combine program analysis and feedback learning mechanisms to achieve driver-driven generation. For example, Hopper employs an interpretive fuzzing framework, automatically inferring API call sequences and parameter constraints through dynamic execution and coverage feedback, without relying on extensive pre-defined code or documentation. These methods reduce reliance on training data and model capabilities to some extent, providing diverse technical paths for library testing. Overall, existing methods comprehensively utilize techniques from static analysis, machine learning, and software engineering to gradually build a fuzz test-driven development system centered on automated generation.
[0005] While existing methods have made significant progress in automating the generation of fuzz test drivers, they still have several limitations. First, existing LLM-driven methods heavily rely on the model's understanding of the underlying API context. For example, PromptFuzz provides only limited information such as function signatures and type definitions, lacking crucial information like the call order, data flow, and semantic constraints between APIs. This often results in generated drivers that cannot effectively combine multiple APIs to trigger deep code branches. CKGFuzzer constructs a code knowledge graph to characterize API call relationships, but these relationships often fail to reflect effective API sequence relationships. Hopper dynamically explores API usage sequences through coverage feedback, reducing reliance on training data, but its strategy of relying on large-scale search space exploration struggles to effectively cover complex or semantically related deep logic within limited time budgets, especially when testing large, complex libraries. Furthermore, existing methods generally allocate the same test time and computational resources to all generated drivers, failing to dynamically schedule them according to their actual coverage potential. This leads to low testing efficiency, with a large amount of resources consumed on low-value drivers. These factors collectively limit the practical effectiveness of existing methods in generating high-quality, high-coverage drivers and hinder their widespread application in real-world scenarios. Summary of the Invention
[0006] This invention addresses the shortcomings of existing fuzz test driver generation methods in terms of coverage depth and sequence construction effectiveness. It proposes a fuzz test driver generation method based on multi-dimensional API sequence construction, employing the MASFuzzer automated driver generation framework that integrates multi-dimensional API sequences with LLM (Limited Language Management). This aims to significantly improve test coverage and real vulnerability discovery capabilities for software libraries. The framework is dedicated to systematically generating high-quality, executable fuzz test drivers without manual intervention, thereby enabling a thorough exploration of complex library API interactions and deep program states.
[0007] Specifically, the main problems to be solved include:
[0008] (1) Existing LLM generation methods lack contextual information and API relationships, making it difficult for generated drivers to form effective long call chains and complex object state transfers. To address this, we propose a multi-dimensional API sequence construction method. By extracting real use case sequences from the codebase, generating data flow sequences based on type compatibility, and using LLM for semantic analysis to mine implicit dependency sequences, we provide rich and structured contextual information for driver generation, significantly improving the quality and depth coverage potential of the initial driver.
[0009] (2) Traditional fuzz-driven testing frameworks allocate resources equally to all drivers, resulting in insufficient testing of high-potential drivers and wasted resources on low-potential drivers. We designed a coverage-guided time scheduling algorithm that dynamically allocates test time based on the API-level coverage feedback of each driver, prioritizing the scheduling of drivers with high coverage potential but insufficient exploration, thereby optimizing the efficiency of global test resource utilization.
[0010] (3) A context-aware driving mutation strategy is proposed. Combining multidimensional sequence features and coverage feedback, mutation operations such as API insertion, replacement or sequence merging are performed on invalid drivers to restore their exploration capabilities and continuously explore uncovered code regions.
[0011] The specific technical solution is as follows:
[0012] A method for generating fuzz test drivers based on multi-dimensional API sequences includes the following steps:
[0013] S1. Multi-dimensional API Sequence Construction. MASFuzzer first performs syntactic and static analysis on the target library to extract meta-information of public APIs, including function signatures, parameter types, and code locations. Based on this, the system constructs effective API call sequences from three complementary dimensions: extracting real call sequences from the library's own test cases and sample code; generating API sequences with data flow coherence based on type compatibility relationships; and using LLM to analyze API semantics and implicit dependencies to derive semantically reasonable call chains. These sequences collectively constitute the structured context driving the generation.
[0014] S2.LLM-driven fuzzing driver generation and repair. MASFuzzer combines multidimensional API sequences with corresponding metadata to form prompt words, which are then input into the LLM to generate candidate drivers. The LLM then performs compilation checks and repairs any fuzzing drivers that fail to compile, ensuring the generation of high-quality fuzzing drivers.
[0015] S3. Seed Corpus Generation and Selection. For each generated driver program, MASFuzzer automatically constructs initial input seeds based on the API documentation and sample code, and dynamically updates and selects effective seeds during testing based on coverage feedback to improve the relevance of test input.
[0016] S4. Coverage-driven test time scheduling. A dynamic time allocation strategy is adopted, which allocates more test time to drivers with greater coverage potential based on the historical coverage of the APIs associated with each driver, thereby optimizing the utilization efficiency of global test resources.
[0017] S5. Fuzzing Driver Mutation. For drivers that fail to trigger new coverage, MASFuzzer performs mutation operations such as API insertion, replacement, or sequence merging on the original driver based on a multidimensional sequence library and energy calculation, generating an evolved version for continued exploration.
[0018] S6. Crash Analysis and Automated Diagnosis. The system uses LLM to classify and analyze crashes triggered during testing, distinguishing between API misuse and real library vulnerabilities, and attempts to generate brief diagnostic reports to help developers quickly locate problems.
[0019] Further:
[0020] S1. The specific method for constructing multi-dimensional API sequences is as follows:
[0021] MASFuzzer systematically constructs high-quality API sequences through three complementary dimensions, providing rich and reliable contextual information for subsequent fuzz-driven generation based on a large language model. These three dimensions, starting from real-world use cases, type data flow, and semantic dependencies, respectively, jointly ensure that the generated API sequences possess syntactic correctness, data flow integrity, and semantic rationality.
[0022] First, API sequence mining based on real-world usage examples extracts valid call patterns verified by developers from the target library's source code. MASFuzzer performs Abstract Syntax Tree (AST) and Control Flow Graph (CFG) analysis on the library source code to identify the call locations and sequences of public APIs. These sequences typically originate from test cases within the project, sample programs, or existing fuzzy drivers.
[0023] Secondly, type-aware API sequence mining constructs a call chain with complete data flow transmission capabilities by analyzing the compatibility of input and output types between APIs. MASFuzzer first establishes type compatibility relationships: if the return type of API a_i is the same as a parameter type of another API a_j, then the two are considered to form a data flow connection. Based on this, a type compatibility directed graph G is constructed, where nodes are APIs and edges represent type compatibility relationships. Subsequently, the system performs a depth-first search starting from nodes with an in-degree of zero to generate sequences with a maximum length of L. For example, in the cJSON library, since most APIs operate around the cJSON structure, type matching can naturally form long call chains.
[0024] Finally, semantically aware API sequence mining leverages the reasoning capabilities of large language models to identify and construct implicit semantic dependencies that cannot be obtained through grammatical or type analysis. This process consists of three stages: semantic information extraction, semantic relation identification, and sequence synthesis. First, MASFuzzer constructs cue words using API metadata (such as function names, parameter lists, and comments) to guide the LLM in generating natural language summaries describing the API's functionality. Subsequently, based on these summaries, the LLM is further prompted to infer the semantic preconditions and dependencies of specific APIs. Finally, the system synthesizes a logically consistent API call sequence based on the identified semantic dependencies.
[0025] S4. Override-based test scheduling
[0026] Based on the historical coverage of the APIs contained in each driver, its current testing value is evaluated, and the time budget to be allocated is calculated accordingly. Specifically, for the i-th driver D[i] to be tested, the algorithm first deduplicates the APIs it calls, and then calculates the average historical branch coverage avgCov of these APIs. If this value exceeds a preset threshold θ (default 0.9), the driver is skipped to avoid redundant testing. For drivers with coverage below the threshold, the algorithm dynamically adjusts their time share through a time coefficient α_i based on the idea of simulated annealing. This coefficient is calculated by the formula α_i = Bound(B^(i / |D| - 1), α_min,α_max), where B is the decay base, used to allocate resources to more drivers in the early stage of testing, and concentrate time on a few high-potential drivers in the later stage.
[0027] Ultimately, the driver's allocation time, t_assign, is derived by inversely scaling the base time share with coverage, i.e., t_assign = t / max(avgCov, β), where β is a very small constant used to avoid division by zero errors and provide minimum time guarantees for low-coverage drivers. After the driver executes within the allocated time, if no new coverage is found, the driver mutation mechanism is triggered and the test is retested; if new coverage is found, the global coverage information is updated and the remaining time resources are released.
[0028] S5. Variations in fuzz test drivers
[0029] The potential value of each API is assessed through energy allocation, and multiple mutation operations are intelligently applied based on this to reshape the behavior of the driver to cover previously untouched code areas.
[0030] One of the core mechanisms of the mutation strategy is the energy allocation model. MASFuzzer abandons the traditional energy calculation method that relies solely on coverage frequency and proposes a new energy calculation formula:
[0031] energy(api) = (1 - cov(api)) × (1 - frequency(api)) × potential(api)
[0032] Here, cov(api) represents the proportion of branches covered by the API, frequency(api) represents the frequency of API calls in the historical drive, and the newly added potential(api) measures the number of times the API appears in the multidimensional sequence, reflecting its semantic diversity and combinatorial potential.
[0033] Based on energy assessment, MASFuzzer implements three core mutation operations, randomly selecting one in each iteration to apply to invalid drives:
[0034] One is insertion mutation, which inserts the API with the highest current energy into a random position in the driver's call sequence, introducing new functionality or state operations;
[0035] The second is replacement mutation, which selects a random segment of the current sequence and replaces it with an API with higher energy to change the data flow or execution logic;
[0036] The third is combinatorial mutation, which randomly selects a subsequence from a multidimensional API sequence that has never been used and merges it with the current driver's sequence to construct a more complex and structured call chain.
[0037] Beneficial effects of the technical solution of this invention
[0038] (1) Significantly improve driver quality and coverage depth. By constructing multi-dimensional API sequences and integrating real call, type compatibility and semantic dependency information, rich context is provided for LLM, and the generated fuzz test drivers are more semantically reasonable and have greater execution depth.
[0039] (2) Improve the efficiency of test resource utilization. Through the coverage-guided dynamic time scheduling mechanism, more test time is allocated to high-potential drivers, reducing resource waste and improving overall test coverage.
[0040] (3) Enhance the ability to reuse ineffective drivers. Employ a multi-strategy mutation method based on energy allocation to enable inefficient drivers to regain their exploratory capabilities and continuously uncover deeper logic.
[0041] (4) Reduce labor costs. Achieve full automation from sequence construction to driver generation, scheduling and mutation, reduce manual intervention, and improve testing efficiency and vulnerability discovery capabilities. Attached Figure Description
[0042] Figure 1This outlines the overall workflow of the MASFuzzer.
[0043] Figure 2 The API sequence extracted from the codebase usage examples in this embodiment;
[0044] Figure 3 The API sequence constructed using the type matching method in this example;
[0045] Figure 4 The API sequence constructed using a semantic matching method is an example of this embodiment;
[0046] Figure 5 The example uses a test time scheduling algorithm guided by coverage. Detailed Implementation
[0047] This invention designs and implements the fuzz testing framework MASFuzzer. Figure 1 The fuzz test driver generation method mainly includes six core stages:
[0048] S1. Construction of multi-dimensional API sequences.
[0049] MASFuzzer first performs syntactic and static analysis on the target library to extract metadata about public APIs, including function signatures, parameter types, and code locations. Based on this, the system constructs effective API call sequences from three complementary dimensions: extracting real call sequences from the library's own test cases and example code; generating API sequences with data flow coherence based on type compatibility relationships; and using LLM to analyze API semantics and implicit dependencies to derive semantically reasonable call chains. These sequences together constitute the structured context that drives the generation.
[0050] Specifically:
[0051] MASFuzzer systematically constructs high-quality API sequences through three complementary dimensions, providing rich and reliable contextual information for subsequent fuzz-driven generation based on a large language model. These three dimensions, starting from real-world use cases, type data flow, and semantic dependencies, respectively, jointly ensure that the generated API sequences possess syntactic correctness, data flow integrity, and semantic rationality.
[0052] First, API sequence mining based on real-world usage examples extracts valid call patterns verified by developers from the target library's source code. MASFuzzer performs Abstract Syntax Tree (AST) and Control Flow Graph (CFG) analysis on the library source code to identify the call locations and sequences of public APIs. These sequences typically originate from project test cases, sample programs, or existing fuzzy drivers. Figure 2This demonstrates an API sequence extracted from the libpcap library. Such sequences directly reflect real and reliable API usage habits, providing a highly reliable foundation for driver generation.
[0053] Secondly, type-aware API sequence mining constructs a call chain with complete data flow transmission capabilities by analyzing the compatibility of input and output types between APIs. MASFuzzer first establishes type compatibility relationships: if the return type of API a_i is the same as a parameter type of another API a_j, then the two are considered to form a data flow connection. Based on this, a type compatibility directed graph G is constructed, where nodes are APIs and edges represent type compatibility relationships. Subsequently, the system performs a depth-first search starting from nodes with zero in-degree to generate sequences with a maximum length of L. For example, in the cJSON library, since most APIs operate around the cJSON structure, type matching can naturally form long call chains. Figure 3 This paper presents a type-aware API sequence. The method ensures that adjacent APIs in the sequence can be connected through data objects, satisfying mutation propagation completeness (MPC), allowing changes in fuzzing inputs to propagate along the call chain and thus explore deeper program states.
[0054] Finally, semantically aware API sequence mining leverages the reasoning capabilities of large language models to identify and construct implicit semantic dependencies that cannot be obtained through grammatical or type analysis. This process consists of three stages: semantic information extraction, semantic relation identification, and sequence synthesis. First, MASFuzzer constructs cue words using API metadata (such as function names, parameter lists, and comments) to guide the LLM in generating natural language summaries describing the API's functionality. Subsequently, based on these summaries, the LLM is further prompted to infer the semantic preconditions and dependencies of specific APIs, such as... Figure 4 This demonstrates the API sequence constructed using this method. Such dependencies typically involve global state initialization or implicit protocol constraints that cannot be captured by static type analysis. Ultimately, the system synthesizes a logically consistent sequence of API calls based on the identified semantic dependencies.
[0055] By integrating the sequence construction methods of the above three dimensions, MASFuzzer can generate rich API call chains that not only conform to real-world usage habits but also have reasonable data flow and semantics, laying a solid foundation for generating high-quality fuzz test drivers.
[0056] Generation and repair of fuzz test drivers for S2.LLM.
[0057] MASFuzzer combines multidimensional API sequences with corresponding metadata to form prompt words, which are then input into the LLM to generate candidate drivers. The LLM then performs compilation checks and repairs any fuzzing drivers that fail to compile, ensuring the generation of high-quality fuzzing drivers.
[0058] S3. Seed Corpus Generation and Selection.
[0059] For each generated driver, MASFuzzer automatically constructs an initial input seed based on the API documentation and sample code, and dynamically updates and selects effective seeds based on coverage feedback during testing to improve the relevance of test inputs.
[0060] S4. Override-guided test time scheduling.
[0061] The system designs a dynamic time allocation strategy that allocates more test time to drivers with greater coverage potential based on the historical coverage of the APIs associated with each driver, thereby optimizing the utilization efficiency of global test resources.
[0062] Specifically:
[0063] MASFuzzer designed a coverage-guided time scheduling algorithm that dynamically allocates differentiated test time to each driver, thereby significantly improving the utilization efficiency of test resources and the overall coverage. The detailed algorithm implementation is shown in Figure 5. The core of this scheduling algorithm is to evaluate the current test value of each driver based on the historical coverage of its APIs and calculate the allocated time budget accordingly. Specifically, for the i-th driver D[i] to be tested, the algorithm first deduplicates the APIs it calls, and then calculates the average historical branch coverage avgCov of these APIs. If this value exceeds a preset threshold θ (default 0.9), the driver is skipped to avoid redundant testing. For drivers with coverage below the threshold, the algorithm dynamically adjusts their time share using a time coefficient α_i based on simulated annealing. This coefficient is calculated using the formula α_i = Bound(B^(i / |D| - 1), α_min, α_max), where B is the decay base, used to allocate resources to more drivers in the early stages of testing, and then concentrate time on a few high-potential drivers in the later stages.
[0064] Ultimately, the driver's allocation time, t_assign, is derived by inversely scaling the base time share with coverage, i.e., t_assign = t / max(avgCov, β), where β is a very small constant used to avoid division by zero errors and provide minimum time guarantees for low-coverage drivers. After the driver executes within the allocated time, if no new coverage is found, the driver mutation mechanism is triggered and the test is retested; if new coverage is found, the global coverage information is updated and the remaining time resources are released. This mechanism ensures that test resources are continuously tilted towards drivers with higher coverage potential, avoiding resource waste and systematically improving the ability to probe deep code regions, making it a key part of achieving efficient fuzz testing.
[0065] S5. Variations in the fuzz test driver.
[0066] For drivers that fail to trigger new coverage, MASFuzzer does not discard them immediately. Instead, it performs mutation operations such as API insertion, replacement, or sequence merging on the original driver based on the multidimensional sequence library and energy calculation to generate an evolutionary version for continued exploration.
[0067] Specifically:
[0068] During fuzzing, some initially generated drivers may fail to effectively explore new code paths or trigger potential vulnerabilities. To systematically improve the testing potential of such inefficient drivers, MASFuzzer proposes a driver mutation strategy that integrates multi-dimensional API sequence information. This strategy evaluates the potential value of each API through energy allocation and intelligently applies multiple mutation operations based on this, aiming to reshape the driver's behavior to cover previously untouched code regions.
[0069] One of the core mechanisms of the mutation strategy is the energy allocation model. MASFuzzer abandons the traditional energy calculation method that relies solely on coverage frequency and proposes a new energy calculation formula:
[0070] energy(api) = (1 - cov(api)) × (1 - frequency(api)) × potential(api)
[0071] Here, cov(api) represents the proportion of branches covered by the API, frequency(api) indicates the frequency of API calls in the historical drive, and the newly added potential(api) measures the number of times the API appears in the multi-dimensional sequence, reflecting its semantic diversity and combinatorial potential. This model takes into account coverage, call distribution, and static sequence characteristics, thus more comprehensively characterizing the testing value of the API.
[0072] Based on energy assessment, MASFuzzer implements three core mutation operations, randomly selecting one in each iteration to apply to invalid drives:
[0073] One is insertion mutation, which inserts the API with the highest current energy into a random position in the driver's call sequence, introducing new functionality or state operations;
[0074] The second is replacement mutation, which selects a random segment of the current sequence and replaces it with an API with higher energy to change the data flow or execution logic;
[0075] The third is combinatorial mutation, which randomly selects a subsequence from a multidimensional API sequence that has never been used and merges it with the current driver's sequence to construct a more complex and structured call chain.
[0076] S6. Crash analysis and automatic diagnosis.
[0077] Finally, the system uses LLM to classify and analyze crashes triggered during testing, distinguishing between API misuse and real library vulnerabilities, and attempts to generate brief diagnostic reports to help developers quickly locate problems.
[0078] This invention includes several custom parameters during the generation and execution of the fuzz test driver, including coverage boundaries and time scheduling factors during the time scheduling phase. These parameters can be replaced with other values or generated using heuristic methods, depending on actual needs.
Claims
1. A method for generating fuzz test drivers based on multi-dimensional API sequences, characterized in that, Includes the following steps: S1. Construction of multi-dimensional API sequences; MASFuzzer first performs syntactic and static analysis on the target library to extract metadata about the common APIs. Based on this, the system constructs an effective API call sequence from three complementary dimensions: Extract the actual call sequence from the library's own test cases and sample code; Generate API sequences with coherent data flow based on type compatibility relationships; By using LLM to analyze API semantics and implicit dependencies, a semantically reasonable call chain can be derived. These sequences together constitute the structured context that drives the generation; Generation and repair of S2.LLM-driven fuzz test driver; MASFuzzer combines multidimensional API sequences with corresponding metadata into prompt words, inputs them into the LLM to generate candidate drivers, and then, through compilation checks, the LLM repairs fuzz test drivers that fail to compile. S3. Seed Corpus Generation and Selection; For each generated driver, MASFuzzer automatically constructs the initial input seed based on the API documentation and sample code, and dynamically updates and selects the effective seed based on coverage feedback during the testing process; S4. Override-guided test time scheduling; A dynamic time allocation strategy is adopted, based on the historical coverage of the API associated with each driver; S5. Variations in fuzz test drivers; For drivers that fail to trigger new coverage, MASFuzzer performs mutation operations on the original drivers based on multidimensional sequence libraries and energy calculations to generate evolutionary versions for continued exploration; S6. Crash analysis and automated diagnosis; The system uses LLM to classify and analyze crashes triggered during testing, distinguishing between API misuse and real library vulnerabilities, and attempts to generate brief diagnostic reports to help developers quickly locate problems.
2. The fuzz test driver generation method based on multi-dimensional API sequence construction according to claim 1, characterized in that, S1. The specific method for constructing multi-dimensional API sequences is as follows: MASFuzzer systematically constructs a high-quality API sequence through three complementary dimensions, providing contextual information for subsequent fuzz test-driven generation based on a large language model; First, API sequence mining based on real-world usage examples extracts correct calling patterns that have been verified by developers from the source code of the target library; MASFuzzer performs Abstract Syntax Tree (AST) and Control Flow Graph (CFG) analysis on the library source code to identify the call locations and sequences of public APIs; these sequences are usually derived from test cases, sample programs, or existing fuzzy drivers within the project. Secondly, type-aware API sequence mining constructs a call chain with complete data flow transmission capability by analyzing the compatibility of input and output types between APIs. MASFuzzer first establishes type compatibility relationships: if the return type of API a_i is the same as the parameter type of another API a_j, then the two are considered to be able to form a data flow connection. Based on this, a type compatibility directed graph G is constructed, where nodes are APIs and edges represent type compatibility relationships. Subsequently, the system performs a depth-first search starting from the node with an in-degree of zero, generating a sequence with a maximum length of L; Finally, semantically aware API sequence mining leverages the reasoning capabilities of large language models to identify and construct implicit semantic dependencies that cannot be obtained through grammatical or typological analysis. This process consists of three stages: semantic information extraction, semantic relation identification, and sequence synthesis. First, MASFuzzer uses API metadata to construct cue words, guiding the LLM to generate natural language summaries describing the API's functionality. Subsequently, based on these summaries, the LLM is further prompted to infer the semantic preconditions and dependencies of specific APIs; finally, the system synthesizes a logically consistent API call sequence based on the identified semantic dependencies.
3. The fuzz test driver generation method based on multi-dimensional API sequence construction according to claim 1, characterized in that, S4. The specific method for scheduling test time under the overlay guidance is as follows: Based on the historical coverage of the APIs contained in each driver, the algorithm evaluates its current testing value and calculates the time budget to be allocated accordingly. Specifically, for the i-th driver D[i] to be tested, the algorithm first deduplicates the APIs it calls, and then calculates the average historical branch coverage avgCov of these APIs. If the value exceeds the preset threshold θ, the driver is skipped to avoid redundant testing. For drivers with coverage below the threshold, the algorithm dynamically adjusts its time share through a time coefficient α_i based on the idea of simulated annealing. This coefficient is calculated using the formula α_i = Bound(B^(i / |D| - 1), α_min, α_max), where B is the decay base, used to allocate resources to more drivers in the early stage of testing, and to concentrate time on a few high-potential drivers in the later stage. Ultimately, the driver's allocation time t_assign is derived from the base time share by inverse scaling of coverage, i.e., t_assign = t / max(avgCov, β), where β is a very small constant used to avoid division by zero errors and to provide minimum time guarantees for low-coverage drivers. After the driver executes within the allocated time, if no new coverage is found, the driver mutation mechanism is triggered and the test is repeated; if a new coverage is found, the global coverage information is updated and the remaining time resources are released.
4. The fuzz test driver generation method based on multi-dimensional API sequence construction according to claim 1, characterized in that, S5. The specific methods for mutating the fuzz test driver are as follows: The potential value of each API is assessed through energy allocation, and multiple mutation operations are intelligently applied based on this to reshape the behavior of the driver to cover previously unreached code areas; Energy calculation formula: energy(api) = (1 - cov(api)) × (1 - frequency(api)) × potential(api) Here, cov(api) represents the proportion of branches covered by the API, frequency(api) represents the frequency of API calls in the historical drive, and potential(api) measures the number of times the API appears in the multidimensional sequence, reflecting its semantic diversity and combinatorial potential. Based on energy assessment, MASFuzzer implements three core mutation operations, randomly selecting one in each iteration to apply to invalid drives: One is insertion mutation, which inserts the API with the highest current energy into a random position in the driver's call sequence, introducing new functionality or state operations; The second is replacement mutation, which selects a random segment of the current sequence and replaces it with an API with higher energy to change the data flow or execution logic; The third is combinatorial mutation, which randomly selects a subsequence from a multidimensional API sequence that has never been used and merges it with the current driver's sequence to construct a more complex and structured call chain.