Platform and method for automatically testing and generating kernel export function of operating system

Abstract

The invention provides an automatic test generation platform and method for an operating system kernel derived function. The method comprises the following steps: (1) intelligent symbol extraction and analysis; (2) generating an LLM-driven test code; (3) performing automatic compiling and virtualization testing; and (4) intelligent error diagnosis and repair. According to the method, the test coverage degree is greatly improved, through the multi-level symbol context extraction technology, single function information is extracted, the dependency relationship of related functions in the same element is analyzed, a function call graph and data flow analysis are constructed, rich context information is provided for LLM, and the problem that traditional manual test case writing is incomplete in coverage 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: 1. Static code analysis: use tools such as Sparse, Coccinelle, etc. to check code quality; 2. Manual test cases: developers write specific function tests based on experience; 3. Fuzzing testing: use random input to test the robustness of functions; 4. Unit testing framework: kernel testing frameworks such as KUnit.

[0003] Existing implementation schemes: 1. Traditional kernel testing scheme: Structure: includes static analysis tools, manual test scripts, and simple automation framework; Workflow: developers manually write test cases → manually compile → test on real hardware or virtual machines; Relationship: each component runs independently, lacking unified management and intelligent generation capabilities.

[0004] 2. Template-based code generation scheme: Structure: pre-defined template library, parameterized generator, and basic compilation system; Workflow: parse function signature → match pre-defined template → fill in parameters to generate code; Relationship: template library and generator are tightly coupled, and the quality of the generated code is limited by the coverage of the templates.

[0005] Drawbacks of existing technology: 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.

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

[0007] 3. Insufficient error handling capabilities: traditional schemes lack intelligent error diagnosis and automatic repair capabilities, and compilation or running errors need to be analyzed and solved manually.

[0008] 4. Test environment configuration is complex: existing tools lack automated QEMU virtualization test environment management, and the cost of environment setup and maintenance is high.

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

[0010] 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.

[0011] To achieve the above purpose, the present application adopts the following technical solutions: An operating system kernel export function automatic test generation method, comprising the following steps: (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 techniques to extract the EXPORT_SYMBOL (export symbol) function from the source file, and constructs metadata information including 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; (2) LLM-driven test code generation: the API client manager maintains multiple LLM API key pools, based on the multi-level symbol context, constructs intelligent prompt words containing the AST call relationship of the tested function, parameter constraints and test requirements, 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; (3) Automatic compilation and virtualization testing: the module compiler calls the kernel build system to automatically generate Makefile (text file) and compile through the C language test module code, creates an isolated ARM64 virtualization environment through DockerQEMUTestRunner (QEMU virtualization test execution layer), loads the compiled test module into a parallel QEMU instance and executes, collects execution results, compilation errors and runtime error information; (4) Intelligent error diagnosis and repair: TestCaseFixManager (intelligent error repair manager) receives execution results, compilation errors and runtime error information. If the execution result is test failure, the key error points are extracted and the error feature mode is identified in combination with the compilation errors and runtime error information. Repair suggestions are generated in combination with the inference ability of LLM and historical repair experience. For the case that a sub-function cannot be called at runtime, a stub function is automatically called based on the error context to generate a C language test module code that can be compiled and normally run.

[0012] In the 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 marked in the component definition table and the source code directory to which the component belongs, accurately locating the source file set storing the corresponding EXPORT_SYMBOL function, and ensuring the accuracy of the extraction range.

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

[0014] In the 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 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 assigned to idle threads.

[0015] In the specification, the intelligent prompt words constructed in step (2) specifically include: metadata information of the tested function (function signature, parameter type), key call relationship in the multi-level symbol context, mandatory verification items in the kernel test specification (such as memory leak check, permission verification), and successful template fragments of historical test cases of similar functions.

[0016] In the specification, the process of generating Makefile by the module compiler in step (3) specifically includes: The automatic reading step (2) generates the kernel header file reference in the C language test module code, combines the kernel version information of the current test environment (obtained by specifying the correct kernel source path), generates a Makefile containing the correct kernel source path and compilation options (such as -Wall-O2), and ensures compilation compatibility.

[0017] In the specification, the way in which the Docker QEMU TestRunner monitors the test process in step (3) specifically includes: collecting the CPU usage and memory usage of each QEMU instance in real time (through the Docker stats command), setting a threshold (CPU usage ≥ 90% for 10 seconds or memory usage ≥ a preset value), and automatically sending an interrupt signal to terminate the test process when the threshold is triggered, thereby avoiding resource exhaustion.

[0018] 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), null pointer exceptions (segment error logs containing "NULL pointer dereference") in runtime, array out-of-bounds (containing "buffer overflow"), resource deadlocks (containing "lock contention timeout"), etc. Each mode corresponds to a preset feature keyword library.

[0019] In the specification, the strategy for 10 rounds of iterative repair in step (4) is as follows: the first to third rounds focus on repairing compilation errors (preferably handling syntax and linking issues), the fourth to seventh rounds focus on repairing runtime errors (preferably handling null pointers and segment errors), and the eighth to tenth rounds optimize the logical coverage of test cases (supplement boundary value testing and abnormal input testing). Update the error feature mode matching library after each round of repair.

[0020] An operating system kernel export function automatic test generation platform applies the operating system kernel export function automatic test generation method of any one of the above, and the operating system kernel export function automatic test generation platform comprises: An input processing layer is configured to: parse a component definition table through an Excel parser, obtain an element-component-source file mapping relationship, locate to a source file corresponding to a target element and a component, extract an exported symbol function from the source file to construct metadata information, extract a plurality of levels of related functions called by the exported symbol function, analyze the dependency relationship of the related functions within the same element, construct a function call graph and a data flow, and form a plurality of levels of symbol contexts; 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. The code generation layer is configured to: call a kernel build system through a module compiler, automatically generate a text file based on C language test module code and compile the text file, and output a compiled test module; and receive test results fed back by the execution layer, and generate a test report through a report generator; The execution layer is configured to: create an isolated ARM64 virtualization environment through a QEMU virtualization test execution layer, load test modules and execute in parallel QEMU instances; 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 the repair layer, respectively; 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; generate repair suggestions in combination with the inference ability of an LLM and historical repair experience; optimize test cases through iterative repair, return modified test module code to the code generation layer for recompilation and execution after each round of repair, until the execution results are test pass or the iteration upper limit is reached.

[0021] In summary, the present application has at least the following advantages: The test coverage is greatly improved, the multi-level symbolic context extraction technology is used to not only extract single function information, but also analyze the dependency relationship of related functions in the same element and construct a function call graph and data flow analysis, thereby providing rich context information for the LLM and solving the problem of incomplete coverage of traditional manually written test cases.

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

[0023] The test environment configuration is simplified, the DockerQEMUTestRunner is used to automatically create an isolated ARM64 virtual machine environment, 12 parallel QEMU instances are supported, and the test process is monitored in real time, thereby solving the problems of complex traditional test environment construction and lack of automatic execution framework.

[0024] The error repair efficiency and quality are improved, the error repair engine based on feature learning analyzes error pattern features, intelligent diagnosis is realized in combination with the inference ability of an LLM and historical repair experience, up to 10 rounds of iterative repair are supported, and the problems of manual analysis and iterative repair of compilation and runtime errors are solved.

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

[0026] 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 for those skilled in the art, other drawings can also be obtained without creative labor.

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

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

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

[0030] 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

[0031] 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 the description are considered to be exemplary in nature rather than limiting.

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

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

[0034] The operating system of the present application is preferably a Linux operating system. Other operating systems can also be implemented in accordance with the present application under the technical principles of the present application.

[0035] As shown in Figure 1 The present embodiment provides a method for automatically generating test of kernel export function, comprising the following steps: (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 files corresponding to the target element and component based on the element-component-source file mapping relationship, and then extracts the EXPORT_SYMBOL function from these source files 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, the multi-level related functions called by the EXPORT_SYMBOL function are extracted, the dependency relationship of the related functions within the element is analyzed, the function call graph and data flow are constructed, and the multi-level symbol context is formed; (2) LLM-driven test code generation: the API client manager maintains multiple LLM API key pools, and based on the multi-level symbol context obtained in step (1) (the accuracy thereof depends on the EXPORT_SYMBOL function precisely extracted 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 C language test module code conforming to the kernel development specification is generated by the core LLM test generation engine (LLM Based Test Generator), and the test code is generated in batches in a 16-thread concurrent manner, wherein the API client manager realizes task scheduling through the thread pool and queue mechanism; (3) Automatic compilation and virtualization testing: the module compiler calls the kernel build system to automatically generate Makefile and compile the C language test module code generated in step (2); an isolated ARM64 virtualization environment is created by Docker QEMU TestRunner, 12 parallel QEMU instances are used to load and execute the compiled test module, the execution results (including the test pass or fail status and detailed output), compilation errors and runtime error information are collected, and the test process is monitored to prevent deadlock and resource leakage; (4) Intelligent error diagnosis and repair: TestCaseFixManager receives the execution results, compilation errors and runtime error information in step (3), if the execution result is test failure, it extracts the key error points and identifies the error feature mode combined with the compilation errors and runtime error information; combined with the inference ability of LLM and historical repair experience, it generates repair suggestions, for the case that sub-functions cannot be called at runtime, based on the error context, automatically calls the core LLM test generation engine to generate a stub function, ensures that the C language test module code generated in step (2) can be compiled and the target function logic runs normally; through at most 10 rounds of iterative repair and optimization of test cases, after each round of repair, the modified test module code is returned to step (3) for recompilation and execution to obtain new execution results, until the execution result is test passed or the upper limit of 10 rounds is reached, while maintaining the repair history (including the execution results of each round, error types and repair schemes) and success rate statistics to continuously optimize the repair strategy.

[0036] In some embodiments, 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 marked in the component definition table and the source code directory to which the component belongs, accurately locating the source file set storing the corresponding EXPORT_SYMBOL function, and ensuring the accuracy of the extraction range.

[0037] In some embodiments, 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 path between functions, and the shared variable dependency relationship with the functions in the element, the above information is extracted and structured stored layer by layer through AST analysis technology.

[0038] 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, the task queue adopts a priority queue structure, and 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.

[0039] In some embodiments, the intelligent prompt words constructed in step (2) specifically include: metadata information of the tested function (function signature, parameter type), key call relationship in the multi-level symbol context, mandatory check items in the kernel test specification (such as memory leak check, permission verification), and successful template fragments of historical test cases of similar functions.

[0040] In some embodiments, the process of generating Makefile by the module compiler in step (3) specifically includes: 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 (obtained by specifying the correct kernel source path command), generating a Makefile containing the correct kernel source path, compilation options (such as -Wall-O2), and ensuring compilation compatibility.

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

[0042] In some embodiments, the error feature patterns identified in step (4) specifically include: 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"), and resource deadlocks (containing "lock contention timeout"), etc. Each pattern corresponds to a preset feature keyword library.

[0043] 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 (preferably handling syntax and linking issues), the fourth to seventh rounds focus on repairing runtime errors (preferably handling null pointers and segment errors), and the eighth to tenth rounds optimize the logical coverage of test cases (supplement boundary value testing and abnormal input testing). Update the error feature pattern matching library after each round of repair.

[0044] In some embodiments, the repair history maintained in step (4) specifically includes: the kernel version at the time of the error, the test module code snippet (10 lines before and after the error location), the error feature pattern label, the code changes of the repair scheme (addition, deletion, and modification content), and the pass status of the test execution after repair. The above information is stored in a local database in JSON format.

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

[0046] The core technical process of the present application (the process is as shown in Figure 3 and Figure 4 , and the overall architecture is as shown in Figure 2 ): First stage: intelligent symbol extraction and analysis, preprocessing 1. The Excel parser analyzes the component definition table to extract the element-component-source file mapping relationship; 2. The symbol extractor uses regular expressions and AST analysis techniques to extract the EXPORT_SYMBOL function from the kernel source code; 3. Build function signature, parameter type, context dependency, etc. Metadata information; 4. Through the dependency information in the compilation information, 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 graph and data flow analysis, providing rich context information for LLM; Key technical innovation: multi-level symbol context extraction technology; Not only extract single function information, but also analyze the dependency relationship of related functions within the same element; Build function call graph and data flow analysis, provide rich context information for LLM; Second stage: LLM-driven test code generation 1. The API client manager maintains multiple LLM API key pools to achieve load balancing and failover; 2. The test code generator builds an intelligent prompt word containing the AST call relationship and function definition context of the function under test, parameter constraints, and test requirements; 3. Generate C language test module code that meets the kernel development specification through LLM; 4. Support 16-thread concurrent generation, and realize efficient task scheduling and resource management through thread pool and queue mechanism, greatly improve the generation efficiency; Key technical innovation: adaptive API load balancing mechanism; Realize intelligent polling and fault detection of 24 API keys; Adjust the load distribution strategy dynamically according to the API response time and success rate; Hierarchical parallel processing architecture; Generation layer 16-thread concurrency, compilation layer adaptivity, test layer 12-instance parallelism; Through the thread pool and queue mechanism to realize efficient task scheduling and resource management; Third stage: automated compilation and virtualization testing 1. The module compiler automatically generates a Makefile and uses the kernel build system to compile the test module; 2.DockerQEMUTestRunner creates an isolated ARM64 virtual machine environment; 3. Support 12 parallel QEMU instances, automatically load test modules and collect execution results; 4. Monitor the test process in real time to prevent deadlock and resource leakage; Phase 4: Intelligent Error Diagnosis and Repair 1. TestCaseFixManager extracts relevant key error points and presents different error feature patterns by analyzing GCC compilation errors and the stdout (standard output) and stderr (standard error) information when QEMU runs the test case; Key technical innovations: Error repair engine based on feature learning (error feature pattern); Analyze compilation errors and QEMU crash logs for pattern characteristics; Combine LLM's reasoning capabilities and historical repair experience to achieve intelligent error diagnosis; 2. LLM uses its code comprehension capabilities to generate targeted repair suggestions for error characteristics encountered during QEMU operation. Combined with previous historical repair experience, this enables intelligent error diagnosis. Key technological innovation: Combining LLM's reasoning capabilities and historical repair experience to achieve intelligent error diagnosis; Code call-tree analysis extracts code that has a direct call relationship with the target function (the object being tested), significantly improving the output accuracy of large models. Traditional methods typically read source code files or project files, which creates a long and expensive context. This can lead to decreased performance and accuracy of large models. Remove definitions, functions, code comments, etc. that are not relevant to the target test object; If a sub-function cannot be called during runtime, based on the error (such as missing interface definition, link error, etc.), the large model generated stub function can be automatically called again to ensure that the compilation passes and the target function logic can run normally; 3. Support up to 10 rounds of iterative repairs to gradually improve the quality of test cases; 4. Maintain repair history and success rate statistics, and continuously optimize repair strategies; 5. Provide text preprocessing, sentence importance analysis, and context compression technology to reduce hallucinations, improve LLM repair quality, and reduce token usage; Key technical innovation: text preprocessing, technical details: Advanced sentence segmentation: handle abbreviations (Dr. Mr. Inc.), numbers, special cases of punctuation; Text cleaning: uniform spacing, remove invalid characters, maintain format consistency; Basic statistics: calculate the number of sentences, average length, vocabulary distribution; Sentence importance analysis, evaluated by the following multi-dimensional sentence scoring mechanism, the higher the total score, the more important: Total score = keyword density × 0.3 + position weight × 0.2 + length optimization × 0.2 + numerical features × 0.15 + language features × 0.15; Context compression based on summary, recursive summary: Compression strategy: First round: sentence-level compression (retain 60% of sentences); Second round: if still exceeds the target, compress to 70%; Third round: final adjustment to ensure the target token number; Principle: block → summary → re-block → re-summary, layer by layer; Effect: 308 tokens → 43 tokens (14% compression ratio); Advantages: maintain information coherence, high compression ratio; Key information extraction: Principle: extract entities, relationships, events, and structure them; Effect: 308 tokens → 124 tokens (40% compression ratio); Advantages: retain specific details, facilitate accurate answers; The key points and points to be protected of the invention are: Key points: 1. LLM-based kernel function semantic understanding and test generation method: use large language models to analyze the semantics of kernel export functions and generate test cases that conform to the functional logic; 2. Multi-level concurrent processing architecture: implement fine-grained parallel processing in symbol extraction, code generation, compilation testing, and other stages to improve overall performance; 3. Intelligent error diagnosis and iterative repair mechanism: automated error repair method based on error feature recognition and LLM inference; 4. Automated management of virtual test environment: dynamic creation of QEMU virtual machine instances, test execution, and resource cleanup.

[0047] In some embodiments, the intelligent symbol extraction and analysis stage: 1. Excel parser adaptation optimization: For component definition table, 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 standardized element-component-source file mapping table, ensure the accuracy of data source for subsequent symbol extraction.

[0048] 2. Symbol extractor multi-version adaptation: For the format difference of EXPORT_SYMBOL in different Linux kernel versions (such as 5.x, 6.x) (such as whether to contain 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.

[0049] 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 according to call depth (such as 1-3 layers), providing more intuitive context reference for LLM.

[0050] In some embodiments, the LLM-driven test code generation phase: 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.

[0051] 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 calling examples of associated functions within the same element (such as "func must be called after init_func() is initialized"); 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.

[0052] 3. 16-thread concurrency optimization: Bind independent CPU cores when initializing the thread pool, use "task fragmentation-result merging" mode, each thread is responsible for function test generation of a specific module (such as divided by kernel subsystem "process management" "memory management"), intermediate results are passed through shared memory blocks, reducing thread communication overhead.

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

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

[0055] 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).

[0056] In some embodiments, the intelligent error diagnosis and repair phase: 1. Error feature pattern library dynamic update: based on the error information collected by TestCaseFixManager, automatically cluster new error types every week (such as adding "use-after-free" pattern), extract feature keywords (such as "use-after-free" in error log) and update to the pattern library, at the same time, associate historical repair solutions to form an "error-repair" mapping table, to improve the first repair success rate.

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

[0058] 3. Context compression technology landing: For the text preprocessing of kernel function documents, the "keyword weighting + position weight adjustment" strategy is adopted - the core terms such as "EXPORT_SYMBOL" and "parameter constraints" are increased to 0.4 in keyword density weight, and the position weight of the example code at the end of the document is increased to 0.3, to ensure that the key test information is retained after compression; when recursive summary, priority is given to retaining function call relationship description, and redundant comments are removed.

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

[0060] 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.

[0061] In some embodiments, the symbolic extraction stage: 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 which must have logical matching with the "component name" (such as the component "process scheduling" corresponding to the path containing "sched / "), and non-matching items are marked as suspicious data and trigger manual review reminders.

[0062] 2. Symbol extraction accuracy improvement: For kernel EXPORT_SYMBOL_GPL and other variant symbols, the regular matching rule library is expanded to distinguish between ordinary export symbols and GPL exclusive symbols. Function scope analysis is introduced in the AST analysis stage to filter export symbols that are only called within the module (by judging whether the function is referenced by external modules), reducing the amount of invalid symbol extraction. At the same time, a unique identifier (format "kernel version-element ID-symbol name") is generated for each extracted symbol, facilitating subsequent full-process tracking.

[0063] In some embodiments, LLM code generation: 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 "memory safety constraint" module (such as "need to verify pointer non-empty before operation"), 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).

[0064] 2. Thread pool dynamic scaling strategy: Automatically adjust the number of threads according to the length of the task queue, temporarily expand to 24 threads (upper limit) when the queue task number ≥ 20; reduce to 8 threads when the queue idles for more than 5 minutes. 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 the continuity of generation.

[0065] In some embodiments, the compilation and testing environment: 1. Compiler adaptation depth optimization: The module compiler adds cross-compilation support for ARM, x86, RISC-V architecture, automatically detects the target architecture (through the "arch" environment variable) when generating Makefile, and adds architecture-specific compilation options (such as ARM architecture enables "-marm", RISC-V enables "-march=rv64gc"). For compatibility issues between kernel version and compiler version, built-in version matching matrix (such as kernel 6.1+ adapts GCC12+), if not matched, automatically recommend compatible version or prompt upgrade suggestion.

[0066] 2. Virtualization test resource elastic scheduling: DockerQEMUTestRunner introduces a resource prediction model based on historical test data (the correlation between code size, function complexity and resource consumption), estimates the resource demand of each instance before testing. When the predicted memory demand exceeds the single instance upper limit, automatically split the test task (such as splitting a complex function test into 3 steps). At the same time, configure an independent network namespace for each QEMU instance to avoid network request conflicts during testing (such as port occupation).

[0067] In some embodiments, error repair mechanism: 1. Error diagnosis accuracy improvement: The error feature pattern library adds semantic analysis capability, not only matching keywords, but also identifying error context logic (such as "null pointer exception" needs to be combined with the code pointer assignment position to determine whether it is uninitialized). Introduce error impact range evaluation, mark whether the error will cause test interruption (such as "compilation failure" is high impact, "log warning" is low impact), and repair according to impact level.

[0068] 2. Iterative repair efficiency optimization: Add an adaptive adjustment mechanism in 10 rounds of iterations. If the success rate of a certain round is ≥80%, automatically shorten the duration of the next round (reduce by 20%). If the success rate of 2 consecutive rounds is <30%, pause the iteration and call the historical repair solution library for global matching. Generate an error repair report after each round of repair, including error type, repair code change amount, test pass rate, etc. to provide data support for subsequent optimization.

[0069] In some embodiments, the whole process is monitored and feedback is closed loop: 1. Real-time tracking of key indicators: Deploy a monitoring center to collect core indicators such as symbol extraction accuracy (target ≥95%), LLM code generation pass rate (target ≥85%), and test task completion rate (target ≥98%) in real time. When the indicators deviate from the threshold, trigger hierarchical alerts (email, SMS, system pop-up) with exception analysis (e.g. decreased extraction accuracy may be due to changes in the format of the new kernel version symbols).

[0070] 2. User feedback integrated into optimization: Add a user feedback entry that allows testers to mark error repair results ("valid", "partially valid", "invalid") and provide improvement suggestions. Feedback data is analyzed monthly, and high-frequency problems (such as poor error repair results for a certain type of error) are included in the next round of optimization focus, forming a closed-loop mechanism of "development - testing - feedback - optimization".

[0071] In some embodiments, surface fitting is applied in symbol extraction: 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: 1. Data collection: Select 10 typical kernel versions (5.4 to 6.6), and collect 50 sets of extraction accuracy data for each version at call depth 1-5, forming a three-dimensional data set .

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

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

[0074] In some embodiments, resource allocation optimization driven by surface fitting: Apply Gaussian process surface fitting to the relationship between the amount of test module code (x-axis), number of concurrent instances (y-axis), and resource utilization (z-axis) in virtualization testing: 1. Feature Mapping: The code size (KB) and number of instances are used as input variables, and resource utilization (CPU + memory utilization) is used as output. 200 sets of historical data are collected to train the model, and the kernel function (RBF kernel) is used to capture local correlations between variables.

[0075] 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 number of instances as 8 (the utilization rate is only 62% when the traditional fixed 12 instances are used). Based on this, the number of QEMU instances is dynamically adjusted and the corresponding number of CPU cores is allocated simultaneously (according to 0.8 times the number of cores for computing) and memory (by 1.2 times of the reserved amount).

[0076] 3. Real-time calibration: New operating data is collected every hour to update the fitting model. When the actual utilization rate deviates from the predicted value by more than 5%, the model parameters are fine-tuned (such as adjusting the kernel function bandwidth) to ensure that resource allocation always stays in the efficient area of ​​the surface.

[0077] In some embodiments, error-fixing iterative surface fitting optimization: For the surface relationship between "error type complexity (x-axis), iteration rounds (y-axis), and repair success rate (z-axis)", Bayesian optimization combined with surface fitting is used: 1. Type quantification: Quantify the error type by complexity (syntax error = 1, null pointer exception = 3, deadlock = 5) as x value, and the iteration rounds 1-10 as y value. Collect the repair success rate data for 100 types of errors.

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

[0079] 3. Iteration strategy adjustment: Dynamically allocate iteration rounds based on the fitting results. Low-complexity errors (x≤2) are terminated according to the optimal y value of the surface (usually 3-4 rounds), while high-complexity errors (x≥4) are extended to the saturation rounds of surface prediction (such as 7-8 rounds). Compared with a fixed 10-round iteration, the repair time is shortened by an average of 35%, and the success rate is increased to 82%.

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

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

[0082] 3. Visual monitoring: Real-time display of variable relationships through a three-dimensional surface graph, automatically mark "data sparse area" when the fitting error of a certain area is > 8%, and trigger supplementary sampling to continuously optimize the model coverage.

[0083] In some embodiments, when a binary cubic polynomial surface fitting model is used in step (1) to optimize the symbol extraction accuracy, the specific steps include: Collect 10 kernel versions (5.4 to 6.6) and 50 groups of extraction accuracy data for calls at depths 1-5, forming 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; Fit the surface equation z = a0 + a1x + a2y + a3x² + a4xy + a5y² + a6x³ + a7x²y + a8xy² + a9y³ using the least squares method, and solve for the coefficient weights, where the kernel version weight is 0.35±0.05 and the call depth weight is 0.42±0.05; Real-time input of the current kernel version and the preset call depth, if the model prediction accuracy < 90%, automatically adjust the function filtering threshold of AST analysis: relax to 6 layers when the call depth is insufficient, and tighten the symbol matching rules (increase function parameter type checking) when the version compatibility is poor, so that the actual extraction accuracy is stable at 92% or above.

[0084] In some embodiments, when a Gaussian process surface fitting is used in step (3) to optimize resource allocation, the specific steps include: Collect 200 groups of historical running data with test module code size (KB) as x-axis, concurrent QEMU instance number as y-axis, and resource utilization rate (CPU + memory) as z-axis, build a Gaussian process model using RBF kernel function to capture local correlation between variables; Solve the optimal solution (x0, y0) based on the gradient descent algorithm of the fitted surface, which satisfies resource utilization rate ≥ 85% and no competition, where when the code size is 15KB, the output optimal instance number is 8, corresponding to the allocation of CPU core number as 0.8 times the code size calculation value and memory as 1.2 times the code size calculation value; New running data is collected every hour to update the model, and when the actual utilization rate deviates from the predicted value by >5%, the RBF kernel function bandwidth is adjusted (from the initial 0.5 to 0.3-0.7) to ensure that the resource allocation is in the efficient area of the curved surface.

[0085] In some embodiments, when the Bayesian optimization is combined with the curved surface fitting optimization error repair iteration in step (4), it specifically includes: Quantify the error type according to the complexity as the x value (syntax error = 1, null pointer exception = 3, deadlock = 5), and the iteration round 1-10 as the y value, and collect the repair success rate data of 100 kinds of errors; Construct a probability surface through Gaussian process regression, output the mean and variance of the success rate under given (x, y), and when x = 5 (deadlock), the surface shows that the mean success rate is 78% and the variance is <10% when y = 7 rounds; According to the fitting result, dynamically allocate the iteration round: low complexity errors with x≤2 are terminated at y=3-4 rounds, and high complexity errors with x≥4 are extended to y=7-8 rounds, which shortens the repair time by more than 35% compared with fixed 10 rounds of iteration.

[0086] In some embodiments, the calculation method of resource comprehensive utilization rate is: the weighted sum of CPU utilization rate (weight 0.6) and memory utilization rate (weight 0.4), wherein the CPU utilization rate takes the average usage of 12 QEMU instances, and the memory utilization rate is calculated according to "actual occupation / distributed total".

[0087] In some embodiments, the quantification of error type complexity includes: 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 interval of 1-5.

[0088] In some embodiments, the data preprocessing step of curved surface fitting includes: normalizing x, y axis data to [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 input data of the fitting model.

[0089] In some embodiments, the curved 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 link control node, with a single prediction time <10ms, and supports offline operation (preloading 1000 groups of historical fitting parameters).

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

[0091] In some embodiments, the optimal solution also needs to satisfy the constraint condition when solving: 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.

[0092] In some embodiments, the variance threshold of the probability curve is set to 15%, and when the prediction variance of a certain (x, y) point is >15%, the iterative resources are preferentially allocated (such as increasing the test sample size of the point) to reduce the fitting uncertainty.

[0093] An operating system kernel export function automatic test generation platform applies the operating system kernel export function automatic test generation method described in any of the above, such as Figure 2 As shown in the figure, the operating system kernel export function automatic test generation platform includes: An input processing layer is configured to: parse the component definition table through an 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, 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; 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 multi-level symbol context, and generate C language test module code through a core LLM test generation engine; A code generation layer is configured to: call the kernel build system through a module compiler, automatically generate a text file based on the C language test module code and compile it, and output the compiled test module; simultaneously receive the test results fed back by the execution layer, and generate a test report through a report generator; An execution layer is configured to: create an isolated ARM64 virtualization environment through a QEMU virtualization test execution layer, load the test module in parallel with the QEMU instance and execute it; monitor the test process in real time, collect execution results, compilation errors and runtime error information, and feed them back to the code generation layer and the repair layer respectively; The repair layer is configured to: receive, by the intelligent bug repair manager, an execution result, a compilation error and a runtime error information output by the execution layer; if the execution result is a test failure, extract a key error point and identify an error feature mode in combination with the error information, and generate a repair suggestion in combination with inference ability of the LLM and historical repair experience; The test case is optimized by iterative repair, and the modified test module code is returned 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.

[0094] The functional architecture of each functional layer, its functions and interactions, etc. should be understood in combination with the description of the previous method, such as the input processing layer including an Excel parser, a symbol extractor and an API client manager, and its respective functions and interactions, which are described in detail in the principle of the previous method steps.

[0095] The above-described embodiments are used to illustrate the present application and are not intended to limit the present application, so the change of example values or the substitution of equivalent elements should still belong to the scope of the present application.

[0096] From the above detailed description, those skilled in the art can understand that the present application can achieve the above-mentioned purposes, and has met the requirements of the Patent Law.

[0097] Although the preferred embodiments of the present application have been described, those skilled in the art can make further changes and modifications to these embodiments once they know the basic creative concept. 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 only the preferred embodiments of the present application and is not intended to limit the present application. 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.

[0098] It should be noted that the above description of the process is only 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 process under the guidance of the present application. However, these modifications and changes are still within the scope of the present application.

[0099] The above has described the basic concept, and it is obvious that the above-mentioned invention 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 still belong to the spirit and scope of the exemplary embodiments of the present application.

[0100] Also, certain terminology can also be used in the description for the purpose of reference only, and thus is not necessarily limiting. For example, the terms "one embodiment" or "an embodiment" (and / or "one alternative" or "an alternative") are not necessarily mutually exclusive, unless otherwise specified. Additionally, the terms "first", "second", and / or "third" can be used merely as labels, and are not necessarily intended to signify importance or a particular order of occurrence. Moreover, terms such as "front", "back", "top", "bottom", "over", "under", "right", "left", and the like can be used for directionally purposes only, and are not necessarily intended to denote relative position or orientation unless otherwise specified. Furthermore, the terms "coupled" and "connected" and / or similar terms, as used herein, can have different meanings depending upon the context in which they are used. Therefore, these terms are used herein for clarity only, and their use should not be limited by the particular meanings taken from the context in which they are used. For example, the term "connected" can be used herein to indicate that two or more elements are in either physical or logical contact with one another, while the term "coupled" can be used herein to indicate that two or more elements are in either physical or logical contact with one another or that the two or more elements are not in contact with one another, but nonetheless still co-operate. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms. As used herein, the term "includes" means includes but is not limited to, or is inclusive of but not limited to.

[0101] Furthermore, to the extent that the terms "includes", "containing", "having", "with", "wherein", or the like can be interpreted to imply a numerical limitation or the necessity of concomitant recitation of a "comprising" or "consisting of" limitation, those terms shall not be interpreted so as to exclude other embodiments of the application. It will be apparent to one of ordinary skill in the art that aspects of the application can be practiced by other than the methods, systems and materials as described. Accordingly, the present application is not intended to be limited to the methods, systems and materials described, but rather is to be accorded the widest scope consistent with the principles and features described.

[0102] Computer program code for carrying out operations of portions of the application 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, partly on the user's computer, as a stand-alone software package, 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 type of network, including 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 using an Internet Service Provider), or in a cloud computing environment or as a service such as Software as a Service (SaaS).

[0103] Furthermore, the order of processing elements or sequences, or the use or appearance of certain terminology, throughout the above description should not be construed as limiting the application. Other steps, components, or configurations can be determined and implemented in a manner most beneficial to a particular application. For example, although the implementation of the various components described above can be embodied in hardware devices, it can also be implemented as a pure software solution, for example, as an installation on an existing server or mobile device.

[0104] Similarly, it is to be noticed that the term "comprising", used in the description, should not be interpreted as being restricted to the means listed thereafter; it does not exclude other elements or steps. It is thus to be interpreted as specifying the presence of the stated features, integers, steps or components as referred to, but does not preclude the presence or addition of one or more other features, integers, steps or components, or groups thereof. Furthermore, the description of the application is not intended to limit the application to the form disclosed herein. Various modifications and changes can be made without departing from the spirit and scope of the application as set forth in the following claims.

Claims

1. A method for automatically generating test data for an operating system kernel export function, characterized in that: The following steps are involved: (1) 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 build metadata information, and extract the multi-level related functions called by the export symbol function, analyze the dependency relationship of related functions within the same element, build the function call graph and data flow, and form a multi-level symbol context; (2) The API client manager maintains multiple LLM API key pools, builds intelligent prompt words based on multi-level symbol context, and generates C language test module code through the core LLM test generation engine; (3) The module compiler calls the kernel build system, automatically generates a text file through the C language test module code and compiles it, creates an isolated ARM64 virtualization environment through the QEMU virtualization test execution layer, loads the compiled test module with a parallel QEMU instance and executes it, and collects the execution results, compilation errors and runtime error information; (4) The intelligent error repair manager receives the execution results, compilation errors, and runtime error information. If the execution result is a test failure, it extracts the key error points and identifies the error feature patterns based on the compilation error and runtime error information. It then generates repair suggestions based on the reasoning ability of the LLM and historical repair experience. The test cases are optimized through iterative repair. After each round of repair, the modified test module code is returned to step (3) for recompilation and execution to obtain new execution results, until the execution result is that the test passes or the iteration limit is reached.

2. The method for generating automated test of operating system kernel export functions according to claim 1, characterized in that: In step (1), when the symbol extractor 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 element marked in the component definition table and the source code directory to which the component belongs, accurately locating the source file set that stores the corresponding exported symbol function, and ensuring the accuracy of the extraction range.

3. The method for generating automated test of operating system kernel export functions according to claim 1, wherein: The multi-level symbol context constructed in step (1) specifically includes: the directly called functions of the derived symbol function, the indirectly called nested functions, the parameter transfer paths between functions, and the shared variable dependencies of functions within the same element. The above information is extracted layer by layer and stored in a structured manner through AST analysis technology.

4. The method for generating automated test of operating system kernel export functions according to claim 1, wherein: The thread pool and queue mechanism of the API client manager in step (2) specifically includes: creating 16 working threads 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 exported symbol function corresponding to the test task, and high-priority tasks are preferentially assigned to idle threads.

5. The method for generating automated test of operating system kernel export functions according to claim 1, wherein: The intelligent prompt words constructed in step (2) specifically include: metadata information of the function under test, key call relationships in the multi-level symbol context, mandatory check items in the kernel test specification, and successful template fragments of historical test cases of similar functions.

6. The method for generating automated test of operating system kernel export functions according to claim 1, characterized in that: The process of the module compiler generating a text file in step (3) specifically includes: 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, and generating a text file containing the correct kernel source code path and compilation options to ensure compilation compatibility.

7. The method for generating automated test of operating system kernel export functions according to claim 1, characterized in that: 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.

8. The method for generating automated test of operating system kernel export functions according to claim 1, characterized in that: The error feature patterns identified in step (4) specifically include: syntax errors and link errors in the compilation phase, null pointer exceptions, array out-of-bounds, and resource deadlocks in the runtime. Each pattern corresponds to a preset feature keyword library.

9. The method for generating automated test of operating system kernel export functions according to claim 1, characterized in that: The strategy for the 10 rounds of iterative repair in step (4) is as follows: rounds 1-3 focus on repairing compilation errors, rounds 4-7 focus on repairing runtime errors, rounds 8-10 optimize the logical coverage of test cases, and update the error feature pattern matching library after each round of repair.

10. An operating system kernel export function automated test generation platform, characterized in that: The operating system kernel export function automated test generation method according to any one of claims 1 to 9 is applied, and the operating system kernel export function automated 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 build metadata information, and extract the multi-level related functions called by the export symbol function, analyze the dependency relationship of related functions within the same element, build 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 through the API client manager, build intelligent prompt words based on multi-level symbol context, and generate C language test module code through the core LLM test generation engine; The code generation layer is used to: call the kernel build system through the module compiler, automatically generate text files based on the C language test module code, compile them, and output the compiled test modules; at the same time, it receives the test results fed back by the execution layer and generates test reports through the report generator; The execution layer is used to: create an isolated ARM64 virtualization environment through the QEMU virtualization test execution layer, load test modules and execute them in parallel with QEMU instances; monitor the test progress in real time, collect execution results, compilation errors, and runtime error information, and feed them back to the code generation layer and repair layer respectively; The repair layer is used to: receive the execution results, compilation errors, and runtime error information output by the execution layer through the intelligent error repair manager; if the execution result is a test failure, extract the key error points and identify the error feature patterns based on the error information, and generate repair suggestions based on the LLM's reasoning ability and historical repair experience; optimize test cases through iterative repair, and after each round of repair, return the modified test module code to the code generation layer for recompilation and execution until the execution result is a test pass or the iteration limit is reached.

Images