Test method, device and equipment of Xinchuang software and storage medium

Abstract

This invention discloses a testing method, apparatus, device, and storage medium for domestically developed IT software. The method includes: receiving input testing requirements for the target domestically developed IT software; inputting the testing requirements into a large language model; determining a testing process planning scheme based on the model's output; scheduling the analysis component through a testing process scheduling control unit to perform reverse engineering and semantic extraction on the binary program of the target domestically developed IT software to obtain the program's core code representation and potential risk-related data; wherein the testing process scheduling control unit is a scheduling unit built based on the large language model; generating targeted test data based on the program's core code, the potential risk-related data, and the large language model; and scheduling the testing component to execute targeted dynamic testing based on the targeted test data. This achieves the technical effect of improving test coverage and vulnerability identification accuracy.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology for domestically developed software, and in particular to a testing method, apparatus, device, and storage medium for domestically developed software. Background Technology

[0002] With the deepening of the information technology application innovation strategy, domestically developed operating systems, databases, middleware, and other basic software have been widely used in critical information infrastructures such as power, finance, and government. However, the complexity and unique characteristics of the domestic IT innovation ecosystem, such as its closed nature, architectural differences, and frequent instances of no source code, pose serious challenges to software supply chain security.

[0003] Currently, security testing for domestically developed software primarily relies on traditional methods. In vulnerability discovery, while widely adopted fuzzing techniques (such as AFL++) can achieve a certain degree of automation, the generation of test cases often depends on random mutation or simple coverage guidance, exhibiting significant blindness. This method struggles to understand the deep semantic logic of the program, resulting in insufficient reach of complex conditional branches and boundary cases, leading to low testing efficiency and limited coverage. Meanwhile, static analysis tools (such as CodeQL), although capable of quickly scanning code using predefined rules, suffer from high false positive and false negative rates when dealing with the unique code structures or novel vulnerability patterns of domestically developed software, and heavily rely on expert experience to formulate rules and verify results.

[0004] Existing vulnerability remediation technologies have low levels of automation and intelligence, heavily relying on manual labor. In most cases, vulnerability remediation work depends on developers manually analyzing crash information, locating the root cause, and writing patches. The entire process is time-consuming, averaging several weeks. Furthermore, there is a lack of practical tools on the market capable of automating vulnerability remediation for domestically developed software binaries without source code. Although some Automated Program Remediation (APR) tools exist, their remediation methods are often based on fixed templates or historical patches, making it difficult to guarantee the quality and correctness of patch generation, and thus unable to meet the complex needs of the domestically developed software environment. Summary of the Invention

[0005] This invention provides a testing method, apparatus, device, and storage medium for domestically developed software, so as to realize the construction of an intelligent and precise testing process for domestically developed software.

[0006] According to one aspect of the present invention, a testing method for domestically developed information technology software is provided, the method comprising: The system receives input testing requirements for the target domestically developed software, inputs these requirements into a large language model, and determines a testing process planning scheme based on the model's output. The testing process planning scheme includes test instructions and a sequence of functional component calls, whereby the functional components include analysis components and testing components. The test process scheduling control unit schedules the analysis component to perform reverse analysis and semantic extraction on the binary program of the target domestic IT innovation software to obtain the core code representation of the program and potential risk-related data; wherein, the test process scheduling control unit is a scheduling unit built based on a large language model; Based on the core program code, the potential risk-related data, and the large language model, targeted test data is generated, and the test component is scheduled to execute targeted dynamic tests based on the targeted test data.

[0007] According to another aspect of the present invention, a testing apparatus for domestically developed information technology software is provided, the apparatus comprising: The requirement receiving module is used to receive input test requirements for the target domestically developed software, input the test requirements into the large language model, and determine the test process planning scheme based on the model output results; wherein, the test process planning scheme includes test instructions and functional component call sequences, and the functional components include analysis components and test components; The potential risk acquisition module is used to schedule the analysis component to perform reverse analysis and semantic extraction on the binary program of the target domestically developed software through the test process scheduling control unit, so as to obtain the core code representation of the program and potential risk-related data; wherein, the test process scheduling control unit is a scheduling unit built based on a large language model; The testing module is used to generate targeted test data based on the core program code, the potential risk-related data, and the large language model, and to schedule the testing component to execute targeted dynamic tests based on the targeted test data.

[0008] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and memory that is communicatively connected to at least one processor; The memory stores a computer program that can be executed by at least one processor, which is then executed by the at least one processor to enable the at least one processor to execute the testing method of the information technology innovation software according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute a test method for domestically developed software that implements any embodiment of the present invention.

[0010] The technical solution of this invention receives input testing requirements for a target domestically developed software, inputs these requirements into a large language model, and determines a testing process planning scheme based on the model's output. The testing process planning scheme includes test instructions and a sequence of functional component calls, whereby the functional components include analysis components and testing components. A testing process scheduling control unit schedules the analysis components to perform reverse engineering and semantic extraction on the binary program of the target domestically developed software to obtain the core code representation and potential risk-related data. The testing process scheduling control unit is a scheduling unit built based on the large language model. Targeted test data is generated based on the core code, the potential risk-related data, and the large language model. Based on this targeted test data, the testing components are scheduled to execute targeted dynamic tests. This solution solves the technical problems of low efficiency in traditional domestically developed software testing process planning and weak targeting in vulnerability discovery, achieving the technical effects of improving test coverage and vulnerability identification accuracy, and reducing manual testing costs.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a testing method for domestically developed software provided in an embodiment of the present invention; Figure 2a A flowchart illustrating another testing method for domestically developed software provided in this embodiment of the invention; Figure 2b A schematic diagram of the system structure of an optional example of a testing method for domestically developed software provided in an embodiment of the present invention; Figure 2c A flowchart of an optional example of a testing method for domestically developed software provided in an embodiment of the present invention; Figure 3 A schematic diagram of a testing device for domestically developed information technology software provided in an embodiment of the present invention; Figure 4 A schematic diagram of the structure of an electronic device for implementing a testing method for domestically developed software according to an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Figure 1 This is a flowchart illustrating a testing method for domestically developed software provided in an embodiment of the present invention. This embodiment is applicable to the automated testing of domestically developed software. The method can be executed by a testing device for domestically developed software, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method specifically includes the following steps: S110. Receive input test requirements for the target domestically developed software, input the test requirements into a large language model, and determine a test process planning scheme based on the model output results; wherein, the test process planning scheme includes test instructions and functional component call sequences, and the functional components include analysis components and test components.

[0017] Among them, "IT innovation software" can be understood as software developed based on the information technology application innovation system; "target IT innovation software" can be understood as IT innovation software to be tested; "test requirements" can be understood as a set of relevant requirements such as test objectives, scope, and indicators for IT innovation software; "large language model" can be understood as an artificial intelligence model with powerful natural language processing and logical reasoning capabilities, capable of outputting relevant analysis results or solutions based on input content; "test process planning scheme" can be understood as a specific scheme to guide the testing work, including test execution instructions and component call order; "functional component" can be understood as a set of modules that implement specific test functions; "analysis component" can be understood as a functional module used to parse and analyze software programs; and "test component" can be understood as a functional module used to execute test operations and generate test results.

[0018] Specifically, test requirements are received through an interactive interface. Considering that testers may not be technical professionals and their requirements may be expressed in a colloquial manner, the requirements are input into a large language model. Utilizing the model's natural language understanding and domain adaptation capabilities, the requirements are broken down, analyzed, and standardized, ultimately outputting a test flow planning scheme containing test instructions and functional component call sequences. It is understood that the large language model used in this application can be any existing pre-trained model with natural language processing and logical reasoning capabilities. No additional improvements to the model structure or training methods are required; simply integrating it with the test flow scheduling and control unit, analysis components, and test components of this application is sufficient to achieve the technical effects of this application.

[0019] Optionally, the test requirements are natural language requirements; the step of inputting the test requirements into a large language model and determining a test process planning scheme based on the model output results includes: performing semantic parsing on the natural language requirements through the large language model and outputting the model output results; wherein, the model output results include test target data, test scope data, and test priority data; and generating the test process planning scheme based on the test target data, the test scope data, and the test priority data.

[0020] Among them, natural language requirements can be understood as test requirements expressed in everyday spoken or written natural language; semantic parsing can be understood as the analysis of natural language requirements by a large language model; test target data can be understood as data related to the specific goals that the test work needs to achieve; test scope data can be understood as data related to the software functions, modules, etc. covered by the test work; and test priority data can be understood as data related to prioritizing different test tasks.

[0021] Specifically, the system uses a large language model to semantically analyze natural language requirements, breaking down the core demands, involved software modules, and key test metrics. This results in a structured model output, which explicitly includes test target data, such as identifying vulnerabilities like buffer overflows and null pointer dereferences, test scope data, data interaction interfaces, and test priority data. Subsequently, based on this structured data and combined with the system's preset tool calling rules and test process templates, a test process planning scheme is automatically generated, including test instructions, functional component call sequences, and execution standards for each stage.

[0022] S120. The analysis component is scheduled by the test process scheduling control unit to perform reverse analysis and semantic extraction on the binary program of the target domestic software to obtain the core code representation of the program and potential risk-related data; wherein, the test process scheduling control unit is a scheduling unit built based on a large language model.

[0023] The test process scheduling and control unit generates component scheduling instructions based on the functional component call sequence in the test process planning scheme to ensure the orderly scheduling of analysis and test components. The test process scheduling and control unit can be understood as a control module built on a large language model, used to coordinate and schedule the sequential execution of test tasks by various functional components; binary program can be understood as a program file in binary code form; reverse analysis can be understood as performing reverse analysis on the binary program to restore its code logic and structure; semantic extraction can be understood as extracting meaningful syntactic and logical information; core program code representation can be understood as the core functional code of the program; potential risk-related data can be understood as risk information such as potential vulnerabilities and defects.

[0024] Specifically, the binary program of the target domestic IT innovation software is reverse-engineered to restore its code structure and logical flow. Then, the core information is extracted from the parsed code through semantic extraction technology. Finally, a core code representation of the program that reflects the core function of the program is formed, as well as potential risk-related data marked with the location and type of potential risks, so as to provide core data support for subsequent accurate testing.

[0025] Optionally, the step of scheduling the analysis component through the test process scheduling control unit to perform reverse engineering and semantic extraction on the binary program of the target domestically developed software to obtain the core code representation and potential risk-related data includes: performing reverse engineering on the binary program of the target domestically developed software using a decompilation tool to obtain target code; performing semantic analysis on the target code using a static analysis tool to extract the core code representation and potential risk-related data; wherein, the potential risk-related data includes potential vulnerability functions and vulnerability semantic descriptions.

[0026] Among them, decompilation tools can be understood as tools that can convert binary programs into more readable code files; target code can be understood as the code file obtained after the decompilation tool processes the binary program; static analysis tools can be understood as tools that perform syntax, logic, vulnerability, and other analyses on the code when the program is not running; potential vulnerability functions can be understood as functions in the program that may contain vulnerabilities; and vulnerability semantic descriptions can be understood as textual descriptions of the specific manifestations, causes, and other relevant information of potential vulnerabilities.

[0027] Specifically, reverse engineering is performed on the target binary program using decompilation tools to parse the code and data segments of the binary file, restoring machine instructions into highly readable and logically clear target code, such as C language code. Subsequently, deep semantic analysis is conducted on the target code using static analysis tools. By analyzing the code's syntax structure, function call relationships, and data and control flow logic, the core code representation that reflects the software's core functions is extracted. On the other hand, based on preset vulnerability detection rules, such as vulnerability characteristics like buffer overflows and null pointer dereferences, potential risk-related data is identified and extracted. This potential risk-related data may include vulnerable functions, vulnerability triggering conditions, and semantic descriptions.

[0028] S130. Based on the core program code, the potential risk-related data, and the large language model, generate targeted test data, and schedule the test component to execute targeted dynamic tests based on the targeted test data.

[0029] Among them, targeted test data can be understood as test data specifically generated for potential risk points of the program, which has precise testing effects; directional dynamic testing can be understood as testing work targeting specific risk points.

[0030] Specifically, the core code representation of the program and potential risk-related data are input into a large language model. The model combines program logic and risk characteristics to generate targeted test data that can accurately trigger risks, such as input parameter combinations for specific vulnerabilities. Subsequently, the test process scheduling and control unit schedules the test components, loads the generated targeted test data, and conducts targeted testing in the dynamic running state of the program. This simulates real-world usage scenarios to verify whether potential risks will be triggered, while collecting relevant data during the testing process to provide a basis for subsequent risk confirmation and remediation.

[0031] Preferably, the test process planning scheme can dynamically adapt the calling strategy of functional components according to the domain attributes of the target domestic software. For high-security domestic software, the number and depth of the analysis component's execution can be increased, improving the comprehensiveness of risk identification. The test process scheduling and control unit issues targeted test data and test instructions to the test components, driving them to perform targeted dynamic testing on the risk-related code segments of the target domestic software to accurately verify whether potential risks actually exist.

[0032] Optionally, generating targeted test data based on the program core code, the potential risk-related data, and the large language model includes: mapping the program core code to the potential risk-related data to obtain risk-related code segments; and generating targeted test data adapted to risk-triggered scenarios based on the logical structure and potential vulnerability types of the risk-related code segments using the large language model.

[0033] Among them, the association mapping can be understood as associating the core code of the program with data related to potential risks; the risk-associated code segment can be understood as the program code segment directly related to the potential risk point; and the risk triggering scenario can be understood as the specific running scenario that can trigger the potential risk of the program.

[0034] Specifically, the extracted core program code is mapped to potential risk-related data. By matching the location and semantic description of potentially vulnerable functions with the logical correspondence of the core code, the risk-related code segments carrying the risks are accurately identified, such as function code with buffer overflow risks or call code segments without null pointer checks, thus clarifying the core target areas for testing. Subsequently, a large language model is used to deeply understand the logical structure of the risk-related code segments, such as conditional branches and parameter passing rules, and potential vulnerability types such as command injection and integer overflow. Combined with the core conditions for vulnerability triggering, such as specific input formats, boundary values, and logical jump paths, targeted test data adapted to specific risk scenarios is generated. For example, this could be extremely long input data for buffer overflows or malicious instruction combinations for command injection, ensuring that the test data accurately reaches the risk points and significantly improving the efficiency and accuracy of vulnerability verification. Preferably, the mapping process can be presented visually, allowing technical personnel to intuitively view the correspondence between risks and code.

[0035] Optionally, the functional components further include a vulnerability remediation component; after the scheduling test component executes the targeted dynamic test, the components further include: collecting program exception information during the targeted dynamic test; synchronizing the program exception information, program core code representation, and potential risk-related data to the vulnerability remediation component; performing root cause analysis on the program exception information based on a large language model through the vulnerability remediation component to generate a vulnerability remediation plan; and integrating the vulnerability remediation plan into the target domestically developed software based on binary rewriting technology.

[0036] Among them, the vulnerability remediation component can be understood as a functional module that generates remediation solutions and implements remediation; program exception information can be understood as information related to errors, crashes, and other abnormal situations that occur during program operation; root cause analysis can be understood as the process of conducting in-depth analysis of program exception information to find the root cause of the exception; vulnerability remediation solution can be understood as a specific remediation measure formulated for program vulnerabilities; and binary rewriting technology can be understood as the technology of modifying and optimizing code at the binary program level to achieve vulnerability remediation.

[0037] Specifically, during targeted dynamic testing, program anomaly information, such as program crash logs, illegal memory access warnings, and function execution timeout records, is collected in real time to fully capture the on-site data after the vulnerability is triggered. Subsequently, this anomaly information, along with the core program code representation and potential risk-related data obtained from previous analysis, is synchronized to the vulnerability remediation component, providing complete contextual support for root cause analysis, including the core code associated with the vulnerability and the potential risk characteristics identified in the early stages. Next, the vulnerability remediation component leverages the deep reasoning capabilities of a large language model, combined with multi-source data to reconstruct the vulnerability triggering scenario, accurately locating the root cause of the anomaly, such as the lack of null pointer checks or missing buffer boundary checks, and generating a vulnerability remediation solution that conforms to the target software code logic and does not introduce new functional anomalies, such as supplementing conditional judgment instructions or optimizing data processing logic. Finally, considering the application scenario of domestically developed software without source code, binary rewriting technology is adopted to accurately integrate the remediation solution into the binary program while maintaining the integrity of the target program's control flow. Vulnerability patching can be completed without source code compilation, significantly improving the efficiency and adaptability of vulnerability remediation. Preferably, after the vulnerability remediation solution is generated, simulation verification can be performed first to confirm the remediation effect before integration into the target software.

[0038] Optionally, after integrating the vulnerability remediation scheme into the target domestic software based on binary rewriting technology, the method further includes: calling the testing component to reuse the targeted test data and generating new verification test data in combination with the vulnerability remediation logic; performing verification tests on the target domestic software after integrating the remediation scheme based on the new verification test data; and determining that the target domestic software after integrating the remediation scheme has passed the test if the verification test is passed.

[0039] Among them, the newly added verification test data can be understood as test data generated on the basis of the original targeted test data; the target domestic software after integrating the repair solution can be understood as domestic software with the vulnerability repair solution implanted.

[0040] Specifically, the testing component is first invoked to reuse the previous targeted test data, and new verification test data is generated by combining the vulnerability repair logic, such as boundary condition test data for the repaired code, to ensure coverage of the vulnerability repair points and related functions. Then, based on this data, verification tests are performed on the repaired target software. If the test passes, that is, the vulnerability is not reproduced and the core functions are normal, the software is determined to have passed the test, thereby ensuring the quality of the repaired software.

[0041] Preferably, the verification test can adopt a comparative test method, which compares the software test results before and after the repair to intuitively judge the repair effect.

[0042] The technical solution of this invention receives input testing requirements for a target domestically developed software, inputs these requirements into a large language model, and determines a testing process planning scheme based on the model's output. The testing process planning scheme includes test instructions and a sequence of functional component calls, whereby the functional components include analysis components and testing components. A testing process scheduling control unit schedules the analysis components to perform reverse engineering and semantic extraction on the binary program of the target domestically developed software to obtain the core code representation and potential risk-related data. The testing process scheduling control unit is a scheduling unit built based on the large language model. Targeted test data is generated based on the core code, the potential risk-related data, and the large language model. Based on this targeted test data, the testing components are scheduled to execute targeted dynamic tests. This solution solves the technical problems of low efficiency in traditional domestically developed software testing process planning and weak targeting in vulnerability discovery, achieving the technical effects of improving test coverage and vulnerability identification accuracy, and reducing manual testing costs.

[0043] Figure 2a This is a flowchart illustrating another testing method for domestically developed information technology software provided in this embodiment of the invention. Based on the above embodiments, this embodiment is a further optimization, and its specific implementation can be found in the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here. Figure 2a As shown, the method specifically includes the following steps: S210. Receive input test requirements for the target domestically developed software, input the test requirements into a large language model, and determine a test process planning scheme based on the model output results; wherein, the test process planning scheme includes test instructions and functional component call sequences, and the functional components include analysis components and test components; S220. The analysis component is scheduled by the test process scheduling control unit to perform reverse analysis and semantic extraction on the binary program of the target domestic software to obtain the core code representation of the program and potential risk-related data; wherein, the test process scheduling control unit is a scheduling unit built based on a large language model; S230. Based on the core program code, the potential risk-related data, and the large language model, generate targeted test data, and schedule the test component to execute targeted dynamic tests based on the targeted test data.

[0044] S240. Collect test coverage data during the directional dynamic testing process.

[0045] Test coverage data can be understood as data reflecting the extent to which testing covers the program code.

[0046] Specifically, after the targeted dynamic test is executed, test coverage data that reflects the code coverage is collected to understand the current test coverage level.

[0047] S250. Based on the test coverage data, determine the uncovered code segments. If the proportion of uncovered code segments exceeds a preset threshold, feed back to the large language model to optimize the targeted test data generation rules, supplement and generate test data adapted to the uncovered code segments, and re-execute the targeted dynamic test.

[0048] Here, the uncovered code segment can be understood as the program code segment that was not executed during the test; the preset threshold can be understood as a pre-set critical value used to judge whether the test coverage meets the standard, which can be preset based on experience, and this embodiment does not impose specific restrictions on it.

[0049] Specifically, based on test coverage data, the percentage of uncovered code segments is determined. If the percentage exceeds a preset threshold, the relevant data is fed back to the large language model. The model then optimizes the generation rules for targeted test data, supplements the generation of test data for the uncovered code segments, and re-executes the targeted dynamic test, thereby improving the comprehensiveness of the test. This invention's technical solution, by collecting test coverage data from targeted dynamic tests, determining the percentage of uncovered code segments, and feeding back the optimized targeted test data generation rules to the large language model when the percentage exceeds a preset threshold, supplementing the data, and re-testing, solves the problems of incomplete code coverage and insufficient test targeting in traditional tests, achieving the technical effect of improving the completeness and accuracy of test coverage.

[0050] Figure 2b A schematic diagram of the system structure of an optional example of a testing method for domestically developed software provided in this embodiment of the invention, as shown below. Figure 2b As shown, its core lies in building a collaborative working platform with a large language model as the intelligent hub. This system mainly includes the following four core modules: (1) Intelligent call central module This module serves as the scheduling and control center for the entire system. Using the large language model as the decision-making entity, it achieves dynamic orchestration and collaborative management of heterogeneous toolchains such as decompilation, static analysis, fuzzing, and vulnerability patching through standardized interfaces built using the ModelContextProtocol (MCP). Each MCP server registers its provided function list, input parameter formats, and output result specifications with the large language model, forming a unified tool catalog. The large model can perceive the test task status, understand user command intent, and dynamically drive backend tools to execute corresponding operations. Figure 2c A flowchart of the MCP (Multi-Process Flowchart) is provided as an optional example of a testing method for domestically developed software, according to an embodiment of the present invention. The core process of the MCP is as follows: Figure 2c As shown.

[0051] Specifically, the large model receives testing requirements expressed by users in natural language and, based on its task planning capabilities, automatically decomposes these requirements into a series of ordered tool invocation steps. Subsequently, the large model acts as a scheduler, sequentially invoking the corresponding MCP tools to perform the specific operations according to this plan. After each tool completes its execution, its output (such as decompiled code, vulnerability lists, and coverage reports) is returned to the large model as new context. Based on this multi-round interactive context, the large language model dynamically decides subsequent steps; for example, it adjusts the fuzzing seed generation strategy based on high-risk functions discovered through static analysis. This dynamic workflow orchestration mechanism based on context awareness and reasoning enables effective combination of toolchains and adaptive task execution, forming the core of the system's intelligence.

[0052] (2) Decompilation and Static Analysis Module This module is responsible for in-depth analysis and security assessment of the target domestically developed software's binary program. Its function is to convert binary code to high-level language code and perform preliminary intelligent vulnerability identification. Specifically, the module's technical implementation includes two core steps: First, in the decompilation stage, the system integrates professional decompilation tools (such as IDAPro) to perform automated reverse analysis on the input binary executable program. This process converts machine code into high-level language code (such as C code), which is easier to semantically analyze, and uses a pre-compiled tree-sitterC syntax library to parse any C source file into an abstract syntax tree, automatically extracting all function definitions and performing lightweight cleanup such as removing control characters, merging blank lines, and preserving indentation. The result is saved as a JSON dataset for subsequent annotation. This step provides a structured code foundation for further in-depth analysis.

[0053] Subsequently, in the static analysis phase, the system submits the function code and related structural information extracted in the previous steps, along with predefined vulnerability detection hints, to the large language model. The large language model acts as an analysis engine with code security knowledge, performing static security audits on each function. Its analysis process is not simple pattern matching, but rather based on a deep understanding of code semantics, data flow, and control flow. The model is required to determine whether a specified function contains a specific type of security vulnerability (such as buffer overflow, null pointer dereference, command injection, etc.) and must generate a thought chain explaining its reasoning process. This thought chain details the vulnerability's triggering conditions, sensitive data flow paths, and potential harms, thereby externalizing and making the model's internal reasoning process transparent.

[0054] This module outputs an intelligent vulnerability report, which not only identifies the locations of at-risk functions but also includes a model-generated, interpretable analysis of the vulnerability's root cause. This report assists in the generation of test seeds for the next stage, ensuring the accuracy and efficiency of subsequent fuzzing. Through this module, the system achieves automated and in-depth security insights into binary programs, laying a solid knowledge foundation for the entire testing process.

[0055] (3) Seed generation and fuzz testing module This module leverages vulnerability knowledge acquired during the static analysis phase to support efficient dynamic testing. Its core function is to generate initial test seeds and execute coverage-guided fuzzing to trigger potential vulnerabilities. Specifically, the module's technical implementation includes the following three key steps: First, in the seed generation stage, the system leverages the code understanding and generation capabilities of a large language model. Based on the output of the decompilation and static analysis modules, initial test seeds are generated. The large language model analyzes the target program's code semantics, input format specifications, and high-risk functions identified by static analysis to generate syntactically correct and semantically reasonable test cases. For example, when static analysis identifies a function with a buffer overflow risk, the large language model generates specific input data designed to trigger the buffer boundary conditions, significantly improving the quality of the starting point for testing.

[0056] Subsequently, during the fuzzing execution phase, the system invokes and manages the coverage-guided fuzzing tool AFL++, using the aforementioned generated seed as initial input to perform dynamic testing on the target program. During the testing process, AFL++ collects runtime information about the target program, including but not limited to test cases that cause program crashes, test cases that cause program timeouts, and test cases with unique execution paths. This dynamic information is continuously recorded and fed back to the system.

[0057] Finally, in the dynamic feedback and optimization phase, the large language model analyzes the information collected in real time. Based on the analysis results, the model can dynamically adjust testing strategies. For example, for areas where coverage growth has stagnated, it can suggest generating new mutation seeds to explore uncovered paths; or for code segments that frequently exhibit anomalies, its testing priority can be increased. This continuous optimization based on semantic understanding and dynamic feedback transforms the fuzzing process from traditional blind exploration to goal-oriented intelligent search, greatly improving the accuracy of vulnerability discovery and overall testing efficiency.

[0058] (4) Vulnerability Repair Module This module is responsible for automating vulnerability remediation. Based on the clear division of module functions, this module is specifically completed by two sub-modules: a patch generation module and a patch application module.

[0059] The patch generation module is responsible for the intelligent process from vulnerability analysis to remediation plan generation. First, it collects complete vulnerability information, including the specific input samples that triggered the vulnerability, the core dump file at the time of program crash, function call stacks, and related decompiled code context. The system integrates this multi-source information to construct a complete vulnerability analysis context and submits it to a large language model for root cause analysis. Based on its deep semantic understanding capabilities trained on massive amounts of code and vulnerability data, the large language model diagnoses the root cause of the vulnerability. This process is not simple pattern matching but involves complex logical reasoning. The model needs to identify the specific code location causing the vulnerability, accurately determine the vulnerability type, and clearly explain its triggering mechanism and potential harm. Based on this in-depth analysis, the system drives the large language model to generate specific remediation plans. The model automatically synthesizes patch code that conforms to the original program logic based on the vulnerability type and code context.

[0060] The generated patches must meet several requirements: first, they must accurately fix the identified security vulnerabilities; second, they must maintain consistency with the original code in style and structure; and third, they should avoid introducing new functional anomalies or performance degradation as much as possible. The system will perform a preliminary syntax check on the generated patch code and compare it with the original vulnerable code to ensure the remediation logic is targeted. The final output of this module is a structured remediation plan, which includes patch code that can be directly applied to subsequent processes, detailed remediation instructions, and a thought process chain for model reasoning, providing a foundation for the precise operation of the patch application module.

[0061] The patch application module is responsible for actually deploying the generated patch scheme to the target program. Its core technology is patch application based on binary rewriting. This module uses GTIRB (Gramma TechIntermediate Representation for Binaries) as a standardized binary intermediate representation to construct a hierarchical control flow representation (CFR) to deconstruct the target program. This process elevates the original binary instruction sequence into a structured representation containing multiple levels such as modules, sections, byte ranges, code blocks, and data blocks. Based on this, the system further constructs a hierarchical control flow representation model, establishing a complete abstract system from the instruction layer, basic block layer to the function layer. Each level maintains the positional relationship of its internal elements through an automatic indexing mechanism and establishes a precise binding with the underlying GTIRB entity, thereby providing a reliable structured foundation for subsequent precise patching while preserving the complete semantics of the original program.

[0062] This module, based on the aforementioned constructed program representation, performs specific patch code integration operations. It supports both block-level and instruction-level patching granularities. For block-level patching, the tool uses a hierarchy editor to insert new blocks or modify existing blocks at target locations, automatically handling block splitting, control flow redirection, and offset adjustments. For instruction-level patching, the tool uses a precise positioning mechanism to replace or insert instructions at specified locations, simultaneously updating the underlying byte range content and symbolic expressions. Throughout the rewrite process, the tool uses a hierarchy locator and a graph locator to track the entity objects corresponding to each abstract element and their specific locations in the binary file in real time, ensuring bidirectional consistency between the program's abstract representation and its concrete implementation.

[0063] Finally, during the control flow maintenance and verification phase, this tool automates the handling of program structure changes caused by code modifications through its built-in control flow maintenance subsystem. It maintains complete predecessor and successor relationships at the basic block level. When a new code segment is inserted or an existing instruction is modified, the edge relationship recorder automatically captures the control flow edges that need to be deleted or newly created. After the patching operation is completed, the tool reconstructs the complete control flow graph through a unified edge implementation mechanism, ensuring that the symbolic references of all jump instructions are correctly updated, thereby guaranteeing the integrity and correctness of the patched program's control logic. After rewriting, the tool generates a new executable binary file and automatically executes the verification process. Regression testing ensures the effectiveness of the fix and that no new functional defects have been introduced, ultimately completing the technical loop of vulnerability patching.

[0064] Through the collaborative work of the patch generation module and the patch application module, this module automates the entire process from vulnerability discovery to remediation, significantly improving the efficiency and reliability of emergency response for domestically developed software security.

[0065] For example, this embodiment uses office software running on a certain operating system as the test target to demonstrate the complete workflow of the system. This software is an important component for office document processing.

[0066] For example, the system first receives test instructions from the user expressed in natural language, such as: "You are a senior security researcher specializing in software supply chain security analysis. The current operating system is A; the core task is to develop and execute a complete security testing process based on the provided installation package B. Specifically, this includes: Installation package preprocessing stage: decompressing the installation package, recommending analysis priorities based on file characteristics, and the user selecting the target to be tested; Decompilation analysis stage: decompiling the target and extracting function-level code representations; Static vulnerability analysis stage: performing in-depth security audits on the decompiled code to identify potential security vulnerabilities; Test verification stage: generating test cases based on the static analysis results and executing coverage-guided fuzzing tests; Vulnerability remediation stage: performing root cause analysis on vulnerabilities, generating remediation patches, and achieving automated remediation through binary rewriting technology. All work is completed within the MCP toolchain provided in this environment, ensuring data transfer and process continuity at each stage. Detailed analysis and execution strategies are required at each critical decision point." For example, after parsing the instruction, the large language model generates a detailed execution sequence: first, the installation package is decompressed and its files are analyzed to identify analyzable objects; then, a reverse engineering tool is called to decompile the selected target, followed by static vulnerability analysis; then, test cases are generated based on the analysis results and fuzz testing is performed; after a vulnerability is discovered, a vulnerability remediation tool is called for automated remediation. The central module, according to this plan, sequentially schedules the subsequent modules to perform their work via the MCP protocol. We selected the libswwatermark.so dynamic link library, a core component of the OFD software, as the specific target for this test.

[0067] For example, after selecting a target, the decompilation and static analysis module begins its work. The system uses the `decompile_function` tool of IDA Pro MCP to decompile the target binary file `libswwatermark.so` and writes the decompiled result into a C language code file. Subsequently, the pre-compiled tree-sitter C syntax library is used to parse the decompiled code into an abstract syntax tree, automatically extracting all function definitions and performing lightweight cleanup such as removing control characters, merging blank lines, and preserving indentation. The result is saved as a JSON dataset for subsequent annotation. Then, a large language model is called to perform static security audits on each function in the dataset, requiring the model to provide a 0 / 1 judgment on the existence of a vulnerability. When analyzing the function `CPDF_Dictionary::GetDict()`, the large language model discovered that this function might return a null pointer under certain conditional branches, and its caller function `COFD_PdfReader::ParseAnnotation()` directly accessed member fields without performing a validity check on the return value. The large model identified this as a high-risk null pointer dereference vulnerability and generated a detailed report containing the vulnerability location, risk description, triggering conditions, and remediation suggestions.

[0068] For example, based on the static analysis results, the seed generation and fuzzing modules proceed. The large language model first parses the OFD file format specification, understanding the file structure, including core components such as Root.xml, Documents.xml, and Pages / *.xml. Based on the identified vulnerability characteristics, the model generates five types of targeted test seeds: 1) abnormal documents missing Annotations nodes; 2) documents with incorrectly formatted Annotations nodes; 3) document structures with excessively deep nesting levels; 4) documents containing special Unicode characters; and 5) intentionally constructed boundary condition documents. Next, the system starts the AFL++ fuzzer, using these targeted seeds as input to perform coverage-guided fuzzing on the libswwatermark.so library. During the test, the system detects a segmentation fault crash when processing a specific seed file. Analysis of the crash scene confirms the cause as movr8d,[rdx+4]. In this instruction, the value of the rdx register is 0, and [rdx+4] attempts to access memory address 0x4, which is an illegal memory access, leading to a segmentation fault.

[0069] For example, upon detecting a crash, the vulnerability remediation module is activated. The patch generation submodule first collects the complete crash context, including the OFD document sample that triggered the crash, the core dump file, the function call stack, and related decompiled code. After analyzing this information using a large language model, it accurately diagnoses the root cause of the vulnerability as the lack of null pointer checks and generates a corresponding patch: after calling CPDF_Dictionary::GetDict(), it inserts null pointer check code on the return value, and executes a security handling process when a null pointer is detected. The patch application submodule then uses binary rewriting technology to precisely integrate the generated patch code into the binary image of libswwatermark.so. The system first converts the target library to a GTIRB intermediate representation, locates the instruction that needs patching, inserts conditional jump instructions to implement the null pointer check logic, and updates all related control flow edges and symbolic references. Finally, the system uses the original test document that triggered the vulnerability to verify the patched library, confirming that the vulnerability has been eliminated and normal functionality is unaffected, completing the entire closed loop from vulnerability discovery to remediation.

[0070] The technical solution of this invention uses a large language model as the intelligent scheduling and decision-making center to dynamically schedule decompilation, static analysis, fuzz testing and vulnerability repair toolchain, thereby realizing a closed loop of the entire process from intelligent vulnerability discovery to automated repair, which significantly improves the intelligence level, efficiency and accuracy of security testing of domestically developed software.

[0071] Figure 3 This is a schematic diagram of a testing device for domestically developed information technology software provided in an embodiment of the present invention. Figure 3 As shown, the device includes: a demand receiving module 310, a potential risk acquisition module 320, and a testing module 330.

[0072] The system includes a requirement receiving module 310, which receives input test requirements for the target domestically developed software, inputs these requirements into a large language model, and determines a test process planning scheme based on the model's output. The test process planning scheme includes test instructions and a sequence of functional component calls, with the functional components including an analysis component and a test component. A potential risk acquisition module 320, through a test process scheduling control unit, schedules the analysis component to perform reverse engineering and semantic extraction on the binary program of the target domestically developed software to obtain the core program code representation and potential risk-related data. The test process scheduling control unit is a scheduling unit built based on the large language model. A test module 330 generates targeted test data based on the core program code, the potential risk-related data, and the large language model, and schedules the test component to execute targeted dynamic tests based on the targeted test data.

[0073] The technical solution of this invention receives input testing requirements for a target domestically developed software, inputs these requirements into a large language model, and determines a testing process planning scheme based on the model's output. The testing process planning scheme includes test instructions and a sequence of functional component calls, whereby the functional components include analysis components and testing components. A testing process scheduling control unit schedules the analysis components to perform reverse engineering and semantic extraction on the binary program of the target domestically developed software to obtain the core program code representation and potential risk-related data. The testing process scheduling control unit is a scheduling unit built based on the large language model. Targeted test data is generated based on the core program code, the potential risk-related data, and the large language model. Based on the targeted test data, the testing components are scheduled to execute targeted dynamic tests. This solves the technical problems of low efficiency in traditional domestically developed software testing process planning and weak targeting in vulnerability discovery, achieving the technical effects of improving test coverage and vulnerability identification accuracy, and reducing manual testing costs. Optionally, the testing requirements are natural language requirements; correspondingly, the requirement receiving module includes: The semantic parsing unit is used to perform semantic parsing on the natural language requirements through the large language model and output the model output results; wherein, the model output results include test target data, test scope data and test priority data; The scheme generation unit is used to generate the test process planning scheme based on the test target data, the test scope data, and the test priority data.

[0074] Optionally, the potential risk acquisition module includes: The target code acquisition unit is used to perform reverse engineering on the binary program of the target domestic software using a decompilation tool to obtain the target code; The potential risk acquisition unit is used to perform semantic analysis on the target code using static analysis tools to extract the core code representation of the program and potential risk-related data; wherein, the potential risk-related data includes potential vulnerable functions and vulnerability semantic descriptions.

[0075] Optionally, the test module includes: The risk code segment acquisition unit is used to associate and map the core program code with the potential risk-related data to obtain the risk-related code segment; The targeted test data generation unit is used to generate targeted test data adapted to risk-triggered scenarios based on the logical structure and potential vulnerability types of risk-related code segments using a large language model.

[0076] Optionally, the device further includes a first test data acquisition module, used to acquire test coverage data during the directional dynamic test process after the scheduling test component performs the directional dynamic test; The retesting module is used to determine the uncovered code segments based on the test coverage data. If the proportion of uncovered code segments exceeds a preset threshold, it feeds back to the large language model to optimize the targeted test data generation rules, supplements and generates test data adapted to the uncovered code segments, and re-executes the targeted dynamic test.

[0077] Optionally, the functional components further include a vulnerability remediation component; correspondingly, the apparatus further includes: The second test data acquisition module is used to collect program exception information during the directed dynamic test process after the scheduling test component performs the directed dynamic test; The data synchronization module is used to synchronize the program exception information, the program core code representation, and potential risk-related data to the vulnerability remediation component; The remediation solution generation module is used to perform root cause analysis on the program's abnormal information based on a large language model using the vulnerability remediation component, and generate a vulnerability remediation solution. An integration module is used to integrate the vulnerability remediation scheme into the target domestic software based on binary rewriting technology.

[0078] Optionally, the device further includes: A new test data determination module is added, which is used to call the test component to reuse the targeted test data and generate new verification test data in combination with the vulnerability repair logic after the vulnerability repair scheme is integrated into the target domestic software based on binary rewriting technology. The verification test module is used to perform verification tests on the target domestically developed software after the integration and repair scheme based on the newly added verification test data. The verification test result determination module is used to determine whether the target domestically developed software with integrated repair solution has passed the test, provided that the verification test is passed. The testing device for domestically developed software provided in this embodiment of the invention can execute the testing method for domestically developed software provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0079] Figure 4 This is a schematic diagram of an electronic device for implementing the testing method of domestically developed information technology software according to embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0080] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0081] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0082] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the testing of domestically developed software.

[0083] In some embodiments, the testing of the method-based information technology innovation software can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method-based information technology innovation software testing described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the method-based information technology innovation software testing by any other suitable means (e.g., by means of firmware).

[0084] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0085] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0086] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0087] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0088] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0089] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0090] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0091] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A testing method of Xinxin software, characterized in that, include: The system receives input testing requirements for the target domestically developed software, inputs these requirements into a large language model, and determines a testing process planning scheme based on the model's output. The testing process planning scheme includes test instructions and a sequence of functional component calls, whereby the functional components include analysis components and testing components. The test process scheduling control unit schedules the analysis component to perform reverse analysis and semantic extraction on the binary program of the target domestic IT innovation software to obtain the core code representation of the program and potential risk-related data; wherein, the test process scheduling control unit is a scheduling unit built based on a large language model; Based on the core program code, the potential risk-related data, and the large language model, targeted test data is generated, and the test component is scheduled to execute targeted dynamic tests based on the targeted test data.

2. The method of claim 1, wherein, The testing requirements are natural language requirements; the process of inputting the testing requirements into a large language model and determining the testing process planning scheme based on the model output results includes: After semantically parsing the natural language requirements using the large language model, the model output results are output; wherein, the model output results include test target data, test scope data, and test priority data; The test process planning scheme is generated based on the test target data, the test scope data, and the test priority data.

3. The method of claim 1, wherein, The test process scheduling control unit schedules the analysis component to perform reverse engineering and semantic extraction on the binary program of the target domestic IT innovation software, in order to obtain the core code representation and potential risk-related data, including: The target domestic IT innovation software's binary program is reverse engineered using a decompilation tool to obtain the target code; The target code is subjected to semantic analysis using static analysis tools to extract the core code representation and potential risk-related data; wherein, the potential risk-related data includes potential vulnerable functions and vulnerability semantic descriptions.

4. The method of claim 1, wherein, The generation of targeted test data based on the core program code, the potential risk-related data, and the large language model includes: The core program code is mapped to the potential risk-related data to obtain the risk-related code segment; Based on the logical structure and potential vulnerability types of risk-related code segments, a large language model is used to generate targeted test data that is adapted to risk-triggered scenarios.

5. The method of claim 1, wherein, After the scheduling test component performs the directed dynamic test, the following is also included: Collect test coverage data during the targeted dynamic testing process; Based on the test coverage data, the uncovered code segments are identified. If the proportion of uncovered code segments exceeds a preset threshold, the data is fed back to the large language model to optimize the targeted test data generation rules, supplement the generation of test data adapted to the uncovered code segments, and re-execute the targeted dynamic test.

6. The method of claim 1, wherein, The functional components also include a vulnerability remediation component; after the scheduling test component performs targeted dynamic testing, it also includes: Collect program exception information during the targeted dynamic testing process; The program exception information, core program code representation, and potential risk-related data are synchronized to the vulnerability remediation component. The vulnerability remediation component performs root cause analysis on the program's abnormal information based on a large language model to generate a vulnerability remediation solution. The vulnerability remediation solution is integrated into the target domestic IT software based on binary rewriting technology.

7. The method of claim 6, wherein, After integrating the vulnerability remediation scheme into the target domestically developed software based on binary rewriting technology, the method further includes: The test component is invoked to reuse the targeted test data, and new verification test data is generated by combining the vulnerability remediation logic. Based on the newly added verification test data, perform verification tests on the target domestically developed software after the integration and repair scheme; If the verification test passes, the target domestically developed software with the integrated repair solution will pass the test.

8. A testing device for Xins software, characterized in that, include: The requirement receiving module is used to receive input test requirements for the target domestically developed software, input the test requirements into the large language model, and determine the test process planning scheme based on the model output results; wherein, the test process planning scheme includes test instructions and functional component call sequences, and the functional components include analysis components and test components; The potential risk acquisition module is used to schedule the analysis component to perform reverse analysis and semantic extraction on the binary program of the target domestically developed software through the test process scheduling control unit, so as to obtain the core code representation of the program and potential risk-related data; wherein, the test process scheduling control unit is a scheduling unit built based on a large language model; The testing module is used to generate targeted test data based on the core program code, the potential risk-related data, and the large language model, and to schedule the testing component to execute targeted dynamic tests based on the targeted test data.

9. An electronic device, comprising: The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the testing method of the information technology innovation software according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the testing method of the domestically developed software as described in any one of claims 1-7.

Images