Operating system kernel export function automated test generation platform and method

Abstract

The application provides an operating system kernel export function automatic test generation platform and method, comprising the following steps: (1) intelligent symbol extraction and analysis; (2) LLM driven test code generation; (3) automatic compilation and virtualization test; (4) intelligent error diagnosis and repair. The application greatly improves test coverage. Through multi-level symbol context extraction technology, not only single function information is extracted, but also the dependency relationship of related functions in the same element is analyzed and a function call graph and data flow analysis are constructed, rich context information is provided for LLM, and the problem of incomplete coverage of traditional manual test case writing is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of defensive technology in the field of software testing, in particular to a method for automatically generating test cases for exported functions of an operating system kernel and a platform for automatically generating test cases for exported functions of an operating system kernel. BACKGROUND

[0002] The Linux kernel, as the core of an operating system, contains a large number of exported functions (EXPORT_SYMBOL) for kernel modules to call. The quality of these functions directly affects the stability of the system and needs comprehensive test coverage. Traditional testing methods mainly include:

[0003] 1. Static code analysis: use tools such as Sparse, Coccinelle, etc. to check code quality;

[0004] 2. Manual test cases: developers write specific function tests based on experience;

[0005] 3. Fuzzing testing: use random input to test the robustness of functions;

[0006] 4. Unit test framework: kernel test frameworks such as KUnit.

[0007] Existing implementation schemes:

[0008] 1. Traditional kernel testing scheme:

[0009] Structure: includes static analysis tools, manual test scripts, and simple automation framework;

[0010] Workflow: developers manually write test cases → manually compile → test on real hardware or virtual machines;

[0011] Relationship: each component runs independently, lacking unified management and intelligent generation capabilities.

[0012] 2. Template-based code generation scheme:

[0013] Structure: pre-defined template library, parameterized generator, and basic compilation system;

[0014] Workflow: parse function signature → match pre-defined template → fill in parameters to generate code;

[0015] Relationship: template library and generator are tightly coupled, and the quality of the generated code is limited by the coverage of the templates.

[0016] Drawbacks of existing technology:

[0017] 1. Low degree of intelligence: existing schemes lack deep understanding of function semantics, and the generated test cases are often too simple or cannot cover complex scenarios.

[0018] 2. Poor scalability: Template-based solutions require manual maintenance of templates for each function type, making it difficult to adapt to the diversity and complexity of kernel functions.

[0019] 3. Insufficient error handling capabilities: Traditional solutions lack intelligent error diagnosis and automatic repair capabilities, and compilation or runtime errors require manual analysis and resolution.

[0020] 4. Complex test environment configuration: Existing tools lack automated QEMU virtualization test environment management, resulting in high environment setup and maintenance costs.

[0021] 5. Limited concurrent processing capabilities: Traditional solutions are mostly serial processing, which cannot fully utilize multi-core resources for large-scale parallel test generation. SUMMARY

[0022] The present application provides an operating system kernel export function automatic test generation method and platform to solve one or more of the above problems.

[0023] To achieve the above purpose, the present application adopts the following technical solutions:

[0024] An operating system kernel export function automatic test generation method, comprising the following steps:

[0025] (1) Intelligent symbol extraction and analysis: parse the component definition table through the Excel parser component to obtain the element-component-source file mapping relationship; the symbol extractor locates the source file corresponding to the target element and component based on the element-component-source file mapping relationship, and then extracts the EXPORT_SYMBOL (export symbol) function from the source file using regular expressions and AST analysis techniques to construct metadata information containing function signature, parameter type, and context dependency; at the same time, through compilation dependency information and AST analysis, extract the multi-level related functions called by the EXPORT_SYMBOL function, analyze the dependency relationship of the related functions within the same element, construct the function call graph and data flow, and form the multi-level symbol context;

[0026] (2) LLM-driven test code generation: the API client manager maintains multiple LLM API key pools, constructs intelligent prompt words containing the AST call relationship of the tested function, parameter constraints, and test requirements based on the multi-level symbol context, generates C language test module code conforming to the kernel development specification through the core LLM test generation engine, and realizes batch generation of test code in a thread concurrent manner;

[0027] (3) Automated compilation and virtualization testing: The module compiler invokes the kernel build system to automatically generate a Makefile (a text file) and compile the test module code in C language. A Docker QEMU TestRunner (QEMU virtualization test execution layer) creates an isolated ARM64 virtualization environment to load the compiled test module and execute it in parallel QEMU instances. The execution results, compilation errors, and runtime error information are collected.

[0028] (4) Intelligent error diagnosis and repair: The TestCaseFixManager (intelligent error repair manager) receives the execution results, compilation errors, and runtime error information. If the execution result is a test failure, it extracts key error points and identifies error feature patterns based on the compilation errors and runtime error information. It generates repair suggestions using the reasoning ability of the LLM and historical repair experience. For cases where a sub-function cannot be called at runtime, it automatically calls the core LLM test generation engine to generate a stub function, ensuring that the generated C language test module code can be compiled and the target function logic runs normally. It optimizes the test cases through iterative repair, and after each round of repair, it returns the modified test module code to step (3) for recompilation and execution to obtain new execution results until the execution result is a test pass or the iteration limit is reached.

[0029] In this specification, when the symbol extractor in step (1) locates the source file based on the element-component-source file mapping relationship, it specifically includes: parsing the source file path information recorded in the mapping relationship, combining the target elements and component source code directories marked in the component definition table, accurately locating the source file set storing the corresponding EXPORT_SYMBOL function, and ensuring the accuracy of the extraction range.

[0030] In this specification, the multi-level symbol context constructed in step (1) specifically includes: the directly called functions of the EXPORT_SYMBOL function, the indirectly called nested functions (depth not less than 3 layers), the parameter passing paths between functions, and the shared variable dependency relationships within the element functions. The above information is extracted and structured stored layer by layer through AST analysis technology.

[0031] In this specification, the thread pool and queue mechanism of the API client manager in step (2) specifically includes: 16 worker threads are created when the thread pool is initialized, and the task queue uses a priority queue structure. The priority is set according to the importance of the EXPORT_SYMBOL function corresponding to the test task (determined by the function call frequency), and high-priority tasks are preferentially assigned to idle threads.

[0032] In the specification, the intelligent prompt word constructed in step (2) specifically includes: metadata information of the measured function (function signature, parameter type), key call relationships in the multi-level symbolic context, mandatory verification items in the kernel test specification (such as memory leak checking, permission verification), and successful template fragments of historical test cases of similar functions.

[0033] In the specification, the process of generating Makefile by the module compiler in step (3) specifically includes:

[0034] Automatically read the kernel header file reference in the C language test module code generated in step (2), and combine the kernel version information of the current test environment (obtained by specifying the correct kernel source path) to generate Makefile containing the correct kernel source path and compilation options (such as -Wall-O2), to ensure compilation compatibility.

[0035] In the specification, the way in which the DockerQEMUTestRunner monitors the test process in step (3) specifically includes: real-time collection of CPU usage and memory usage (through the Dockerstats command) of each QEMU instance, setting of threshold (CPU usage ≥ 90% for 10 seconds or memory usage ≥ preset value), automatic sending of an interrupt signal to terminate the test process when the threshold is triggered, and avoidance of resource exhaustion.

[0036] In the specification, the error feature mode identified in step (4) specifically includes: syntax errors in the compilation phase (such as parameter type mismatch), linking errors (such as undefined symbols), runtime null pointer exceptions (segment error logs containing "NULL pointer dereference"), array out-of-bounds (containing "buffer overflow"), resource deadlocks (containing "lock contention timeout"), and the like, each mode corresponding to a preset feature keyword library.

[0037] In the specification, the strategy for 10 rounds of iterative repair in step (4) is specifically: the first to third rounds focus on repairing compilation errors (preferentially processing syntax and linking problems), the fourth to seventh rounds focus on repairing runtime errors (preferentially processing null pointers and segment errors), and the eighth to tenth rounds optimize the logical coverage of the test case (supplement boundary value testing and abnormal input testing), and the error feature mode matching library is updated after each round of repair.

[0038] An operating system kernel export function automatic test generation platform, which applies the operating system kernel export function automatic test generation method in any one of the above, the operating system kernel export function automatic test generation platform comprising:

[0039] The input processing layer is used for: parsing the component definition table through an Excel parser, obtaining an element-component-source file mapping relationship, positioning to the source file corresponding to the target element and component, extracting an exported symbol function from the source file to construct metadata information, simultaneously extracting a plurality of levels of related functions called by the exported symbol function, analyzing the dependency relationship of the related functions in the same element, constructing a function call graph and a data flow, and forming a plurality of levels of symbol contexts;

[0040] The core processing layer is used for: maintaining a plurality of LLM API key pools by an API client manager, constructing intelligent prompt words based on the plurality of levels of symbol contexts, and generating C language test module code through a core LLM test generation engine;

[0041] The code generation layer is used for: calling a kernel construction system through a module compiler, automatically generating a text file based on the C language test module code and compiling, and outputting the compiled test module; simultaneously receiving the test results fed back by the execution layer, and generating a test report through a report generator;

[0042] The execution layer is used for: creating an isolated ARM64 virtualization environment through a QEMU virtualization test execution layer, loading the test module in parallel through a QEMU instance and executing; monitoring the test process in real time, collecting execution results, compilation errors and runtime error information, and feeding back to the code generation layer and the repair layer, respectively;

[0043] The repair layer is used for: receiving the execution results, compilation errors and runtime error information output by the execution layer through an intelligent error repair manager; if the execution result is test failure, extracting a key error point and identifying an error feature mode in combination with the error information; generating a repair suggestion in combination with the inference ability of the LLM and historical repair experience; optimizing the test case through iteration repair, returning the modified test module code to the code generation layer for recompilation and execution after each round of repair, until the execution result is test pass or the iteration upper limit is reached.

[0044] In summary, the present application has at least the following beneficial effects:

[0045] The test coverage is greatly improved, the plurality of levels of symbol context extraction technology not only extracts single function information, but also analyzes the dependency relationship of the related functions in the same element and constructs a function call graph and a data flow analysis, providing rich context information for the LLM, and solving the problem of incomplete coverage of traditional manual test case writing.

[0046] The test case generation efficiency is significantly improved, the intelligent polling and dynamic load distribution strategy of 16 threads are adopted, 24 API keys are generated in parallel, the thread pool and queue mechanism are combined to realize efficient task scheduling, and the problem of long time consumption of manual generation and difficulty in adapting to kernel rapid iteration is solved.

[0047] Simplify the test environment configuration, automatically create an isolated ARM64 virtual machine environment through DockerQEMU TestRunner, support 12 parallel QEMU instances and real-time monitoring of test processes, solve the problem of complex traditional test environment construction and lack of automated execution framework.

[0048] Improve error repair efficiency and quality, error repair engine based on feature learning analyzes error mode features, combines LLM inference ability and historical repair experience to realize intelligent diagnosis, supports up to 10 rounds of iterative repair, solves the problem of manual analysis and iterative repair difficulty of compile and runtime errors.

[0049] Optimize the efficiency of large model application, extract key code through code Call-tree analysis and remove irrelevant information, combine text preprocessing and context compression technology to reduce the context length of large model and improve the output accuracy, solve the problem of low efficiency of large model dialogue mode and insufficient accuracy of general AI Agent generated code. BRIEF DESCRIPTION OF DRAWINGS

[0050] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0051] Figure 1 The flowchart of the operating system kernel export function automatic test generation method involved in the present application.

[0052] Figure 2 The architecture structure diagram of the Linux operating system kernel export function automatic test generation platform involved in the present application.

[0053] Figure 3 The partial core technology flowchart of the operating system kernel export function automatic test generation method involved in the present application.

[0054] Figure 4 Another partial core technology flowchart of the operating system kernel export function automatic test generation method involved in the present application. DETAILED DESCRIPTION

[0055] In the following, only some exemplary embodiments are simply described. As those skilled in the art can recognize, the described embodiments can be modified in various different ways without departing from the spirit or scope of the embodiments of the present application. Therefore, the drawings and description are considered to be exemplary rather than limiting.

[0056] The following disclosure provides many different embodiments, or examples, for implementing different structures of embodiments of the application. For the purpose of simplifying the disclosure of embodiments of the application, the components and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the embodiments of the application. In addition, the embodiments of the application can refer to the same reference numerals and / or reference letters in different examples, and such repetition is for the purpose of simplification and clarity, which does not indicate the relationship between the various embodiments and / or settings discussed.

[0057] The embodiments of the application will be described in detail below with reference to the accompanying drawings.

[0058] The operating system of the application is preferably a Linux operating system. Under the technical principles of the present application, other operating systems can also be implemented according to the application.

[0059] As Figure 1 shown, the present embodiment provides a method for automatically generating test of operating system kernel export function, comprising the following steps:

[0060] (1) Intelligent symbol extraction and analysis: parse the component definition table through the Excel parser component to obtain the element-component-source file mapping relationship; the symbol extractor is based on the element-component-source file mapping relationship, locates the source file corresponding to the target element and component, and then uses regular expressions and AST analysis technology to extract the EXPORT_SYMBOL function from these source files, and constructs metadata information containing function signature, parameter type and context dependency; At the same time, through the compilation dependency information and AST analysis, the multi-level related functions called by the EXPORT_SYMBOL function are extracted, the dependency relationship of the related functions within the same element is analyzed, the function call graph and data flow are constructed, and the multi-level symbol context is formed;

[0061] (2) LLM-driven test code generation: a plurality of LLM API key pools are maintained by an API client manager, and based on the multi-level symbol context obtained in step (1) (its accuracy depends on the EXPORT_SYMBOL function extracted accurately in step (1) based on the element-component-source file mapping relationship), an intelligent prompt word containing the AST call relationship of the tested function, parameter constraints and test requirements is constructed; a core LLM test generation engine (LLM Based Test Generator) is used to generate C language test module code conforming to the kernel development specification, and a 16-thread concurrent mode is used to realize batch generation of test code, wherein the API client manager realizes task scheduling through thread pool and queue mechanism;

[0062] (3) Automated compilation and virtualization testing: The module compiler invokes the kernel build system to automatically generate a Makefile for the C language test module code generated in step (2) and compile it. An isolated ARM64 virtualization environment is created by Docker QEMU TestRunner, and the compiled test module is loaded and executed in 12 parallel QEMU instances. The execution results (including test pass or fail status and detailed output), compilation errors, and runtime error information are collected, and the test process is monitored to prevent deadlocks and resource leaks.

[0063] (4) Intelligent error diagnosis and repair: The TestCaseFixManager receives the execution results, compilation errors, and runtime error information in step (3). If the execution result is a test failure, it extracts key error points and identifies error feature patterns in combination with the compilation errors and runtime error information. It generates repair suggestions based on the reasoning ability of the LLM and historical repair experience. For cases where a sub-function cannot be called at runtime, it automatically calls the core LLM test generation engine to generate a stub function based on the error context, ensuring that the C language test module code generated in step (2) can be compiled and the target function logic runs normally. It optimizes the test cases through up to 10 rounds of iteration, and returns the modified test module code to step (3) for recompilation and execution after each round of repair to obtain new execution results until the execution result is a test pass or the 10-round limit is reached. It also maintains repair history (including execution results, error types, and repair solutions) and success rate statistics to continuously optimize repair strategies.

[0064] In some embodiments, when the symbol extractor locates the source file based on the element-component-source file mapping relationship in step (1), it specifically includes: parsing the source file path information recorded in the mapping relationship, combining the target elements and the source code directory to which the components belong marked in the component definition table, and accurately locating the source file set storing the corresponding EXPORT_SYMBOL function to ensure the accuracy of the extraction range.

[0065] In some embodiments, the multi-level symbol context constructed in step (1) specifically includes: the direct call function of the EXPORT_SYMBOL function, the nested function (depth not less than 3 layers) of the indirect call, the parameter passing path between functions, and the shared variable dependency relationship with the functions within the element. The above information is extracted and structured stored layer by layer through AST analysis technology.

[0066] In some embodiments, the thread pool and queue mechanism of the API client manager in step (2) specifically includes: 16 worker threads are created when the thread pool is initialized, and the task queue adopts a priority queue structure, the priority is set according to the importance of the EXPORT_SYMBOL function corresponding to the test task (determined by the function call frequency), and high-priority tasks are preferentially allocated to idle threads.

[0067] In some embodiments, the intelligent prompt word constructed in step (2) specifically includes: metadata information (function signature, parameter type) of the function to be tested, key call relationships in multi-level symbolic context, mandatory verification items (such as memory leak checking, permission verification) in the kernel test specification, and successful template fragments of historical test cases of similar functions.

[0068] In some embodiments, the process of generating Makefile by the module compiler in step (3) specifically includes: automatically reading the kernel header file references in the C language test module code generated in step (2), combining the kernel version information of the current test environment (obtained by specifying the correct kernel source path command), generating Makefile containing the correct kernel source path, and compiling options (such as -Wall -O2), to ensure compilation compatibility.

[0069] In some embodiments, the way DockerQEMUTestRunner monitors the test process in step (3) specifically includes: real-time collection of CPU usage and memory usage (through the Docker stats command) of each QEMU instance, setting threshold values (CPU usage ≥ 90% for 10 seconds or memory usage ≥ preset value), and automatically sending an interrupt signal to terminate the test process when the threshold value is triggered, to avoid resource exhaustion.

[0070] In some embodiments, the error feature mode identified in step (4) specifically includes: syntax errors (such as parameter type mismatch) and linking errors (such as undefined symbols) in the compilation phase, null pointer exceptions (segment error logs containing "NULL pointer dereference"), array out-of-bounds (containing "buffer overflow"), and resource deadlocks (containing "lock contention timeout") in the runtime, etc., each mode corresponds to a preset feature keyword library.

[0071] In some embodiments, the strategy of 10 rounds of iterative repair in step (4) is specifically: the first to third rounds focus on repairing compilation errors (preferentially handling syntax and linking problems), the fourth to seventh rounds focus on repairing runtime errors (preferentially handling null pointers and segment errors), the eighth to tenth rounds optimize the logical coverage of the test case (supplement boundary value testing and abnormal input testing), and the error feature mode matching library is updated after each round of repair.

[0072] In some embodiments, the repair history maintained in step (4) specifically includes: the kernel version when the error occurs, the test module code segment (10 lines before and after the error location), the error feature mode label, the code change of the repair scheme (addition, deletion and modification content), the passing state of the test execution after repair, and the above information is stored in the local database in JSON format.

[0073] In some embodiments, the resource allocation mode of the 12 parallel QEMU instances in step (3) is specifically: according to the estimated resource requirement (based on the parameter size of the memory application function in the code) of the C language test module code generated in step (2), an independent CPU core (bound to a physical core) and a memory partition (isolated by cgroup) are allocated to each instance to avoid resource competition between instances.

[0074] The core technical process of the application (the process is as shown in Figure 3 and Figure 4 , and the overall architecture is as shown in Figure 2 ):

[0075] First stage: intelligent symbol extraction and analysis, preprocessing

[0076] 1. The Excel parser parses the component definition table, and extracts the element-component-source file mapping relationship;

[0077] 2. The symbol extractor uses regular expressions and AST analysis techniques to extract the EXPORT_SYMBOL function from the kernel source code;

[0078] 3. Build metadata information such as function signature, parameter type, and context dependency;

[0079] 4. Through the dependency information in the compilation information, the AST extracts the multi-level symbol related functions called by the EXPORT_SYMBOL function, not only extracts single function information, but also analyzes the dependency relationship of related functions within the same element and builds function call graphs and data flow analysis, providing rich context information for LLM;

[0080] Key technical innovation: multi-level symbol context extraction technology;

[0081] Not only extracts single function information, but also analyzes the dependency relationship of related functions within the same element;

[0082] Build function call graphs and data flow analysis to provide rich context information for LLM;

[0083] Second stage: LLM-driven test code generation

[0084] 1. API client manager maintains multiple LLM API key pools, achieving load balancing and failover;

[0085] 2. Test code generator builds AST call relationships and function definition contexts, parameter constraints, and test requirements for the function under test;

[0086] 3. Generate C language test module code that meets the kernel development specification through LLM;

[0087] 4. Support 16-thread concurrent generation, and achieve efficient task scheduling and resource management through thread pool and queue mechanism, greatly improving generation efficiency;

[0088] Key technical innovations: adaptive API load balancing mechanism;

[0089] Implement intelligent polling and fault detection of 24 API keys;

[0090] Adjust the load distribution strategy dynamically according to API response time and success rate;

[0091] Hierarchical parallel processing architecture;

[0092] Generate 16-thread concurrency in the generation layer, adaptive in the compilation layer, and 12-instance parallel in the test layer;

[0093] Efficient task scheduling and resource management through thread pool and queue mechanism;

[0094] Third stage: automated compilation and virtualization testing

[0095] 1. Module compiler automatically generates Makefile and uses the kernel build system to compile the test module;

[0096] 2. DockerQEMUTestRunner creates an isolated ARM64 virtual machine environment;

[0097] 3. Support 12 parallel QEMU instances, automatically load test modules and collect execution results;

[0098] 4. Real-time monitoring of test processes to prevent deadlocks and resource leaks;

[0099] Fourth stage: intelligent error diagnosis and repair

[0100] 1. TestCaseFixManager extracts relevant error points and provides different error feature patterns by analyzing GCC compilation errors and stdout (standard output) and stderr (standard error) information when running test cases in QEMU;

[0101] Key technical innovation: error repair engine based on feature learning (error feature pattern);

[0102] Analyze the pattern features of the compilation error and QEMU crash logs;

[0103] Integrate the reasoning ability of LLM and historical repair experience to realize intelligent error diagnosis;

[0104] 2. Use the code understanding ability of LLM to generate targeted repair suggestions for error features that occur during QEMU execution, and combine previous historical repair experience to realize intelligent error diagnosis;

[0105] Key technical innovation: integrate the reasoning ability of LLM and historical repair experience to realize intelligent error diagnosis;

[0106] Code Call-tree analysis, extract code that has direct call relationship with target function (object under test), which can greatly improve the output accuracy of large model; Traditional method: Generally read this source code file or engineering file, which has long context and is expensive, and long context will cause the performance and accuracy of the large model to decrease;

[0107] Remove definitions, functions, code comments, etc. that are irrelevant to the target test object;

[0108] For the case where the sub-function cannot be called at runtime, based on the error context (such as missing interface definition, link error, etc.), the large model can automatically generate a stub function to ensure that the compilation passes and the target function logic can run normally;

[0109] 3. Support up to 10 rounds of iterative repair to gradually improve test case quality;

[0110] 4. Maintain repair history and success rate statistics to continuously optimize repair strategies;

[0111] 5. Provide text preprocessing and sentence importance analysis, context compression techniques to reduce hallucinations, improve LLM repair quality and reduce token usage;

[0112] Key technical innovation: text preprocessing, technical details:

[0113] Advanced sentence segmentation: handle special cases of abbreviations (Dr. Mr. Inc.), numbers, and punctuation marks;

[0114] Text cleaning: uniform spacing, remove invalid characters, and maintain format consistency;

[0115] Basic statistics: calculate the number of sentences, average length, and vocabulary distribution;

[0116] Sentence importance analysis is evaluated using the following multi-dimensional sentence scoring mechanism. The higher the total score, the more important it is:

[0117] Total score = keyword density × 0.3 + position weight × 0.2 + length optimization × 0.2 + numerical features × 0.15 + language features × 0.15;

[0118] Context compression based on abstract, recursive summarization:

[0119] Compression strategy:

[0120] First round: sentence-level compression (retaining 60% of the sentences);

[0121] Second round: if still exceeds the target, compress to 70%;

[0122] Third round: final adjustment to ensure the target token number;

[0123] Principle: block → abstract → block again → abstract again, layer by layer;

[0124] Effect: 308 tokens → 43 tokens (14% compression ratio);

[0125] Advantages: maintain information coherence, high compression ratio;

[0126] Key information extraction (Key Information Extraction):

[0127] Principle: extract entities, relationships, and events, and structure them;

[0128] Effect: 308 tokens → 124 tokens (40% compression ratio);

[0129] Advantages: retain specific details, easy to answer accurately;

[0130] The key points and points to be protected of the invention are:

[0131] Key points:

[0132] 1. Kernel function semantic understanding and test generation method based on LLM: using large language model to analyze the semantics of kernel export function, and generating test cases conforming to the function logic;

[0133] 2. Multi-level concurrent processing architecture: realizing fine-grained parallel processing in symbol extraction, code generation, compilation testing and other stages to improve overall performance;

[0134] 3. Intelligent error diagnosis and iterative repair mechanism: automatic error repair method based on error feature recognition and LLM inference;

[0135] 4. Automation of virtualized test environment: Full automation of the process of dynamic creation of QEMU virtual machine instances, test execution, and resource cleanup.

[0136] In some embodiments, the intelligent symbol extraction and parsing phase:

[0137] 1. Excel parser adaptation optimization: For component definition tables, support.xls and.xlsx formats, preset table header verification rules (such as must contain "Element ID" "Component Name" "Source File Path" fields), automatically skip empty rows and format error rows during parsing, generate a standardized element-component-source file mapping table, and ensure the accuracy of the data source for subsequent symbol extraction.

[0138] 2. Multi-version adaptation of symbol extractor: For format differences in EXPORT_SYMBOL in different Linux kernel versions (such as 5.x, 6.x) (such as whether to include version suffix), built-in version identification module, automatically switch regular expression matching rules; AST analysis combined with kernel source macro definition (such as MODULE_LICENSE) to filter non-exported functions, improve extraction accuracy.

[0139] 3. Function call graph construction refinement: Use Graphviz tool to visualize the extracted function dependency relationship, label function parameter passing direction (such as "Function A→Function B" indicates A calls B), and support filtering and displaying by call depth (such as 1-3 layers), providing a more intuitive context reference for LLM.

[0140] In some embodiments, the LLM-driven test code generation phase:

[0141] 1. API client manager dynamic scheduling: 24 API keys are sorted by "response time + success rate" weighting (weight ratio 3:7), when a key fails continuously for 3 times, it is automatically moved to "recovery pool", and a new key is supplemented from the backup pool; when assigning tasks, complex function test generation tasks (such as parameter number ≥5) are preferentially assigned to API channels with response time <500ms.

[0142] 2. Intelligent prompt word hierarchical construction: The basic layer contains function signature and parameter constraints (such as "int func(int a, char* b), where a∈[0,100]"); the enhanced layer adds call examples of associated functions within the same element (such as "func must be initialized before calling init_func()"); the test specification layer embeds kernel test mandatory requirements (such as "must contain memory leak detection statement kfree()"), improving the compliance of LLM generated code.

[0143] 3.16 Thread concurrency optimization: thread pool is bound to independent CPU cores at initialization, and a "task fragmentation-result combination" mode is adopted, each thread is responsible for the function test generation of a specific module (such as division according to kernel subsystems "process management" and "memory management"), and intermediate results are transmitted through shared memory blocks to reduce thread communication overhead.

[0144] In some embodiments, the automated compilation and virtualization testing phase:

[0145] 1. Module compiler multi-environment compatibility: automatically detect the kernel source path of the current environment when generating Makefile (get the version by "specify the correct kernel source path -r", match the corresponding directory under / lib / modules), generate adaptive compilation options for GCC and Clang compilers respectively (such as "-mno-omit-leaf-frame-pointer" for GCC and "-fno-omit-frame-pointer" for Clang), and ensure that the test module is cross-compiler compilable.

[0146] 2. Docker QEMU TestRunner resource management: allocate a fixed resource pool (total memory ≤ 80% of host memory) for 12 parallel QEMU instances, each instance is initially allocated 2 cores of CPU and 2GB of memory, and when the test module code size ≥ 10KB, automatically expand to 4 cores of CPU and 4GB of memory; through the Docker health check mechanism (detect instance heartbeat every 30 seconds), when abnormal, automatically restart and reload the test module.

[0147] 3. Test process monitoring refinement: record the system call log of each QEMU instance in real time (through the strace tool), when "deadlock characteristic call sequence" (such as 10 times of pthread_mutex_lock not released in a row) or memory occupancy growth exceeds 50% within 5 minutes, automatically trigger process termination and save the scene log (including register state and memory snapshot).

[0148] In some embodiments, the intelligent error diagnosis and repair phase:

[0149] 1. Error feature mode library dynamic update: based on the error information collected by TestCaseFixManager, new error types are automatically clustered every week (such as adding a "use-after-free" mode), extract feature keywords (such as "use-after-free" in the error log) and update to the mode library, and at the same time, associate historical repair solutions to form an "error-repair" mapping table, to improve the first repair success rate.

[0150] 2.10 Round iteration repair strategy refinement: Set the repair time threshold for each round (≤5 minutes for the first 3 rounds, ≤10 minutes for the 4th-10th rounds), skip the current error if it exceeds the threshold; prioritize the repair of "blocking errors" (such as compilation errors that prevent execution), and then handle "non-blocking errors" (such as runtime warnings); perform a minimum test set (including 3 basic use cases) after each round of repair to verify effectiveness and avoid invalid iterations.

[0151] 3. Context compression technology landing: For the text preprocessing of kernel function documents, adopt the "keyword weighting + position weight adjustment" strategy - increase the keyword density weight of core terms such as "EXPORT_SYMBOL" and "parameter constraints" to 0.4, and increase the position weight of example code at the end of the document to 0.3 to ensure that key test information is retained after compression; prioritize retaining function call relationship descriptions during recursive summaries and eliminate redundant comments.

[0152] In some embodiments, the following are implemented:

[0153] 1. Multi-level symbolic context extraction: Develop a dedicated AST analysis plug-in to support the identification of "macro-defined exported functions" (such as define EXPORT_FUNC(func) EXPORT_SYMBOL(func)) in kernel source code, avoiding missed extraction; the constructed function call graph supports filtering by "call frequency" (such as retaining function relationships with call frequencies ≥5), reducing redundant information for LLM processing.

[0154] 2. Hierarchical parallel processing monitoring: Deploy a visual dashboard to display real-time generation layer thread utilization (target ≥80%), compilation layer success rate (target ≥90%), and test layer instance load (target CPU utilization ≤70%), and automatically trigger resource reallocation (such as adding 2 temporary compilation nodes for the compilation layer) when a layer's indicators are not met for 5 consecutive minutes.

[0155] In some embodiments, the symbolic extraction stage:

[0156] 1. Cross-format parsing adaptation upgrade: In addition to the existing.xls and.xlsx formats, support for CSV and ODS format component definition tables is added, with the corresponding parsing engine called through the format automatic identification module (based on file header byte characteristics). During parsing, field correlation checks are added, such as the "source file path" field must have logical matching with the "component name" (such as the "process scheduling" component corresponding to the path containing "sched / "), and unmatched items are marked as suspicious data and trigger manual review reminders.

[0157] 2. Symbol extraction precision improvement: For variant symbols such as EXPORT_SYMBOL_GPL, extend the regular matching rule library to distinguish between ordinary export symbols and GPL-specific symbols. Introduce function scope analysis in the AST analysis phase to filter export symbols that are only called within the module (by determining whether the function is referenced by external modules), reducing the amount of invalid symbol extraction. At the same time, generate a unique identifier for each extracted symbol (format: "kernel version-element ID-symbol name"), which facilitates subsequent full-process tracking.

[0158] In some embodiments, the LLM code generation:

[0159] 1. API client intelligent scheduling mechanism: Real-time monitoring of the response delay of each API key (sliding window mean calculation), when the delay of a key exceeds 1 second for 3 consecutive times, automatically reduce its task allocation weight (from 0.7 to 0.3). Configure a dedicated prompt word template for complex function test tasks (parameters ≥ 5 or containing pointer nesting), add a "memory safety constraint" module (such as "need to verify that the pointer is not empty before operating"), and associate the test specification document segment of the kernel subsystem where the function is located (such as the memory management subsystem needs to include slab allocator related tests).

[0160] 2. Thread pool dynamic scaling strategy: Automatically adjust the number of threads according to the length of the task queue, when the queue task number ≥ 20, temporarily expand to 24 threads (upper limit); when the queue is idle for more than 5 minutes, reduce to 8 threads. Use a lock-free queue to pass tasks between threads, and each thread binds an independent LLM session context to avoid context loss caused by session switching and improve generation continuity.

[0161] In some embodiments, the compilation and testing environment:

[0162] 1. Compiler adaptation depth optimization: The module compiler adds cross-compilation support for ARM, x86, and RISC-V architectures, automatically detects the target architecture when generating Makefile (through the "arch" environment variable), and adds architecture-specific compilation options (such as enabling "-marm" for ARM architecture and "-march=rv64gc" for RISC-V). For compatibility issues between kernel version and compiler version, a built-in version matching matrix is provided (such as kernel 6.1+ compatible with GCC12+), and when not matching, automatically recommend compatible versions or prompt for upgrade suggestions.

[0163] 2. Elastic scheduling of virtualized test resources: Docker QEMU TestRunner introduces a resource prediction model based on historical test data (correlation between code size, function complexity, and resource consumption) to estimate the resource requirements of each instance before testing. When the predicted memory requirement exceeds the single-instance upper limit, the test task is automatically split (e.g., a complex function test is split into three steps). At the same time, each QEMU instance is configured with an independent network namespace to avoid network request conflicts (e.g., port occupation) during testing.

[0164] In some embodiments, the error repair mechanism:

[0165] 1. Improved accuracy of error diagnosis: The error feature pattern library adds semantic analysis capabilities, not only matching keywords but also identifying error context logic (e.g., "null pointer exception" requires checking if the pointer is uninitialized based on its assignment location in the code). Introduce error impact range evaluation to mark whether the error will cause test interruption (e.g., "compilation failure" is high impact, "log warning" is low impact), and repair according to impact level.

[0166] 2. Optimization of iterative repair efficiency: In the 10 rounds of iteration, an adaptive adjustment mechanism is added. If the success rate of a certain round is ≥80%, the next round is automatically shortened (by 20%); if the success rate of the last two rounds is <30%, the iteration is suspended and the historical repair solution library is called for global matching. An error repair report is generated after each round of repair, including error type, repair code change amount, test pass rate, and other indicators to provide data support for subsequent optimization.

[0167] In some embodiments, full-process monitoring and feedback closed loop:

[0168] 1. Real-time tracking of key indicators: Deploy a monitoring center to collect real-time data on key indicators such as symbol extraction accuracy (target ≥95%), LLM code generation pass rate (target ≥85%), and test task completion rate (target ≥98%). When the indicators deviate from the threshold, trigger a hierarchical alarm (email, SMS, system popup) with an exception analysis (e.g., a decrease in extraction accuracy may be due to changes in the format of the new kernel version symbols).

[0169] 2. User feedback integration for optimization: Add a user feedback portal that allows testers to mark error repair results ("valid," "partially valid," "invalid") and provide improvement suggestions. Feedback data is analyzed monthly, and high-frequency issues (e.g., poor error repair results for a certain type of error) are prioritized for the next round of optimization, forming a closed-loop mechanism of "development - testing - feedback - optimization."

[0170] In some embodiments, surface fitting is applied in symbol extraction:

[0171] For the nonlinear relationship between "kernel version (x-axis), function call depth (y-axis), and extraction accuracy (z-axis)" in the symbol extraction process, a binary cubic polynomial surface fitting model is introduced:

[0172] 1. Data collection: Select 10 typical kernel versions (5.4 to 6.6), collect 50 sets of extraction accuracy data for each version according to call depth 1-5 layers, form a three-dimensional data set .

[0173] 2. Model construction: Fit the surface equation by least squares method , solve the coefficient matrix to determine the weight of each variable (such as the influence weight of kernel version on accuracy is about 0.35, and the call depth is about 0.42).

[0174] 3. Dynamic adjustment: Real-time input of current kernel version and preset call depth, prediction of extraction accuracy by fitting model, if the predicted value < 90%, automatically adjust the function filtering threshold of AST analysis (such as relaxing to 6 layers when the call depth is insufficient, and tightening the symbol matching rules when the version compatibility is poor), so that the actual accuracy is stable above 92%.

[0175] In some embodiments, the resource allocation optimization driven by surface fitting:

[0176] In the relationship between "test module code size (x-axis), number of concurrent instances (y-axis), and resource utilization (z-axis)" in virtualization testing, Gaussian process surface fitting is applied:

[0177] 1. Feature mapping: Take code size (KB) and instance number as input variables, and resource utilization (CPU+memory comprehensive utilization) as output, collect 200 sets of historical data to train the model, and capture the local correlation between variables through kernel function (RBF kernel).

[0178] 2. Optimal solution: Based on the gradient descent algorithm of the fitted surface, find the optimal solution with resource utilization ≥ 85% and no competition . For example, when the code size is 15KB, the model outputs the optimal instance number as 8 (when the traditional fixed 12 instances, the utilization rate is only 62%), accordingly, dynamically adjust the number of QEMU instances, and synchronously allocate the corresponding CPU core number (0.8 times the core number calculated by ) and memory (1.2 times reserved by ).

[0179] 3. Real-time calibration: Collect new running data every hour to update the fitted model, when the actual utilization rate deviates from the predicted value by > 5%, trigger model parameter fine-tuning (such as adjusting the kernel function bandwidth), ensure that the resource allocation is always in the efficient area of the surface.

[0180] In some embodiments, the surface fitting optimization of the error repair iteration:

[0181] For the surface relationship of "error type complexity (x-axis), iteration round (y-axis), and repair success rate (z-axis)", Bayesian optimization is combined with surface fitting:

[0182] 1. Type quantification: Quantify the error type according to complexity (syntax error = 1, null pointer exception = 3, deadlock = 5) as x value, iteration round 1-10 as y value, and collect repair success rate data of 100 kinds of errors.

[0183] 2. Probability surface fitting: Use Gaussian process regression to build a probability surface, output the mean and variance of the success rate given (x, y). For example, when x = 5 (deadlock), the surface shows that when y = 7 rounds, the mean success rate is 78% (variance < 10%), while when y = 5 rounds, the mean is only 52%.

[0184] 3. Iteration strategy adjustment: According to the fitting results, dynamically allocate the iteration round - low complexity error (x≤2) is terminated according to the optimal y value of the surface (usually 3-4 rounds), and high complexity error (x≥4) is extended to the saturated round predicted by the surface (such as 7-8 rounds). Compared with fixed 10 rounds of iteration, the average repair time is shortened by 35%, and the success rate is improved to 82%.

[0185] Implementation guarantee

[0186] 1. Data preprocessing: Standardize the collected data (normalize x and y axes to [0, 1], and keep the original percentage of z axis), eliminate outliers outside 3σ (such as extreme data caused by sudden resource fluctuations), and ensure fitting accuracy.

[0187] 2. Lightweight deployment: Compress the surface fitting model into a C language executable module (volume < 500KB), embed it in each control node, and the single prediction time is < 10ms, which does not affect the real-time performance of the original process.

[0188] 3. Visual monitoring: Real-time display of variable relationships through three-dimensional surface graphs, when the fitting error of a certain area is > 8%, it is automatically marked as "data sparse area" and triggers supplementary sampling, continuously optimizing the coverage range of the model.

[0189] In some embodiments, when a binary cubic polynomial surface fitting model is used in step (1) to optimize the accuracy of symbol extraction, it specifically includes:

[0190] Collect 50 sets of extraction accuracy rate data from 10 kernel versions (5.4 to 6.6) with call depth 1-5 layers, form a three-dimensional data set {(xᵢ, yᵢ, zᵢ)}, where x is the kernel version number, y is the function call depth, and z is the extraction accuracy rate;

[0191] The surface equation z = a0 + a1x + a2y + a3x2+ a4xy + a5y2+ a6x3+ a7x2y + a8xy2+ a9y3 is fitted by the least square method, and each coefficient weight is solved, wherein the kernel version influence weight is 0.35±0.05, and the call depth influence weight is 0.42±0.05;

[0192] Real-time input of the current kernel version and the preset call depth, if the model prediction accuracy is less than 90%, the function filtering threshold of the AST analysis is automatically adjusted as follows: the call depth is relaxed to 6 layers, and the symbol matching rule is tightened (the function parameter type checking is increased) when the version compatibility is poor, so that the actual extraction accuracy is stably above 92%.

[0193] In some embodiments, in step (3), when the Gaussian process surface fitting is used to optimize resource allocation, the following steps are specifically included:

[0194] 200 groups of historical running data are collected by taking the test module code amount (KB) as the x-axis, the number of concurrent QEMU instances as the y-axis, and the resource comprehensive utilization rate (CPU+memory) as the z-axis, and a Gaussian process model is constructed by using an RBF kernel function to capture the local correlation between variables;

[0195] The optimal solution (x0, y0) is solved based on the gradient descent algorithm of the fitted surface, and the resource utilization rate is greater than or equal to 85% and there is no competition, wherein when the code amount is 15 KB, the output optimal instance number is 8, and the corresponding allocated CPU core number is 0.8 times the code amount calculation value, and the memory is 1.2 times the code amount calculation value;

[0196] New running data is collected every hour to update the model, and when the actual utilization rate deviates from the predicted value by more than 5%, the RBF kernel function bandwidth is adjusted (from the initial 0.5 to 0.3-0.7), so that the resource allocation is in the efficient area of the surface.

[0197] In some embodiments, in step (4), when the Bayesian optimization is combined with the surface fitting to optimize error repair iterations, the following steps are specifically included:

[0198] The error types are quantified as x values according to complexity (syntax error = 1, null pointer exception = 3, deadlock = 5), and the iteration rounds 1-10 are taken as y values, and the repair success rate data of 100 kinds of errors are collected;

[0199] A probability surface is constructed by Gaussian process regression, and the mean and variance of the success rate under a given (x, y) are output, wherein when x = 5 (deadlock), the surface shows that the mean success rate is 78% and the variance is less than 10% when y = 7 rounds;

[0200] According to the fitting result, the iteration rounds are dynamically allocated: low complexity errors with x≤2 are terminated in y=3-4 rounds, high complexity errors with x≥4 are extended to y=7-8 rounds, which shortens the repair time by more than 35% compared to fixed 10 rounds of iteration.

[0201] In some embodiments, the resource utilization rate is calculated as the weighted sum of CPU utilization (weight 0.6) and memory utilization (weight 0.4), where CPU utilization is the average usage of 12 QEMU instances, and memory utilization is calculated based on "actual occupancy / total allocation".

[0202] In some embodiments, the quantification of error type complexity is based on: error associated code lines (accounting for 40%), involving function call layers (accounting for 30%), and historical repair average duration (accounting for 30%), which are weighted and summed to map to the x value range of 1-5.

[0203] In some embodiments, the data preprocessing step of surface fitting includes: normalizing x and y axis data to the [0,1] interval (x=(current value-minimum value) / (maximum value-minimum value)), and keeping the original percentage of z axis; removing outliers (such as data deviating from the mean by 3 times the standard deviation) by 3σ criterion to ensure the validity of the fitting model input data.

[0204] In some embodiments, the surface fitting model adopts a lightweight deployment method: the model is compressed into a C language executable module with a volume <500KB, embedded in each control node, with a single prediction time <10ms, and supports offline operation (preloading 1000 groups of historical fitting parameters).

[0205] In some embodiments, it also includes a surface fitting effect monitoring step: real-time display of the deviation of the fitted surface from the actual data points through a three-dimensional visualization interface, and when the fitting error of a certain area (such as x=6.0-6.2 kernel version, y=4-5 layer call) is >8%, it is automatically marked as "data sparse area" and triggers supplementary sampling (adds 20 groups of data in this area).

[0206] In some embodiments, the optimal solution also needs to satisfy the constraint condition: the number of CPU cores of a single QEMU instance ≤ 1 / 4 of the number of physical cores of the host, and the memory allocation ≤ 1 / 8 of the host memory, to avoid system instability caused by excessive resource allocation.

[0207] In some embodiments, the variance threshold of the probability surface is set to 15%, and when the prediction variance of a certain (x, y) point is >15%, the iteration resources are preferentially allocated (such as increasing the number of test samples for that point) to reduce the fitting uncertainty.

[0208] The application discloses an operating system kernel export function automatic test generation platform, and relates to the technical field of operating system kernel export function automatic test generation. Figure 2 As shown in the figure, the operating system kernel export function automatic test generation platform comprises:

[0209] An input processing layer is configured to parse a component definition table through an Excel parser, acquire an element-component-source file mapping relationship, locate to a source file corresponding to a target element and a component, extract an export symbol function from the source file to construct metadata information, simultaneously extract a plurality of levels of related functions called by the export symbol function, analyze a dependency relationship of the related functions within the element, construct a function call graph and a data flow, and form a plurality of levels of symbol contexts.

[0210] A core processing layer is configured to maintain a plurality of LLM API key pools by an API client manager, construct intelligent prompt words based on the plurality of levels of symbol contexts, and generate C language test module code through a core LLM test generation engine.

[0211] A code generation layer is configured to call a kernel construction system through a module compiler, automatically generate a text file based on the C language test module code and perform compilation, and output a compiled test module; and simultaneously receive test results fed back by an execution layer, and generate a test report through a report generator.

[0212] The execution layer is configured to create an isolated ARM64 virtualization environment through a QEMU virtualization test execution layer, load test modules in parallel through QEMU instances, and perform execution; monitor test processes in real time, collect execution results, compilation errors and runtime error information, and feed back the execution results, the compilation errors and the runtime error information to the code generation layer and a repair layer, respectively.

[0213] The repair layer is configured to receive the execution results, the compilation errors and the runtime error information output by the execution layer through an intelligent error repair manager; if the execution results are test failure, extract key error points and identify error feature patterns in combination with the error information; and generate repair suggestions in combination with inference capability of the LLM and historical repair experience.

[0214] Test cases are optimized through iterative repair, the modified test module code is returned to the code generation layer for recompilation and execution after each round of repair, and the process is repeated until the execution results are test pass or the iteration limit is reached.

[0215] The function architecture composition of each functional layer and the functions and interactions thereof are understood in combination with the description of the foregoing method, for example, the input processing layer comprises an Excel parser, a symbol extractor and an API client manager, and the functions and interactions thereof are described in detail in the principle description of the foregoing method steps.

[0216] The above-described embodiments are intended to illustrate, not to limit, the present application, and thus the modification of the example values or the substitution of equivalent elements should be within the scope of the present application.

[0217] From the above detailed description, it can be seen that the present application can achieve the aforementioned objects, and thus meets the requirements of the Patent Law.

[0218] Although the preferred embodiments of the present application have been described, those skilled in the art who have the benefit of the basic inventive concept can make additional changes and modifications to the embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application. The above description is merely preferred embodiments of the present application, and is not intended to limit the present application, and it should be noted that any modification, equivalent replacement and improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

[0219] It should be noted that the above description of the flow is merely for example and illustration, and does not limit the scope of the present application. Those skilled in the art can make various modifications and changes to the flow under the guidance of the present application. However, these modifications and changes are still within the scope of the present application.

[0220] The above has described the basic concept, and it is obvious that the above-mentioned application disclosure is only as an example and does not constitute a limitation on the present application for those skilled in the art after reading this application. Although it is not explicitly stated here, those skilled in the art can make various modifications, improvements and modifications to the present application. Such modifications, improvements and modifications are suggested in the present application, so such modifications, improvements and modifications are still within the spirit and scope of the exemplary embodiments of the present application.

[0221] Meanwhile, the present application uses specific words to describe the embodiments of the present application. For example, "one embodiment", "an embodiment", and / or "some embodiments" means a certain feature, structure or characteristic related to at least one embodiment of the present application. Therefore, it should be emphasized and noted that the "an embodiment" or "one embodiment" or "an alternative embodiment" mentioned in different positions in the specification does not necessarily refer to the same embodiment. In addition, some features, structures or characteristics in one or more embodiments of the present application can be properly combined.

[0222] Moreover, as will be appreciated by persons skilled in the art, the present aspects can be embodied in a variety of contexts and situations, and are described in connection with various examples, including any new and useful process, machine, manufacture, or composition of matter, or matter or any new and useful improvement thereof. Accordingly, the present aspects can be embodied in hardware alone, in software alone, including firmware, resident software, micro-code, etc., or in combinations of hardware and software. The above noted hardware or software can be referred to as a "unit," "module," or "system." Furthermore, the present aspects can take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0223] Computer program code for carrying out operations of the present aspects can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C, VB.NET, Python, conventional procedural programming languages, such as the C programming language, Visual Basic, Fortran 2103, Perl, COBOL 2102, PHP, ABAP, dynamic programming languages, such as Python, Ruby and Groovy, or another programming language. The program code can execute entirely on the user's computer, or it can be executed as a stand-alone software package, or it can execute partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any network, such as a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet) or within a cloud computing environment, or as a service, such as Software as a Service (SaaS).

[0224] In addition, the order of execution or sequence of processing elements and sequences, unless otherwise specifically denoted, is not limited to the described ordering but can be performed in any order practical. Although the above disclosure discusses some presently preferred embodiments of the application, it is to be understood that the details disclosed herein are by way of example and that other embodiments can be practiced. For example, although the implementation of various components described above can be embodied in hardware, it can also be implemented as a software only solution e.g. installed on an existing server or mobile device.

[0225] For similar reasons, it is to be appreciated that the teachings of the present application provided herein can be applied to any embodiment of the present application, and that actual claims applied for or patent granted can be broader than any single, featured embodiment. Accordingly, a patent applicant has constructed and filed examples to particularly point out and distinctly claim those aspects which are regarded as novel and those aspects specifically shown.

Claims

1. A method for operating system kernel export function automated test generation, characterized in that, The method comprises the following steps: (1) parsing the component definition table through an Excel parser to obtain an element-component-source file mapping relationship, positioning to the source file corresponding to the target element and component, extracting the exported symbol function from the source file to construct metadata information, extracting the multi-level related functions called by the exported symbol function, analyzing the dependency relationship of the related functions within the same element, constructing a function call graph and a data flow, and forming a multi-level symbol context; (2) an API client manager maintains a plurality of LLM API key pools, constructs intelligent prompt words based on the multi-level symbol context, generates C language test module code through a core LLM test generation engine, and realizes batch generation of test code in a concurrent manner, wherein the API client manager realizes task scheduling through a thread pool and a queue mechanism, and the intelligent prompt words specifically include: metadata information of the tested function, key call relationships in the multi-level symbol context, mandatory check items in the kernel test specification, and successful template fragments of historical similar function test cases; (3) a module compiler calls a kernel build system to automatically generate a text file and compile the C language test module code, creates an isolated ARM64 virtualization environment through a QEMU virtualization test execution layer, loads the compiled test module into a parallel QEMU instance and executes it, and collects execution results, compilation errors and runtime error information; (4) an intelligent error repair manager receives the execution results, compilation errors and runtime error information, extracts key error points and identifies error feature patterns if the execution result is test failure, generates repair suggestions combining the inference ability of the LLM and historical repair experience, optimizes the test case through iterative repair, returns the modified test module code to step (3) for recompilation and execution to obtain new execution results after each round of repair, and stops until the execution result is test passed or the iteration limit is reached.

2. The operating system kernel exported function automated test generation method of claim 1, wherein, In step (1), the symbol extractor locates the source file based on the element-component-source file mapping relationship, specifically including: parsing the source file path information recorded in the mapping relationship, combining the source code directory where the target element and component belong to as marked in the component definition table, accurately locating the source file set storing the corresponding exported symbol function, and ensuring the accuracy of the extraction range.

3. The operating system kernel exported function automation test generation method of claim 1, wherein, The multi-level symbol context constructed in step (1) includes: direct call functions of the exported symbol function, indirectly called nested functions, parameter passing paths between functions, and shared variable dependency relationships between functions within the same element. The above information is extracted and structured stored layer by layer through AST analysis technology.

4. The operating system kernel exported function automation test generation method of claim 1, wherein, The thread pool and queue mechanism of the API client manager in step (2) includes: creating 16 worker threads when initializing the thread pool, using a priority queue structure for the task queue, setting the priority according to the importance of the exported symbol function corresponding to the test task, and assigning high-priority tasks to idle threads first.

5. The operating system kernel exported function automation test generation method of claim 1, wherein, The module compiler in step (3) generates a text file, specifically including: automatically reading the kernel header file reference in the C language test module code generated in step (2), combining the kernel version information of the current test environment, generating a text file containing the correct kernel source code path and compilation options to ensure compilation compatibility.

6. The operating system kernel exported function automation test generation method of claim 1, wherein, The way in which the QEMU virtualization test execution layer monitors the test process in step (3) specifically includes: collecting the CPU usage and memory usage of each QEMU instance in real time, setting a threshold, and automatically sending an interrupt signal to terminate the test process when the threshold is triggered to avoid resource exhaustion.

7. The operating system kernel exported function automation test generation method of claim 1, wherein, The error feature patterns identified in step (4) specifically include: syntax errors and linking errors in the compilation phase, null pointer exceptions, array out-of-bounds, and resource deadlocks in the runtime, each pattern corresponding to a pre-set feature keyword library.

8. The operating system kernel exported function automation test generation method of claim 1, wherein, The 10-round iterative repair strategy in step (4) is specifically: the first to third rounds focus on repairing compilation errors, the fourth to seventh rounds focus on repairing runtime errors, and the eighth to tenth rounds optimize the logical coverage of test cases. Update the error feature pattern matching library after each round of repair.

9. An operating system kernel exported function automated test generation platform, comprising: The operating system kernel export function automatic test generation method according to any one of claims 1-8, the operating system kernel export function automatic test generation platform comprises: The input processing layer is used to parse the component definition table through the Excel parser, obtain the element-component-source file mapping relationship, locate the source file corresponding to the target element and component, extract the export symbol function from the source file to construct metadata information, and extract the multi-level related functions called by the export symbol function. Analyze the dependency relationship between the related functions in the same element, construct the function call graph and data flow, and form a multi-level symbol context; The core processing layer is used to: maintain multiple LLM API key pools by the API client manager, construct intelligent prompt words based on the multi-level symbol context, generate C language test module code through the core LLM test generation engine, and realize batch generation of test code in a concurrent manner. The API client manager realizes task scheduling through the thread pool and queue mechanism. The intelligent prompt words specifically include: metadata information of the function under test, key call relationships in the multi-level symbol context, mandatory verification items in the kernel test specification, and successful template fragments of historical similar function test cases. The code generation layer is used to: call the kernel build system through the module compiler, automatically generate a text file based on the C language test module code and perform compilation, and output the compiled test module; simultaneously receive the test results fed back by the execution layer, and generate a test report through the report generator; The execution layer is used to: create an isolated ARM64 virtualization environment through the QEMU virtualization test execution layer, load the test module in parallel QEMU instances and execute; monitor the test process in real time, collect execution results, compilation errors and runtime error information, and feed back to the code generation layer and the repair layer respectively; The repair layer is used for: receiving the execution result, the compilation error and the runtime error information output by the execution layer through the intelligent error repair manager; if the execution result is test failure, extracting a key error point and identifying an error feature mode in combination with the error information, generating a repair suggestion in combination with the inference ability of the LLM and historical repair experience; and optimizing the test case through iteration repair, returning the modified test module code to the code generation layer for recompilation and execution after each round of repair, until the execution result is test pass or the iteration upper limit is reached.

Images