C language unit test generation method based on reference test case

Abstract

The invention provides a C language unit test generation method based on a reference test case, and belongs to the field of software engineering. Comprising the following steps: constructing a C project symbol index knowledge base; performing test case migration association retrieval; and generating a test case based on the reference test mode. According to the method, the pairwise resource'application / release 'mode is extracted and forcibly applied from the existing test, so that the problem that memory leakage may be introduced into the generated C language test case is solved; by injecting the test mode extracted from the real code, the generated test case is highly consistent with the tested item in data structure initialization, function call agreement and code style, and the readability and maintainability of the test code are improved; the expert knowledge and the generation capability of the large language model are deeply fused, and the test environment establishment and resource cleaning work are fully automated, so that the cost and time for compiling a high-quality test for a complex C language project are remarkably reduced.

Description

TECHNICAL FIELD

[0001] The application provides a C language unit test generation method based on a reference test case, and belongs to the technical field of software engineering. BACKGROUND

[0002] In current software development, especially in the development of underlying systems such as operating systems and embedded systems, C language is widely used due to its high efficiency. To ensure the quality and reliability of C code, unit testing is an indispensable key link.

[0003] In order to solve the problem of low efficiency of manually writing unit tests, researchers and industry have proposed some automatic test generation methods, which mainly include:

[0004] 1. Traditional automatic test generation techniques: This kind of technique does not depend on large language models, and mainly generates tests through program analysis.

[0005] (a) Generation techniques based on search and randomness: This method explores the execution paths of the program by using search algorithms (such as genetic algorithms) or feedback-oriented random testing to maximize code coverage and other indicators. For example, search-based software testing (SBST) technology is widely studied for automatic generation of test suites [1] .

[0006] (b) Generation techniques based on symbolic execution: This method symbolizes the program input, analyzes the reachability of the program path, and systematically generates test cases that can cover specific paths. The famous tools for C language include KLEE [2] and DART (Directed Automated Random Testing) [3] . They are very effective in discovering deep bugs.

[0007] 2. Generation techniques based on large language models (LLM): In recent years, with the breakthrough of large language models (such as GPT series) in code understanding and generation, researchers have begun to try to use them to directly generate test code for target functions. This method usually provides the source code of the function to be tested to the model by constructing a prompt, and instructs it to generate the corresponding unit test [4] .

[0008] Although the existing methods have promoted the automation of test generation to some extent, they still have obvious limitations when applied to C language projects: First, C language has underlying characteristics such as manual memory management, complex pointer operations, and lack of built-in exception mechanisms. Techniques based on search and randomness[1] The generated test cases often only focus on the coverage of the function logic, and easily ignore the verification of the matching of memory allocation (malloc) and release (free), which may cause the test itself to have a memory leakage problem, and cannot effectively find the core security risks in the C code. Secondly, the technology based on symbolic execution, such as KLEE [2] , although powerful, when facing C code containing complex loops, pointer aliasing or external library calls, it is very easy to produce the "path explosion" problem, which leads to a sharp increase in analysis time and memory overhead, and is difficult to apply to large or complex practical projects. Finally, the current method of directly using a large language model to generate C language tests [4] , although convenient, due to the lack of deep understanding of the overall context of the project (such as global variables, macro definitions, project-specific data structure usage specifications, etc.), the generation quality is uneven. Empirical studies have shown [5] that this "zero context" or "shallow context" method generates code with low compilation pass rate, poor logic correctness, and also cannot guarantee memory safety. The current advanced LLM generation technology in the field of C language testing success rate and quality far from meet the requirements of industrial applications. SUMMARY

[0009] The present application aims to solve the problems of low automation, inability to guarantee memory safety, and low generation quality of existing C language unit test generation techniques, and proposes a C language unit test generation method based on reference test cases.

[0010] The main objectives of the present application include:

[0011] (1) Solve the problem that traditional automated tools cannot effectively handle the complexity of C language memory management and pointers, and ensure that the generated test cases are memory safe.

[0012] (2) The present application aims to solve the problems of low automation, inability to guarantee memory safety, and low generation quality of existing C language unit test generation techniques, and proposes a C language unit test generation method based on reference test cases.

[0013] (3) Provide a complete automated process that can efficiently generate unit tests for C language functions that meet project coding standards and best practices, thereby improving software development and testing efficiency.

[0014] The present application designs and implements a C language unit test generation method based on reference test cases, including the following steps:

[0015] S1. C project symbol index knowledge base construction: First, conduct a deep static analysis of the entire C language project to construct a project code knowledge base containing information such as functions, data structures, and dependency relationships.

[0016] S2. Test case migration association retrieval: When a test for a target function is needed, the system retrieves functions with strong associations and their existing test cases in the knowledge base according to the preset test template reuse rules. The retrieved test cases are structured and decomposed to extract the three-part test pattern (Setup-Execute-Verify) of resource preparation, function execution, result verification, and resource cleanup.

[0017] S3. Test case generation based on reference test pattern: Merge the target function information with the extracted test pattern to construct a context-injection instruction template, which guides the large language model to generate a high-quality, memory-safe new unit test case.

[0018] The details of the above steps are described below.

[0019] S1. C project symbol index knowledge base construction, specifically including the following steps:

[0020] S1.1 Symbol index extraction

[0021] Perform a comprehensive offline scan of the entire C language project to establish a global symbol index knowledge base. The system will traverse all source files and header files in the project, extract the following key information using static analysis tools, and store it in a structured manner:

[0022] (1) File-level information: Record the path of each file and which other header files are included by the file through the #include directive.

[0023] (2) Function definition: Store the complete signature of all global functions, including their return type, function name, parameter list, and the source file location where the function definition is located.

[0024] (3) Data structure definition: Store the complete definition of all structs, unions, and enums, including their members and the header file location where they are defined.

[0025] (4) Global variable declaration: Record global variables declared through the extern keyword or defined at the top level of the file.

[0026] (5) Type definition: Record all custom type aliases created through typedef.

[0027] This symbol index knowledge base constitutes a project's "symbol index", which allows fast lookup of any function, type or variable definition without full compilation.

[0028] S1.2 Lightweight Context-Aware Reference Resolution

[0029] The process is as follows:

[0030] (1) Identify Unresolved References: When analyzing the AST of a target function, identify all symbols (function names, type names, etc.) that cannot be found in the current compilation unit.

[0031] (2) Query the Symbol Index Knowledge Base: For each unresolved reference, the system queries the previously constructed global symbol index knowledge base to find the authoritative definition of the symbol.

[0032] (3) Context Completion: Dynamically inject the definition information (such as the function signature of external_func, the definition of the struct it uses, etc.) into the current analysis context.

[0033] S2. Test Case Generation Based on Reference Test Patterns

[0034] This process consists of two core stages: First, identify the test case migration association between the function to be tested and other functions according to the test template reuse rules; then, extract the three-part test pattern for the test cases of the associated functions.

[0035] S2.1 Definition of Test Template Reuse Rules

[0036] The invention defines a set of test template reuse rules for C language to identify existing test cases that can provide templates for new tests. The rules include:

[0037] (1) Core data structure operation association;

[0038] (2) Resource life cycle closed loop association;

[0039] (3) Functional similarity or dependency association;

[0040] S2.2 Three-Part Test Pattern Extraction

[0041] After retrieving the associated test cases, the system extracts the structured three-part test pattern (Setup-Execute-Verify) and performs deep adaptation for C language characteristics:

[0042] (1) Setup (Preparation phase): This phase focuses on setting up the test environment.

[0043] (2) Execute (Execution Phase): This phase is the core of the test, mainly extracting direct call statements to the function under test.

[0044] (3) Verify (Verification and Cleanup Phase): This phase is responsible for verifying behavior and ensuring no side effects.

[0045] S3. Instruction Construction Based on Reference Test Patterns

[0046] This process builds two key technologies through association priority ranking and context-injection instruction templates, ensuring that LLM can generate high-quality unit tests that meet C language safety specifications and project conventions.

[0047] S3.1 Association Priority Ranking

[0048] A set of priority ranking mechanisms is introduced:

[0049] (1) Association Strength Ranking: The system sorts the retrieved patterns based on the reuse rule types defined in step S2.1. Generally, "core data structure operation association" has the highest priority, as it directly relates to test data preparation and cleanup and is the main body of test logic; second is "resource life cycle loop association", which is crucial for ensuring memory safety; and last is "functional similarity or dependency".

[0050] (2) Pattern Integrity Ranking: The system assesses the integrity of each test pattern based on the completeness of resource acquisition and release pairs, the number and type coverage of assertions, and the completeness of environment initialization steps. A pattern that includes clear Setup (preparation) and Verify (cleanup) logic has a significantly higher priority than a pattern with only one stage of logic. A complete "malloc / free pair" pattern is much more valuable than a standalone malloc pattern.

[0051] (3) Pattern Fusion Strategy: For multiple reference patterns ranked high, the system can adopt a fusion strategy to take advantage of each other's strengths.

[0052] S3.2 Construction of Context-injection Instruction Templates

[0053] The construction process of the template is as follows:

[0054] (1) Define the basic framework: First, create an instruction framework that includes role definition, task target, context of the function under test, and output format requirements.

[0055] (2) Injecting symbol definitions: The key struct definitions, enum types, extern global variable declarations, etc. that the function under test depends on, which are queried from the symbol index library, are directly embedded into the context of the template.

[0056] (3) Injecting reference test best practice patterns: The three-segment test patterns (code snippets of Setup and Verify phases) sorted and fused in step S3.1 are injected as mandatory instructions.

[0057] The beneficial effects brought by the technical scheme of the present application are:

[0058] 1. Improving memory safety: By extracting and forcibly applying the paired resource "application / release" patterns (such as malloc / free) from existing tests, the present application fundamentally solves the pain point of memory leakage that may be introduced by the test cases generated by the prior art, ensuring the robustness of the test code itself.

[0059] 2. Enhancing test case consistency: By injecting test patterns extracted from real code, the test cases generated by the present application are highly consistent with the project under test in terms of data structure initialization, function call conventions, and code style, greatly improving the readability and maintainability of the test code, and making it meet the industrial application standards.

[0060] 3. Improving automation efficiency: The present application deeply integrates expert knowledge in the field of software engineering with the generation capability of large language models, fully automates the most tedious and error-prone test environment setup (Setup) and resource cleanup (Cleanup) work, and significantly reduces the cost and time of writing high-quality tests for complex C language projects. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 The flowchart of the present application. DETAILED DESCRIPTION

[0062] The present application designs and implements a C language unit test generation method based on reference test cases, and the overall workflow framework is as shown in Figure 1 The main includes three core processes:

[0063] S1. C project symbol index knowledge base construction: First, perform a deep static analysis of the entire C language project to construct a project code knowledge base containing information such as functions, data structures, and dependencies.

[0064] S2. Test Case Migration Association Retrieval: When generating tests for a target function, the system retrieves strongly associated functions and their existing test cases from the knowledge base based on pre-set test template reuse rules. The retrieved test cases are structured and decomposed to extract the three-part test pattern (Setup-Execute-Verify) of resource preparation, function execution, result verification, and resource cleanup.

[0065] S3. Test Case Generation Based on Reference Test Pattern: The target function information is merged with the extracted test pattern to construct a context-injection instruction template, which guides the large language model to generate a high-quality, memory-safe new unit test case.

[0066] The details of the above steps are described below.

[0067] S1. C Project Symbol Index Knowledge Base Construction

[0068] This step aims to provide comprehensive background knowledge for subsequent analysis and generation, and its core is to construct a structured symbol index knowledge base to support accurate parsing of cross-file references in C language projects. The code context of C language is scattered in different source files (.c) and header files (.h), and traditional single-file analysis methods cannot obtain complete semantic information. The context analysis step of the invention solves this problem through the following process.

[0069] S1.1 Symbol Index Extraction

[0070] The goal of this step is to perform a comprehensive offline scan of the entire C language project and establish a global symbol index knowledge base. The system will traverse all source files and header files in the project, use static analysis tools (such as Clang-based AST parser) to extract the following key information, and store it in a structured manner:

[0071] · File-level information: Records the path of each file and which other header files are included by the file through the #include directive.

[0072] · Function definition: Stores the complete signature of all global functions, including its return type, function name, parameter list, and the source file location where the function definition is located.

[0073] · Data structure definition: Stores the complete definition of all structs, unions, and enums, including their members and the header file location where they are defined.

[0074] · Global variable declaration: Records global variables declared by the extern keyword or defined at the top level of the file.

[0075] • Typedefs: Records all custom type aliases created via typedef.

[0076] This symbol index knowledge base constitutes a project's "symbol index", allowing fast lookup of any function, type or variable definition without full recompilation.

[0077] Suppose there is one source file utils.c in the project as follows:

[0078] Table 1: Source file utils.c

[0079]

[0080] After the system performs symbol index extraction, the knowledge base will contain the following structured information entries:

[0081] • Typedefs:

[0082] o Name: DataPacket

[0083] o Original type: struct { char* data; int id;}

[0084] o Definition location: utils.c, line 5

[0085] • Function definitions (Function):

[0086] o Name: create_packet

[0087] o Signature: DataPacket* create_packet(const char* content)

[0088] o Definition location: utils.c, line 10

[0089] • Function definitions (Function):

[0090] o Name: free_packet

[0091] o Signature: void free_packet(DataPacket* pkt)

[0092] o Definition location: utils.c, line 17

[0093] With this knowledge base, even when analyzing another file that calls create_packet, the system can immediately obtain its complete function signature and the detailed definition of the DataPacket type it operates on by querying the knowledge base. This provides a solid data foundation for cross-file context understanding and dependency analysis.

[0094] S1.2 Lightweight Context-Aware Reference Resolution

[0095] When generating test cases for a target function, the present invention needs to analyze the function and the code fragments related to it. These code fragments often contain external references that are not defined in the current file (e.g., calling a function defined in another.c file, or using a struct defined in a.h file).

[0096] This step aims to resolve these external references in real-time and lightweight, providing a complete context for subsequent analysis. The process is as follows:

[0097] 1. Identify Unresolved References: When analyzing the AST of the target function, identify all symbols (function names, type names, etc.) that cannot be found in the current compilation unit.

[0098] 2. Query Symbol Index Knowledge Base: For each unresolved reference, the system queries the previously constructed global symbol index knowledge base to find the authoritative definition of the symbol. For example, if the code calls the function external_func(), the system will look up the function signature of external_func() and the source file it is in in the database.

[0099] 3. Context Completion: Dynamically inject the definition information (such as the function signature of external_func(), the definition of the struct it uses, etc.) into the current analysis context.

[0100] For example, when analyzing the function foo() in moduleA.c, foo() calls the function bar() defined in moduleB.c and uses the struct my_data defined in common.h. When analyzing foo(), both bar and my_data are unresolved references. This step will query the symbol index knowledge base to find the complete function signature of bar() (defined in moduleB.c) and the complete definition of struct my_data (defined in common.h). These missing definition information will be provided to the subsequent test generation module, allowing the LLM to fully understand the behavior and dependencies of foo().

[0101] By this way of "global offline index + real-time dynamic query", the application ingeniously solves the problem of C language context dispersion, and accurately applies it to the characteristics of C language #include dependency and cross-file call. This lays a solid foundation for subsequent accurate identification of reference relationship.

[0102] S2. Test case generation based on reference test pattern

[0103] This process aims to mine reusable and high-quality test templates from the existing test suites in the project. This process consists of two core stages: first, according to the test template reuse rules, identify the test case migration association between the function to be tested and other functions; then, extract the three-section test pattern of the test case of the associated function.

[0104] S2.1 Definition of test template reuse rules

[0105] The application defines a set of test template reuse rules for C language to identify existing test cases that can provide templates for new tests. The rules include:

[0106] 1. Core data structure operation association: if multiple functions all use a pointer to the same core struct as their main operation object, then these functions constitute a strongly associated "function family".

[0107] 2. Resource life cycle closed loop association: there are a large number of resources that need to be manually managed in C language. For example, the file operation functions FILE* open_config(const char* path) and void close_config(FILE* fp) constitute an "open / close" logical closed loop for file handle resources in terms of functionality. The test case of open_config shows how to handle file paths and check if the return value is NULL; while the test case of close_config shows how to safely close the handle. These two test cases together constitute a complete file I / O test template.

[0108] S2.2 Three-section test pattern extraction

[0109] After retrieving the associated test cases, the system extracts the structured three-section test pattern (Setup-Execute-Verify) and performs deep adaptation according to the characteristics of C language:

[0110] (1) Setup (Preparation Phase): This phase focuses on setting up the testing environment. C language-specific example: For a use case of testing a network packet processing function, the Setup phase might include: uint8_t* buffer = (uint8_t*)malloc(PACKET_SIZE); for memory allocation, and memcpy(buffer, mock_packet_data, PACKET_SIZE); for filling packet content. These statements form a reusable "packet preparation" template.

[0111] (2) Execute (Execution Phase): This phase is the core of the test, mainly extracting direct calls to the function under test.

[0112] (3) Verify (Verification and Cleanup Phase): This phase is responsible for verifying behavior and ensuring no side effects. Example: Continuing the above example, the Verify phase might include: assert(parse_result == SUCCESS); for verifying the return value, and most importantly, free(buffer); for cleaning up resources. A key point of the invention is to ensure that the malloc in the Setup phase and the free in the Verify phase are strictly paired and extracted, forming a complete memory safety test pattern.

[0113] This step is the core output link of the entire method. This process builds two key technologies through association priority sorting and context-injected instruction templates, ensuring that the LLM can generate high-quality unit tests that meet C language safety specifications and project conventions.

[0114] S3. Instruction construction based on reference test patterns

[0115] This step is the core output link of the entire method, aiming to efficiently "inject" all context information and test patterns analyzed and extracted in the previous steps into the generation process of large language models (LLM). This process builds two key technologies through association priority sorting and context-injected instruction templates, ensuring that the LLM can generate high-quality unit tests that meet C language safety specifications and project conventions.

[0116] S3.1 Association priority sorting

[0117] In the S2 step, the system may retrieve multiple test cases related to the target function that contain test patterns. However, the "reference value" of these patterns is not equal. In order to let the LLM preferentially learn the most relevant and highest quality patterns, the system introduces a priority sorting mechanism:

[0118] 1. Association strength ranking: The system ranks the retrieved patterns according to the multiplexing rule types defined in step S2.1. Generally, the "core data structure manipulation association" has the highest priority, as it is directly related to the preparation and cleanup of test data and is the main body of the test logic; the "resource life cycle closure association" is second, as it is crucial for ensuring memory safety; and the "functional similarity or dependency" is last.

[0119] 2. Pattern completeness ranking: The system evaluates the completeness of each test pattern. A pattern that contains both clear Setup and Verify logic has a significantly higher priority than a pattern that only has one stage of logic. A complete "malloc / free pair" pattern is much more valuable than an isolated malloc pattern.

[0120] 3. Pattern fusion strategy: For multiple reference patterns with high rankings, the system can employ a fusion strategy to take the best of both worlds. For example, extract the complex data initialization logic of the Setup phase from pattern A, and the more rigorous multiple assertion logic of the Verify phase from pattern B, and combine them into a more comprehensive "fused pattern".

[0121] Through ranking and fusion, the system ensures that the LLM is provided with the most essential and directly relevant guidance information.

[0122] S3.2 Construction of context-injection instruction template

[0123] One of the cores of the invention is to construct a "context-injection instruction template". Unlike ordinary prompts that simply splice code and problems together, the template of the invention is a highly structured, multi-part instruction set designed to break down complex test generation tasks into sub-tasks that are easier for the LLM to understand and execute.

[0124] The construction process of the template is as follows:

[0125] 1. Define the basic framework: First, create an instruction framework that includes role definitions, task objectives, the context of the function to be tested, and output format requirements.

[0126] 2. Inject symbol definitions: Directly embed the key struct definitions, enum types, extern global variable declarations, etc. that the function to be tested depends on, which are queried from the symbol index library, into the context of the template.

[0127] 3. Inject reference test best practice patterns: Inject the three-stage test patterns (code snippets of Setup and Verify phases) that have been ranked and fused in step S3.1 as mandatory instructions.

[0128] Suppose the target function of the present application is user_set_age(struct user* u, int new_age). The system will dynamically construct the following instruction template:

[0129] Table 2: Construction process of context-injected instruction template

[0130]

[0131]

[0132]

[0133] In this way of injecting the deterministic knowledge of static analysis (symbolic definition) and the best practice of dynamic mining (test pattern) as hard constraints into the instruction template, the present application transforms LLM from a free "code completion tool" into a "test code generation engine" that follows strict C language safety engineering specifications, thereby stably outputting high-quality and highly reliable unit tests.

[0134] The core method of the present application does not depend on any specific LLM. Various large code models publicly available in the industry can be used, such as the GPT series, Claude series, Code Llama series, or other models fine-tuned for code instructions. Different models may differ in generation effect and cost, and can be selected and replaced according to actual application scenarios.

[0135] In addition to the rules based on data structures and resource lifecycles proposed in this embodiment, more reference rules can be defined according to the characteristics of specific projects, such as "functions sharing the same callback function type", "functions handling the same protocol messages", etc. These rules can be dynamically extended as plug-ins to adapt to different project requirements.

[0136] The present application needs to use static analysis technology in the context analysis step. Different tools can be used, such as Clang-based tools, Joern, or other open source / commercial C code analyzers, as long as they can accurately extract the required meta-information.

Claims

1. A C language unit test generation method based on reference test cases, characterized by, Comprising the following steps: S1.C project symbol index knowledge base construction: first, the entire C language project is analyzed in depth, and a project code knowledge base containing function, data structure, dependency relationship and other information is constructed; S2.Test case migration association retrieval: when a test needs to be generated for a target function, the system retrieves the function with strong association and its existing test cases in the knowledge base according to the preset test template reuse rules; the retrieved test cases are structured and decomposed, and the three-part test mode of resource preparation, function execution, result verification and resource cleaning is extracted; S3.Test case generation based on reference test mode: the target function information and the extracted test mode are fused to construct a context injection instruction template, which guides the large language model to generate a high-quality, memory-safe new unit test case.

2. The C language unit test case generation method based on reference test cases according to claim 1, characterized in that, S1 specifically includes the following sub-steps: S1.1 Symbol index extraction A comprehensive offline scan of the entire C language project is performed to establish a global symbol index knowledge base; the system will traverse all source files and header files in the project, extract the following key information using static analysis tools, and store it in a structured manner: (1) File-level information: records the path of each file and which other header files are included by the file through the #include directive; (2) Function definition: stores the complete signature of all global functions, including its return type, function name, parameter list, and the source file location where the function definition is located; (3) Data structure definition: stores the complete definition of all structs, unions and enums, including their members and the header file location where they are defined; (4) Global variable declaration: records global variables declared by the extern keyword or defined at the top level of the file; (5) Type definition: records all custom type aliases created by typedef; This symbol index knowledge base constitutes a project's "symbol index", which allows quick querying of the definition of any function, type or variable without full compilation; S1.2 Light context-aware reference resolution The process is as follows: (1) Identify unresolved references: when analyzing the AST of the target function, identify all symbols that cannot be found in the current compilation unit; (2) Query the global symbol index knowledge base: for each unresolved reference, the system queries the previously constructed global symbol index knowledge base to find the authoritative definition of the symbol; (3) Context completion: dynamically inject the definition information found into the current analysis context.

3. The method of claim 1, wherein the method is characterized by, S2 is divided into two core stages: first, according to the test template reuse rules, identify the test case migration association between the function to be tested and other functions; Then, extract the three-part test mode of the test cases of the associated functions; S2.1 Definition of test template reuse rules (1) Core data structure operation association; (2) Resource life cycle closed loop association; (3) Functional similarity or dependency association; S2.2 Three-part test mode extraction After retrieving the associated test cases, the system extracts the structured three-phase test pattern and deeply adapts it to the C language characteristics: (1) Preparation phase: This phase focuses on the construction of the test environment; (2) Execution phase: This phase is the core of the test, mainly extracting direct call statements to the tested function; (3) Verification and cleanup phase: This phase is responsible for verifying behavior and ensuring no side effects.

4. The C language unit test case generation method based on reference test cases according to claim 3, characterized in that, S3 builds two key technologies through association priority ranking and context-injected instruction templates, including: S3.1 Association priority ranking (1) Association strength ranking: The system ranks the retrieved patterns according to the reuse rule types defined in step S2.1; (2) Pattern completeness ranking: The system evaluates the completeness of each test pattern based on the paired completeness of resource requests and releases, the number and type coverage of assertions, and the completeness of environment initialization steps; (3) Pattern fusion strategy: For multiple reference patterns ranked at the top, the system adopts a fusion strategy to make up for each other's shortcomings; S3.2 Construction of context-injected instruction templates (1) Define the basic framework: First, create an instruction framework that includes role definitions, task objectives, tested function contexts, and output format requirements; (2) Inject symbol definitions: Directly embed the key struct definitions, enum types, and extern global variable declarations that the tested function depends on from the symbol index library into the context of the template; (3) Inject reference test best practice patterns: Inject the three-phase test patterns sorted and fused in step S3.1 as mandatory instructions.

Images