A method and device for mutation testing based on intelligent automation scripts

Abstract

The application discloses a kind of based on intelligent automation script's variation test method and device.The method includes: using context-aware syntax tree extraction in original source code sentence execution order and branch dependency, generate control flow graph and data flow graph;With large language model, code semantic analysis is carried out to multi-dimensional code features, potential defect types and variation rules are identified, the test efficiency of mutant is predicted in combination with deep Q learning model, and the mutant to be processed is generated;Grammar check and equivalence analysis are carried out to the mutant to be processed, and effective mutant is obtained, to carry out test;Variation test index is calculated and weak point of code is positioned, and test blind area is identified according to surviving mutant, and thus visual analysis report is generated;According to the current surviving mutant and visual analysis report, new test case is generated iteratively, and the current surviving mutant is tested using new test case.The application can improve the efficiency of variation test.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a mutation testing method and apparatus based on intelligent automated scripts. Background Technology

[0002] Mutation testing is an important technique in software testing for evaluating the effectiveness of test cases. This technique involves artificially introducing defects (i.e., creating variants) into the program's source code, then running test cases to check whether these variants are detected, thereby evaluating the quality and coverage of the test suite.

[0003] Traditional mutation testing techniques primarily employ two implementation methods: one is rule-based static mutation systems, which generate mutants in batches using predefined syntax transformation rules (such as substitution operators, modification of conditional expressions, etc.); the other is random sampling-based mutation techniques, which generate mutants by randomly selecting code locations and mutation operations. These techniques are typically implemented using specialized mutation testing tools such as MuJava and PIT.

[0004] However, traditional mutation testing techniques suffer from several key problems: First, due to a lack of deep understanding of code semantics, they cannot simulate common logical errors in real-world development; second, the selection of mutation points lacks specificity, often generating a large number of meaningless or equivalent mutants, wasting computational resources; third, the problem of equivalent mutants (i.e., syntactically different but functionally equivalent mutants) produces false mutation coverage metrics, leading to low testing efficiency; finally, traditional methods require a significant amount of manual analysis and test case writing, making them difficult to adapt to the rapid iteration needs of large projects. Therefore, existing mutation testing techniques are inefficient. Summary of the Invention

[0005] This invention provides a mutation testing method and apparatus based on intelligent automated scripts, which solves the problems of lack of semantic understanding, inaccurate selection of mutation points, difficulty in identifying equivalent mutants, and low efficiency in test case generation in traditional mutation testing, thereby improving the efficiency of mutation testing.

[0006] In a first aspect, the present invention provides a mutation testing method based on intelligent automated scripts, comprising the following steps:

[0007] The original source code, runtime information, and version control data are obtained. A context-aware syntax tree constructed by a specific language parser is used to extract the statement execution order and branch dependencies in the original source code, generate a control flow graph and a data flow graph, and perform feature extraction on the control flow graph, the data flow graph, the runtime information, and the version control data to obtain multi-dimensional code features. Each node in the context-aware syntax tree carries contextual meta-information.

[0008] Based on the multi-dimensional code features, a preset large language model is used to perform code semantic analysis on the multi-dimensional code features to identify potential defect types and corresponding mutation rules. A preset deep Q-learning model is combined to predict the testing efficiency of the variants. Based on the testing efficiency and the mutation rules, a variant to be processed that conforms to the defect type is generated. The testing efficiency is used to evaluate the probability that the variant will have a defect problem related to the test case after executing the preset test case.

[0009] The mutants to be processed are subjected to syntax checking and equivalence analysis to obtain valid mutants. The valid mutants are tested using the test cases, and the test execution results of each valid mutant are recorded, wherein the test execution results are either alive or killed.

[0010] Based on the test execution results, mutation test indicators are calculated and code weaknesses are located. Test blind spots are identified based on surviving mutants, so that a visual analysis report containing test strategy optimization suggestions is generated based on the mutation test indicators, the code weaknesses, and the test blind spots. The surviving mutants are used to indicate that the test execution results are valid mutants in the surviving state.

[0011] Iteratively generate new test cases based on the current surviving variants and visualization analysis reports, and use the new test cases to test the current surviving variants.

[0012] Secondly, the present invention provides a mutation testing device based on intelligent automated scripts, comprising:

[0013] The code analysis module is used to acquire the original source code, runtime information, and version control data. It uses a context-aware syntax tree constructed by a specific language parser to extract the statement execution order and branch dependencies in the original source code, generate control flow graphs and data flow graphs, and perform feature extraction on the control flow graphs, data flow graphs, runtime information, and version control data to obtain multi-dimensional code features. Each node in the context-aware syntax tree carries contextual meta-information.

[0014] The variant generation module is used to perform code semantic analysis on the multi-dimensional code features based on the multi-dimensional code features using a preset large language model, identify potential defect types and corresponding mutation rules, predict the test efficiency of the variants by combining a preset deep Q-learning model, and generate a variant to be processed that conforms to the defect type based on the test efficiency and the mutation rules. The test efficiency is used to evaluate the probability that the variant will have a defect problem related to the test cases after executing the preset test cases.

[0015] The test execution module is used to perform syntax checking and equivalence analysis on the mutant to be processed to obtain valid mutants, use the test cases to test the valid mutants, and record the test execution results of each valid mutant, wherein the test execution results are either alive or killed.

[0016] The results analysis module is used to calculate mutation test indicators and locate code weaknesses based on the test execution results, and identify test blind spots based on surviving mutants, so as to generate a visual analysis report containing test strategy optimization suggestions based on the mutation test indicators, the code weaknesses and the test blind spots, wherein the surviving mutants are used to indicate that the test execution results are valid mutants in the surviving state;

[0017] The test case generation module is used to iteratively generate new test cases based on the current surviving mutants and the visualization analysis report, and then use the new test cases to test the current surviving mutants.

[0018] This invention provides a mutation testing method and apparatus based on intelligent automated scripts. It extracts structural and semantic information from source code using deep program analysis technology, performs code semantic analysis using a large language model, identifies potential defect types, and generates high-quality mutants. Simultaneously, it collects results through equivalence analysis and test execution, calculates mutation testing metrics, identifies testing blind spots, and finally generates new test cases based on the test results, forming a closed-loop optimization mechanism that significantly improves the efficiency and effectiveness of mutation testing. This invention enables precise mutation point selection based on semantic understanding, effective mutant identification and filtering, intelligent test result analysis, and test case generation, greatly improving the efficiency and effectiveness of mutation testing and providing strong support for software quality assurance. Attached Figure Description

[0019] Figure 1 A flowchart illustrating a mutation testing method based on intelligent automated scripts provided in an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of a mutation testing device based on intelligent automated scripts, provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0022] like Figure 1 As shown, the present invention provides a mutation testing method based on intelligent automated scripts, including the following steps S101 to S105.

[0023] S101. Obtain the original source code, runtime information, and version control data. Use a context-aware syntax tree constructed by a specific language parser to extract the statement execution order and branch dependencies in the original source code, generate a control flow graph and a data flow graph, and perform feature extraction on the control flow graph, the data flow graph, the runtime information, and the version control data to obtain multi-dimensional code features. Each node in the context-aware syntax tree carries contextual metadata.

[0024] In this application, the original source code, runtime information, and version control data are first obtained. Then, code features are extracted through context-aware syntax tree (FRBT) analysis. FRBT is an enhanced extension of the traditional abstract syntax tree (API), containing not only the syntactic structure of the code but also additional contextual meta-information, enabling each node to carry richer semantic information. This application uses a specific language parser (such as a Java parser or a Python parser) to construct the initial API, and then attaches contextual information to each node to generate a FRBT. It should be noted that, based on the FRBT, the statement execution order and branch dependencies are extracted to construct a control flow graph (CFG). A control flow graph is a graphical representation used to describe all possible execution paths in a program, where nodes represent basic code blocks and edges represent the transition relationships of the execution flow. Therefore, this application, through the control flow graph, can clearly map the program's execution logic and branch structure, and identify key decision points and execution hotspots.

[0025] Simultaneously, this application traces the definition and usage paths of data variables in the code, analyzes data dependencies in the control flow graph, and constructs a data flow graph (DFG). The data flow graph illustrates how data flows from one operation to another in the program, recording the definition and usage points of variables and establishing a complete "definition-use" relationship chain. This analysis is crucial for understanding the data processing logic and variable state changes in the code.

[0026] In this application, dynamic instrumentation technology is used for non-intrusive monitoring of the program to obtain dynamic runtime information. Dynamic instrumentation is a technique that collects runtime data in real time during program execution without modifying the source code. It collects runtime information such as execution paths, actual variable values, and method call frequencies by inserting monitoring points at key locations. For example, in Java programs, bytecode enhancement can be achieved through Java Agent technology using the JVM's Instrumentation interface, enabling data collection without modifying the source code.

[0027] Furthermore, this application also obtains code history data from version control systems (such as Git), including commit history, branch differences, and author modification paths. By analyzing this information, it is possible to identify areas of code change that have been added, deleted, or modified, analyze the context and scope of these changes, and generate version control data. This is particularly important for prioritizing testing of recently modified code areas and understanding the code evolution process.

[0028] Therefore, this application integrates control flow graphs, data flow graphs, runtime information, and version control data to extract code feature vectors and generate multi-dimensional code features. These features include code complexity metrics (such as cyclomatic complexity and nesting depth), test coverage, and historical defect density, which are beneficial for subsequent variant generation and test optimization.

[0029] S102. Based on the multi-dimensional code features, perform code semantic analysis on the multi-dimensional code features using a preset large language model to identify potential defect types and corresponding mutation rules. Combine the preset deep Q-learning model to predict the testing efficiency of the variants. Based on the testing efficiency and the mutation rules, generate a variant to be processed that conforms to the defect type. The testing efficiency is used to evaluate the probability that the variant will have a defect problem related to the test case after executing the preset test case.

[0030] In this application, based on the multi-dimensional code features obtained above, a Large Language Model (LLM) is used for code semantic analysis to identify potential defect types and generate corresponding mutation rules. The Large Language Model (LLM) is a deep learning-based natural language processing model capable of understanding and generating human-like text. In this application, it is used to analyze code structure and semantic features to identify potential defect types and error patterns. This application matches the identified defect types and error patterns with a pre-built defect pattern knowledge base and selects mutation rules that fit the current code context. Specifically, the mutation rules define how to modify the code to simulate common errors in real-world development, including target error patterns such as inverted logical relationships, incorrect boundary conditions, and omissions in null value handling.

[0031] Subsequently, this application dynamically determines the locations of key mutation points based on preliminary candidate mutation regions, runtime information, and version control data. A mutation point refers to the specific location in the code that will be modified to create a mutant. This application adjusts the application location and intensity of mutation rules by considering application factors of the original source code (such as execution frequency, branch coverage, and modification status) to ensure that mutation operations target the most valuable code regions.

[0032] Next, a pre-defined deep Q-learning model is used to predict the testing efficiency of different variants. Deep Q-learning is a reinforcement learning method that uses a deep neural network to approximate the Q-function, evaluating the long-term value of taking a specific action in a given state. In mutation testing, the deep Q-learning model is trained on historical test data to predict the likelihood of a variant being discovered by test cases, i.e., the testing efficiency. This application selects mutation types and locations with testing efficiencies greater than a pre-defined value threshold to generate high-value variant combinations.

[0033] Therefore, this application applies corresponding mutation rules at the identified key mutation points to generate variants that conform to defect types and error patterns. Similar variants are grouped to reduce subsequent execution time, resulting in a set of variants to be processed. A variant is a program version created by making minor modifications to the original program, used to simulate errors that may occur in real-world development.

[0034] S103. Perform syntax checking and equivalence analysis on the mutant to be processed to obtain a valid mutant. Use the test cases to test the valid mutant and record the test execution result of each valid mutant, wherein the test execution result is a survival state or a kill state.

[0035] In this application, after obtaining the variants to be processed, these variants need to be verified and screened to ensure that they are valid test targets. First, this application calls a preset language compiler or interpreter (such as javac or Python interpreter) to perform a syntax check on the variants, verifying their syntactic correctness and capturing compilation error information. Syntactic correctness is a basic requirement for the validity of variants; this application filters out variants with syntactic errors, retaining only those with correct syntax for subsequent analysis. Next, this application performs equivalence analysis to identify variants that are functionally equivalent to the original program. It should be noted that equivalent variants refer to variants that, although their code form is different, have the same actual function as the original program. These variants cannot be distinguished by any test cases and therefore have no testing value. This application employs multiple techniques for equivalence analysis: using a theorem prover (such as Z3) to transform the code into a logical formula for equivalence proof; comparing the control flow structure of the original code and the variants; and performing input sampling to compare the output results. Therefore, this application filters out variants that are functionally equivalent to the original program through syntax checking and equivalence analysis, and only retains valid variants that are not equivalent.

[0036] For example, a theorem prover is a formal verification tool that verifies whether two programs are equivalent through mathematical proof. It converts the programs into mathematical logical expressions and then uses logical reasoning to determine whether the two expressions are equivalent. For instance, the expressions "a>b" and "!(a<=b)" are logically equivalent, despite their different syntactic forms.

[0037] After obtaining valid mutants, this application runs these mutants in parallel on a test execution cluster, tests them using pre-defined test cases, and records the test execution results for each mutant. It should be noted that the test execution results are divided into two states: alive and killed. If a test case can distinguish the mutant from the original program (e.g., producing different outputs or behaviors), the mutant is "killed"; if a test case cannot distinguish the mutant from the original program, the mutant is "alive". A surviving mutant indicates insufficient code region coverage or inadequate test intensity for the current test case.

[0038] S104. Based on the test execution results, calculate the mutation test index and locate code weaknesses. Identify test blind spots based on surviving mutants, so as to generate a visual analysis report containing test strategy optimization suggestions based on the mutation test index, the code weaknesses and the test blind spots. The surviving mutants are used to indicate that the test execution results are valid mutants in the surviving state.

[0039] This application conducts in-depth analysis based on the test execution results of mutants, calculates mutation testing metrics, locates code weaknesses, identifies testing blind spots, and generates intuitive visual analysis reports. First, key mutation testing metrics are calculated, including mutation score, kill rate, test case effectiveness score, and mutation coverage. The mutation score refers to the proportion of mutants killed out of the total number of mutants, reflecting the overall quality of the test suite and its ability to detect defects. The kill rate represents the proportion of mutants killed by a specific test case or test set, used to evaluate the effectiveness of the test cases. The test case effectiveness score measures the contribution of each test case to defect discovery, while the mutation coverage represents the proportion of code covered by mutation points.

[0040] Next, this application analyzes the characteristics of the code regions corresponding to surviving variants to identify test blind spots. Test blind spots refer to code regions that are insufficiently covered or cannot be effectively tested by existing test cases, typically manifesting as complex branching logic, boundary condition handling, or exceptional situations. By identifying these regions, this application can guide the testing team to optimize testing strategies and supplement targeted test cases.

[0041] Simultaneously, by combining code complexity and historical defect data, we analyze defect-intensive and high-risk areas in the code to pinpoint weaknesses. Weak points refer to code areas prone to defects or with existing potential problems, possibly due to poor design, excessive complexity, or frequent modifications. Identifying these weaknesses helps the development team prioritize high-risk areas and proactively prevent potential defects.

[0042] To visually represent the analysis results, this application transforms mutation testing metrics, test blind spots, and code weaknesses into visual charts, including mutation score trend charts, mutant state distribution charts, and test coverage heatmaps. The mutation score trend chart shows the changing trends of mutation testing metrics over time or test iterations; the mutant state distribution chart shows the survival / kill status distribution of different types of mutants; and the test coverage heatmap visually displays the test coverage of various code regions, highlighting test blind spots and weaknesses. Based on these visual charts, this application generates a comprehensive visual analysis report. This report not only presents the test results but also provides suggestions for optimizing test strategies, including directions for test case enhancement, high-value test areas, and automated test coverage suggestions, helping the testing team continuously improve testing practices and enhance software quality.

[0043] S105. Iteratively generate new test cases based on the current surviving variants and the visualization analysis report, and use the new test cases to test the current surviving variants.

[0044] In this application, after completing the analysis and generating the report, the final step is to generate new test cases based on the current surviving mutants and the visualization analysis report, and then use these new test cases to test the current surviving mutants, forming a closed-loop optimization mechanism. Specifically, a test execution path graph is first constructed based on the code execution path of each valid mutant. This test execution path graph is a special type of directed graph where nodes represent code states and edges represent execution transitions. This application assigns an execution probability to each edge in the graph, reflecting the likelihood of the code executing that path under different inputs, and marks the graph nodes where mutation points are located, providing a foundation for subsequent path analysis.

[0045] Next, this application identifies a set of multiple constraints, including resource constraints (such as execution time and memory usage), coverage constraints (code paths that must be covered), dependency constraints (test execution order), value constraints (prioritizing testing high-risk areas), and state constraints (conditions that the system state must satisfy). This application constructs a recursive scaling function and a constraint optimization model, transforming the multi-constraint problem into a weighted single-objective optimization problem, making the complex test path planning problem solvable.

[0046] Then, this application combines the Lagrange multiplier algorithm to handle multiple constraints, determine constraint priorities, and uses a randomization algorithm to handle uncertainties in the test execution path graph, generating a solution space with probability distributions. The Lagrange multiplier method is a classic approach for solving constrained optimization problems, integrating constraints into the objective function by introducing Lagrange multipliers. This application constructs a heuristic pruning strategy to reduce computational space and improve solution efficiency, ultimately obtaining constrained random paths that satisfy multiple constraints through a scaling algorithm. Specifically, based on constrained random paths, this application calculates test paths satisfying multiple constraints for each surviving mutant and identifies shared test paths that can be shared by multiple surviving mutants, reducing redundant execution and generating efficient test execution sequences. The test execution sequence defines the optimal order for executing test cases, maximizing the probability of early defect detection and improving testing efficiency.

[0047] Finally, based on the test execution sequence, this application analyzes high-value paths not covered by current test cases, calculates the input conditions triggering specific paths using a symbolic execution algorithm, and generates test input data that satisfies multiple constraints. Symbolic execution is a program analysis technique that uses symbolic values ​​instead of concrete values ​​to execute the program, and uses a constraint solver to determine the input values ​​that satisfy specific path conditions. This application establishes a mapping relationship between test cases and surviving mutants based on the design boundary values ​​of the mutation points of surviving mutants and the abnormal situations indicated in the visualization analysis report, ultimately generating targeted new test cases. It should be noted that the newly generated test cases in this application are used to test the current surviving mutants, starting a new round of test iterations. Through a closed-loop optimization mechanism, this application can continuously improve the quality and coverage of test cases, gradually eliminating more mutants and improving the effectiveness and efficiency of software testing.

[0048] Therefore, this application can comprehensively improve the intelligence and automation level of mutation testing, significantly improve testing efficiency and test case quality, and provide strong technical support for software quality assurance.

[0049] In one specific embodiment, the process involves acquiring the original source code, runtime information, and version control data; using a context-aware syntax tree constructed by a specific language parser to extract the statement execution order and branch dependencies in the original source code; generating a control flow graph and a data flow graph; and performing feature extraction on the control flow graph, the data flow graph, the runtime information, and the version control data to obtain multi-dimensional code features, including:

[0050] Based on the original source code, an abstract syntax tree is constructed using a specific language parser, and a context-aware syntax tree is generated based on the abstract syntax tree. The nodes of the context-aware syntax tree include variable nodes, function call nodes, and conditional statement nodes. The variable nodes are appended with type and scope information, the function call nodes are appended with parameter type and return value type, and the conditional statement nodes are appended with branch dependency variable information.

[0051] The context-aware syntax tree is subjected to control flow analysis to extract the statement execution order and branch dependencies, and a control flow graph is constructed. The control flow graph is used to map the program execution path.

[0052] The definition and usage paths of data variables in the control flow graph are traced, and the data dependencies in the control flow graph are analyzed to construct a data flow graph. Based on the control flow graph and the data flow graph, a data usage relationship chain is established.

[0053] Non-intrusive monitoring is performed through a preset dynamic instrumentation algorithm to obtain runtime information during program execution, including execution path, actual variable values, and method call frequency.

[0054] Obtain code history, identify newly added, deleted, and modified code change areas based on the code history, analyze the change context relationship, and generate version control data based on the code change areas and the change context relationship. The code history includes code repository historical commit records and branch differences.

[0055] Based on the data, the relationship chain, the runtime information, and the version control data, code feature vectors are extracted, and multi-dimensional code features are generated from the code feature vectors. The code feature vectors include code complexity indicators, test coverage, and historical defect density.

[0056] In this embodiment, firstly, an Abstract Syntax Tree (AST) is constructed based on the original source code using a specific language parser. It should be noted that an AST is a tree-like data structure representing the syntactic structure of program code, where each node represents a construct in the source code. Unlike simple text analysis, an AST preserves the complete syntactic structure of the program and can accurately represent the various syntactic elements in the code and their hierarchical relationships. For different programming languages, this embodiment calls the corresponding language parser; for example, Java programs use JavaParser, and Python programs use the ast module, etc.

[0057] After obtaining the basic AST, a context-aware syntax tree (CAST) is generated using semantic enhancement techniques. The CAST is an important extension to the standard AST, containing not only syntactic structure information but also rich contextual meta-information, making the semantic relationships between nodes clearer. In this embodiment, three types of core nodes are defined in the CAST: variable nodes, function call nodes, and conditional statement nodes, each with specific contextual information appended.

[0058] The variable nodes include type and scope information. Type information includes the variable's static declaration type (such as `int` and `String` in Java) and the dynamic type obtained through type inference (applicable to dynamically typed languages ​​like Python). Scope information records the variable's valid range, including local scope (within a function), class scope (class member variables), or global scope. Furthermore, this embodiment infers the possible value range of the variable through data flow analysis, providing a basis for subsequent path analysis. For example, for an integer variable `x`, the system may infer that the value range of `x` under a specific code path is [1, 10]. The function call nodes include parameter type and return value type information. For each function call, this embodiment records the actual type of the input parameters (rather than just relying on the formal parameter declaration) and the type of the function's return value. Simultaneously, this embodiment also records the definition location of the called function, establishing a direct link between the function call and the function definition, facilitating cross-function data flow and control flow analysis.

[0059] Optionally, conditional statement nodes include branch dependency variable information. For conditional statements such as `if` and `switch`, this embodiment analyzes all variables involved in the conditional expression and records the dependencies between these variables and branch execution. For example, in the condition "if (x>5&&y<10)", this embodiment identifies `x` and `y` as key variables affecting branch selection and records the execution condition "x must be greater than 5 and y must be less than 10". Furthermore, the system also analyzes the preconditions for branch execution, such as constraints that variables must be of a specific type or not empty.

[0060] Therefore, this embodiment constructs a context-aware syntax tree, which becomes the basic data structure for subsequent code analysis, supporting in-depth static analysis and semantic understanding.

[0061] Subsequently, after obtaining the context-aware syntax tree, control flow analysis is performed to extract the statement execution order and branch dependencies, constructing a control flow graph (CFG). A control flow graph is a directed graph used to represent possible paths during program execution, where nodes represent basic code blocks (a continuous sequence of code without branches), and edges represent control flow transitions (such as conditional branches, loop jumps, etc.). Specifically, the control flow analysis process first identifies the basic code blocks in the program. A basic code block is a continuously executed sequence of code without branches or jumps, characterized by a single entry point and a single exit point. This embodiment traverses the context-aware syntax tree, identifies control structures such as sequential statements, conditional statements, and loop statements, and divides the code into multiple basic code blocks.

[0062] Next, the transition relationships between basic code blocks are analyzed, and edges are established in the control flow graph. For sequentially executed code blocks, direct predecessor-successor relationships are established; for conditional statements (such as if-else), edges are created from the conditional statement block to the two branch blocks; for loop structures (such as for and while), back edges are created between the loop body and the loop condition. During this process, the branch dependency variable information in the conditional statement nodes is used to record the execution condition of each edge, i.e., under what conditions the control flow will transfer along this edge.

[0063] After the control flow graph is constructed, this embodiment further analyzes possible execution paths. An execution path refers to a complete path from the program's entry point to its exit point, representing the program's execution flow under specific inputs. By analyzing the paths in the control flow graph, the program's logical structure can be understood, key decision points and possible execution branches can be identified, providing an important basis for subsequent mutation point selection. It should be noted that the control flow graph, as a mapping tool for program execution paths, not only supports static analysis but also provides a structured framework for the collection and correlation of dynamic runtime information, facilitating the understanding of program behavior, prediction of execution paths, and evaluation of code coverage.

[0064] Furthermore, based on the control flow graph, this embodiment traces the definition and usage paths of data variables, analyzes data dependencies, and constructs a Data Flow Graph (DFG). A data flow graph is a graph structure representing how data flows in a program, where nodes represent variable definition or usage points, and edges represent data flow paths. Specifically, data flow analysis first identifies variable definition and usage points in the program. A variable definition point is the location where a variable is assigned a value or initialized, such as x being defined in "x = 5"; a variable usage point is the location where the value of a variable is read, such as x being used in "y = x + 1". Each basic code block in the control flow graph is traversed, marking the variable definition and usage points within it, and recording relevant context information. Next, this embodiment analyzes the definition-use chain (DU chain). A definition-use chain is the set of paths from a variable's definition point to all possible usage points. This embodiment uses control flow analysis to determine the possible definition points corresponding to each usage point, establishing the association between definition and use. For example, if variable x is assigned the value 5 in one branch and the value 10 in another branch, then subsequent statements using x may depend on either of these two points of definition, depending on the execution path.

[0065] Next, this embodiment analyzes the data dependencies in the control flow graph to identify which statements' execution depends on data generated by other statements. Data dependency refers to a statement using a variable value defined by another statement, forming a dependency relationship between statements. By analyzing these dependencies, the system can understand the data flow patterns and variable state changes in the program.

[0066] Therefore, based on the above analysis, this embodiment constructs a data flow diagram to visually display the data flow path in the program. In the data flow diagram, nodes represent the definition or usage operation of variables, and edges represent the data flow relationship from the definition point to the usage point. The data flow diagram and the control flow diagram complement each other, jointly providing a complete view of the program execution logic and data processing logic. Thus, this embodiment establishes a data usage relationship chain based on the control flow diagram and the data flow diagram. The data usage relationship chain is an extended representation of data dependencies, which not only includes direct definition-use relationships but also considers the complete lifecycle and scope of influence of variables in the program. Through the data usage relationship chain, it is possible to track how data propagates and transforms in the program, and identify key data processing points and potential data processing vulnerabilities.

[0067] Furthermore, while static analysis provides a comprehensive view of code structure and logic, it struggles to capture the dynamic behavior of a program during actual runtime. Therefore, this embodiment employs a pre-defined dynamic instrumentation algorithm to perform non-intrusive monitoring, acquiring runtime information during program execution. Dynamic instrumentation is a technique for real-time monitoring and recording program behavior during execution. It collects various runtime information by inserting additional monitoring points (probes) into the program code without modifying the original source code. The non-intrusive nature of dynamic instrumentation allows for the acquisition of rich runtime data without affecting the program's normal functionality. It should be noted that the dynamic instrumentation algorithm used varies depending on the target language and platform. For Java programs, Java Agent technology can be used to enhance bytecode through the JVM's Instrumentation interface; for C / C++ programs, tools such as Pin and DynamoRIO can be used for binary instrumentation; for scripting languages ​​like Python, language-specific hook mechanisms or decorators may be utilized for instrumentation.

[0068] Through dynamic instrumentation, this embodiment can collect three types of core runtime information: First, execution path information records the code paths actually traversed by the program during runtime, including which branches were executed, how many times the loop iterated, etc. This information can verify the execution paths predicted by static analysis and discover code segments that are only triggered under specific conditions. Second, actual variable value information records the specific values ​​of variables at different execution points during program execution. Unlike the possible value ranges inferred in static analysis, these are the exact values ​​of variables in actual execution, providing a more accurate view of data flow. For example, recording the value of the loop counter in each iteration, the actual value of method parameters, or changes in the state of objects, etc. Third, method call frequency information records the number of times and the timing of each method being called in the program, which can identify hot methods (frequently called methods) and key execution paths in the program, and is very important for optimizing resource allocation and focus in mutation testing. In summary, the above runtime information provides empirical verification and supplementation for static analysis, making code analysis more comprehensive and accurate. In particular, it can reveal dynamic behavior patterns and potential problems that are difficult to discover through pure static analysis, such as conditional defects, performance bottlenecks, or abnormal resource usage.

[0069] Furthermore, besides code structure and runtime behavior, the historical evolution of code is also a crucial dimension for understanding software systems. This embodiment acquires code history records, analyzes code changes, and generates version control data. Specifically, it first obtains historical commit records and branch difference information from the code repository from a version control system (such as Git or SVN). The historical commit records contain detailed information about each code change, such as commit time, author, commit message, and change content; branch differences reflect code differences between different development branches, especially complex changes that may be introduced when merging branches. Secondly, based on the acquired history records, it identifies areas of added, deleted, and modified code changes. Using difference analysis algorithms (such as Git's diff algorithm), it compares different versions of code to precisely locate which files, functions, or lines of code have changed. By analyzing the content and patterns of changes, it can distinguish between different types of changes, such as simple formatting adjustments, feature enhancements, or bug fixes. Next, it analyzes the context of the changes to understand the scope of impact and potential risks of the code changes. Contextual relationships include dependencies between the changed code and other code, whether the changes affect critical functional modules, and whether the changes span multiple components. This analysis helps identify high-risk changes and potential new defects.

[0070] Subsequently, this embodiment generates version control data based on the code change areas and change context relationships. For example, this version control data includes a change frequency heatmap (showing which code areas change most frequently), an author responsibility matrix (showing which developers are responsible for which code areas), and a defect fix history (recording changes related to defect fixes), etc., providing important guidance for subsequent mutation testing, such as strategies like prioritizing testing recently modified code and focusing on areas with frequent historical defects.

[0071] Optionally, version control data analysis can also identify pattern changes and trends in the code, such as the increasing trend of code complexity and changes in module coupling, which are important indicators for evaluating code quality and maintainability.

[0072] Therefore, after completing the above analyses, based on data usage relationship chains, runtime information, and version control data, code feature vectors are extracted to generate multi-dimensional code features. Code feature vectors are a set of numerical indicators used to quantify and describe various attributes and characteristics of the code. The code feature vectors extracted in this embodiment include three core indicators:

[0073] 1. Code complexity metrics quantify the structural complexity and difficulty of understanding code. Commonly used complexity metrics include: Cyclomatic Complexity, which measures the branching complexity of code and is calculated as the number of independent paths in the control flow graph; Nesting Depth, which measures the nesting level of code, such as the number of nested if statements within if statements; Method Length, which measures the number of lines of code contained in a method; and Parameter Count, which measures the number of parameters in a method. These metrics collectively reflect the complexity of the code and the potential difficulties in understanding it.

[0074] 2. Test coverage metrics reflect the extent to which existing test cases cover the code. By analyzing test execution data, various coverage metrics are calculated: Statement Coverage, which measures the proportion of code statements executed under test; Branch Coverage, which measures the proportion of branches executed under test; Path Coverage, which measures the proportion of complete paths executed under test; and Method Coverage, which measures the proportion of methods called and executed. These metrics reflect the comprehensiveness of the tests and any potential blind spots.

[0075] 3. Historical defect density metrics reflect the frequency and distribution of defects in the code throughout history. By analyzing defect fix records and code change history, defect density-related metrics are calculated: Historical Defect Count (recording the number of defects found in the code region historically); Defect Fix Frequency (recording the frequency of defect fixes in the code region); Defect Severity (recording the average severity of historical defects); and Recent Change Frequency (recording the frequency of recent modifications to the code region). These metrics help identify high-risk areas and historical problem points in the code.

[0076] Therefore, this embodiment integrates feature vectors to generate multi-dimensional code features. Multi-dimensional code features are a structured code representation that comprehensively describes code characteristics from three dimensions: static structure, dynamic behavior, and historical evolution. In this embodiment, the multi-dimensional code features not only include the numerical values ​​of each feature indicator but also preserve the correlation and hierarchical structure between the indicators, providing rich and accurate input for subsequent intelligent mutation generation.

[0077] Therefore, this embodiment achieves in-depth analysis and feature extraction of the original source code, establishing a comprehensive model that includes code structure, semantics, behavior, and historical information, providing a solid data foundation for mutation testing. These multi-dimensional features enable the system to understand the code's internal logic and potential risks, thereby generating more targeted and valuable variants, significantly improving the efficiency and effectiveness of mutation testing.

[0078] In one specific embodiment, the step of performing code semantic analysis on the multi-dimensional code features using a preset large language model to identify potential defect types and corresponding mutation rules, predicting the testing efficiency of the variants using a preset deep Q-learning model, and generating a variant to be processed that conforms to the defect type based on the testing efficiency and the mutation rules, includes:

[0079] The code structure and semantic features of the multi-dimensional code features are analyzed using a pre-defined large language model to identify potential defect types and error patterns.

[0080] The defect type and error pattern are matched with a pre-built defect pattern knowledge base, and a mutation rule that fits the current code context is selected to generate a preliminary mutation candidate region. The mutation rule includes the target error pattern, which includes logical relationship reversal, boundary condition error, and null value handling omission.

[0081] Based on the preliminary mutation candidate region, the runtime information, and the version control data, the location of key mutation points is determined. The application location and intensity of the mutation rules are adjusted in combination with the code application factors of the original source code, including execution frequency, branch coverage, and modification status.

[0082] The test efficiency of different variants is predicted by a preset deep Q-learning model, and the variant type and position corresponding to the test efficiency being greater than a preset value threshold are selected to generate the corresponding high-value variant combination.

[0083] Based on the high-value variant combination, corresponding mutation rules are applied at the key mutation point to generate variants that conform to the defect type and the error pattern, and similar variants are grouped to obtain variants to be processed.

[0084] In this embodiment, after acquiring multi-dimensional code features, the intelligent mutant generation operation in the mutation test is executed. Through the semantic understanding capabilities of the Large Language Model (LLM) and the predictive capabilities of deep Q-learning, the transformation from code features to high-value mutants is achieved. First, a pre-set Large Language Model (LLM) is used to analyze the multi-dimensional code features, identifying potential defect types and error patterns. The Large Language Model is a deep learning-based natural language processing model that, through pre-training and fine-tuning, can understand and generate human-like text. In code analysis, this type of model has demonstrated a profound understanding of code syntax and semantics, capable of capturing subtle patterns and potential problems in the code. It should be noted that the Large Language Model used has been trained on a dedicated code corpus and can understand the syntax and idiomatic patterns of multiple programming languages. Unlike traditional static analysis tools, the Large Language Model can not only identify syntactic errors but also understand the semantic intent and implementation logic of the code, thereby discovering deeper potential problems. For example, it can identify code segments that are formally correct but logically flawed, such as boundary errors in conditional statements or omissions in resource management.

[0085] In this embodiment, multi-dimensional code features are input into a large language model during the analysis process, allowing the model to perform in-depth analysis of code structure and semantic features. Code structure features include control flow structures (such as branches and loops), data flow patterns (such as variable usage chains), and function call relationships; semantic features include the code's functional intent, algorithm implementation methods, and the application of design patterns. Based on these features, combined with code patterns and best practices learned during its pre-training process, the model identifies potential defect types and error patterns in the code. In this embodiment, defect types refer to specific problem categories in the code that may lead to erroneous behavior, such as type errors, null pointer exceptions, and resource leaks. Error patterns refer to specific coding methods or cognitive biases that lead to defects, such as improper boundary condition handling or incomplete exception handling. Through the analysis of the large language model, various potential defect types and error patterns in the code can be identified, providing a basis for subsequent mutation rule selection.

[0086] Subsequently, after identifying potential defects, the defect type and error pattern are matched against a pre-built defect pattern knowledge base. A mutation rule suitable for the current code context is selected to generate preliminary mutation candidate regions. The defect pattern knowledge base is a pre-built structured database containing various common defect patterns, error types, and corresponding mutation rules in software development. This knowledge base is based on a large number of open-source project defect repair records, software security vulnerability databases, and expert experience summaries, covering a broad defect spectrum from basic syntax errors to complex logic vulnerabilities. Each defect pattern includes a detailed feature description, triggering conditions, impact scope, and response strategies, facilitating accurate matching and analysis.

[0087] It should be noted that the mutation rules refer to a set of rules on how to modify the original code to simulate specific types of defects, defining the specific operation methods and application conditions of mutation. The mutation rules include three main types of target error patterns: First, logical relation inversion means reversing or modifying the logical expressions in the code, such as changing logical AND (&&) to logical OR (||), changing equal to (==) to not equal to (!=), etc. This type of mutation simulates common mistakes made by developers in logical judgments. For example, mutating "if(x>0&&y>0)" to "if (x>0 || y>0)" simulates the error of overly broad conditional judgment. Second, boundary condition errors refer to modifying the boundary judgments in the code, such as changing greater than or equal to (>=) to greater than (>), changing less than (<) to less than or equal to (<=), etc. This type of mutation simulates common mistakes made by developers when dealing with boundary situations. For example, mutating "if (index<array.length)" to "if (index<= array.length)" simulates the risk of out-of-bounds array access. Third, null value handling omission means removing or modifying the null value checks in the code, such as deleting null pointer checks, modifying default value handling, etc. This type of mutation simulates common problems where developers ignore null value situations. For example, mutating "if (obj != null) {obj.method();}" to "obj.method();" simulates the potential risk of null pointer exceptions.

[0088] In this regard, in this embodiment, through a matching algorithm, the identified defect types and error patterns are compared with the patterns in the knowledge base, and the mutation rule most suitable for the current code context is selected. The matching process takes into account factors such as the language characteristics of the code, the application domain, and the functional complexity, ensuring that the selected mutation rule can truly simulate the errors that may occur in actual development. Specifically, based on the selected mutation rule, a preliminary mutation candidate region is generated. The mutation candidate region refers to the set of positions in the code where the mutation rule may be applied, and each candidate region is associated with a specific mutation rule. For example, for the logical relation inversion rule, the candidate region may include all conditional judgment statements; for the boundary condition error rule, the candidate region may include all statements involving index or range checks.

[0089] In this embodiment, after obtaining the initial candidate mutation regions, it is necessary to further pinpoint the key mutation points and adjust the application of mutation rules according to the actual situation of the code. Specifically, the locations of key mutation points are first determined based on the initial candidate mutation regions, runtime information, and version control data. Key mutation points refer to the optimal locations for applying mutation rules; these locations should have high testing value and defect exposure potential. For example, these points are located by comprehensively analyzing multiple factors: from runtime information, the system analyzes code regions with high execution frequency but insufficient test coverage; these regions are often hiding places for potential defects. From version control data, the system focuses on code regions that have been frequently modified recently or have a high density of historical defects; these regions are often prone to introducing new problems. From the candidate mutation regions, the system prioritizes locations that highly match the identified defect types; applying mutation rules to these locations is more likely to simulate real defects.

[0090] Next, this embodiment combines the code application factors of the original source code to adjust the application location and intensity of mutation rules. Code application factors refer to the code characteristics and runtime environment features that affect the mutation effect, mainly including: Execution frequency, which refers to the frequency with which the code is executed in actual operation. Code areas with high-frequency execution have a greater impact on system functionality, and defects within them are more easily triggered; therefore, mutation rules should be prioritized for these areas. For example, code located in the main functional flow has a higher execution frequency than exception handling code that only executes under specific conditions. Secondly, branch coverage refers to the degree to which test cases cover code branches. For code areas with low branch coverage, existing tests may have blind spots, making them more difficult to detect after applying mutation rules; therefore, the mutation intensity of these areas should be appropriately increased to verify the adequacy of the tests. For example, for complex conditional branches with only 30% test coverage, multiple different types of mutants will be generated. Furthermore, modification history refers to the code's historical change record. Recently modified code areas are more likely to introduce new defects; therefore, the system will prioritize mutation for these areas. In particular, code modified collaboratively by multiple people or across components has a higher risk of introducing defects, and the value of mutation testing is greater. Based on the above factors, this embodiment dynamically adjusts the application location and intensity of mutation rules. Adjusting the application location might include moving mutation points from low-value areas to high-value areas, or selecting more critical statements within the same function; intensity adjustments might include increasing or decreasing the number of specific types of mutations, or adjusting the extreme degrees of mutation parameters. Therefore, this embodiment, through dynamic adjustment, ensures that mutation testing resources are concentrated in the most valuable code regions, improving the efficiency and effectiveness of mutation testing.

[0091] Furthermore, to further improve the quality and testing value of mutants, the system predicts the testing efficiency of different mutants using a pre-defined deep Q-learning model and selects high-value mutation combinations. Deep Q-learning is an important algorithm in reinforcement learning, combining the advantages of deep neural networks and Q-learning, and is capable of handling decision-making problems in high-dimensional state spaces. In mutation testing, the deep Q-learning model is used to predict the testing efficiency of mutants, i.e., the probability that a mutant will expose problems after executing test cases. In this embodiment, the deep Q-learning model models the mutation testing process as a Markov Decision Process (MDP), where: State represents the characteristics of the code and the current mutation status, including multi-dimensional features such as code complexity, coverage, and historical defect density; Action represents possible mutation operations, such as applying a specific type of mutation rule at a specific location; Reward represents the degree to which a mutant is killed by a test case (i.e., the test discovers the problem introduced by the mutation), reflecting the effectiveness of the mutation; Transition Probability represents the probability distribution of code state changes after executing a mutation operation.

[0092] Optionally, this embodiment approximates the Q-function using a deep neural network to predict the long-term value of performing a specific mutation operation under a given code state. Specifically, the model input includes code feature vectors (such as complexity metrics, coverage, defect history, etc.) and mutation operation descriptions (such as mutation type, application location, etc.), and the output is the expected value score of that mutation operation, i.e., a test efficiency prediction. This embodiment uses this model to evaluate all possible variants, calculate their test efficiency scores, and select mutation types and locations with test efficiency greater than a preset value threshold. The value threshold is dynamically set by the system based on historical test data and resource constraints to ensure that the generated variants have sufficient test value and avoid resource waste.

[0093] Therefore, through prediction using deep Q-learning, this embodiment is able to identify the high-value variant combinations most likely to expose testing defects from a massive number of possible variant combinations, significantly improving the efficiency and accuracy of variant testing.

[0094] Furthermore, this embodiment applies corresponding mutation rules at key mutation points based on high-value variant combinations to generate variants that conform to defect types and error patterns. Similar variants are then grouped to obtain the final set of variants to be processed. Variant generation is the process of applying mutation rules to the source code. Specifically, the original source code is first parsed to pinpoint the precise location of key mutation points. Then, the code is modified according to the mutation rules to generate a new code version, i.e., a variant. Mutation operations may include: replacing operators (e.g., replacing "+" with "-"), modifying conditional expressions (e.g., changing "if(a>b)" to "if(a>=b)"), deleting statements (e.g., deleting null checks), and adding statements (e.g., adding additional conditional statements).

[0095] Optionally, to ensure the quality and diversity of variants, this embodiment employs multiple strategies during the generation process: for the same mutation point, different types of mutation rules may be applied to generate multiple variants covering different error scenarios; for complex code structures (such as nested conditions and compound expressions), the system analyzes its components and applies mutation rules to different parts separately to generate more granular variants; for critical functional points, the system generates variants for boundary and extreme cases to test the robustness of the code under abnormal conditions.

[0096] After generating a large number of variants, this embodiment groups similar variants to improve the efficiency of subsequent testing. Variant grouping refers to aggregating variants with similar functions or structures together for management and testing as a whole. This embodiment uses multiple similarity measurement methods for grouping: Code similarity: Based on the similarity of abstract syntax trees or code text, variants that modify similar code structures are grouped together; Functional similarity: Based on the function and context of the mutation point, variants that affect similar functions are grouped together; Mutation rule similarity: Based on the type of mutation rule applied, variants that use the same rule but in different locations are grouped together.

[0097] The grouped mutant sets are more structured and organized, facilitating subsequent test execution and result analysis. For example, by selecting a representative mutant for each group for initial testing, if the representative mutant is killed, it can be inferred that other mutants in the same group may also be killed, thereby reducing the testing workload.

[0098] Thus, this embodiment ultimately generates a set of high-quality, high-value variants to be processed. These variants are not randomly generated, but carefully selected based on in-depth code analysis, semantic understanding, and machine learning predictions. They effectively simulate various defects that may occur in actual development, providing ideal test targets for mutation testing. Compared with traditional mutation testing methods, the intelligent variant generation process of this embodiment has significant advantages: First, through semantic understanding of a large language model, it can identify deeper potential defects; second, through efficiency prediction using deep Q-learning, it can prioritize the generation of high-value variants; finally, through dynamic adjustment and intelligent grouping, it significantly improves the efficiency and accuracy of mutation testing. This artificial intelligence-based mutation testing method provides strong technical support for software quality assurance.

[0099] In one specific embodiment, the process of performing syntax checking and equivalence analysis on the mutant to be processed to obtain valid mutants, testing the valid mutants using the test cases, and recording the test execution results for each valid mutant includes:

[0100] Call a preset language compiler or interpreter to verify the grammatical correctness of the variant to be processed and capture compilation error information. Filter out variants to be processed whose grammatical information does not meet the preset grammatical conditions, and retain variants to be processed whose grammatical information meets the preset grammatical conditions.

[0101] Using a preset theorem prover, the code of the retained variant to be processed is converted into a logical formula for equivalence proof. The control flow structure of the original source code and the retained variant to be processed is compared. The comparison and output results are obtained by sampling the input and filtering out variants to be processed that are functionally equivalent to the original source code, thus obtaining valid variants.

[0102] The effective variants are run in parallel on the test execution cluster, and the effective variants are tested using preset test cases. The test execution results of each effective variant are recorded.

[0103] In this embodiment, after generating the variants to be processed, it is necessary to ensure that these variants have sufficient quality and testing value, and to conduct actual tests on them. This embodiment details the three key stages of this process: syntax checking, equivalence analysis, and test execution. These three stages together constitute a rigorous variant screening and verification mechanism, ensuring that the variants ultimately used for testing can realistically simulate software defects and effectively evaluate the quality of test cases. First, a preset language compiler or interpreter is invoked to verify the syntactic correctness of the variants to be processed and capture compilation error information. Variants whose syntactic information does not meet the preset syntactic conditions are filtered out, while those whose syntactic information meets the conditions are retained. The language compiler is a software tool that converts high-level programming language code into machine code or intermediate code. For statically typed languages ​​(such as Java and C++), the compiler performs strict syntax and type checks during compilation to ensure that the code conforms to the language specification. For example, the Java compiler (javac) checks whether the code conforms to Java syntax rules, including variable declarations, method calls, and expression syntax; the C++ compiler (such as g++ and clang++) checks C++ syntax rules and the type system. Secondly, an interpreter is a software tool that directly executes program code, typically used in dynamically typed languages ​​(such as Python and JavaScript). While an interpreter doesn't perform a complete compilation before execution like a compiler, it still performs syntax analysis before or during execution. For example, the Python interpreter checks the syntax correctness of the code before execution, although type checking usually occurs at runtime.

[0104] In mutation testing, syntax checking is the first hurdle to ensure the basic executability of the mutant. This embodiment performs the following steps for each mutant to be processed: First, identify the target programming language of the mutant and select the appropriate compiler or interpreter. For multi-language projects, different language processing tools need to be invoked, such as javac for Java code, the Python interpreter for Python code, and the V8 engine for JavaScript code. Next, the selected compiler or interpreter is invoked to perform syntax checking on the mutant, which includes preprocessing (such as macro expansion in C / C++), lexical analysis (decomposing the code into a sequence of tokens), syntax analysis (checking whether the sequence of tokens conforms to the language syntax), and semantic analysis (checking type compatibility, variable scope, etc.). This embodiment captures all errors and warnings generated during compilation or interpretation, including syntax errors, type errors, undefined references, etc. Then, based on the captured error information, the syntax correctness of the mutant is evaluated. This embodiment defines preset syntax conditions as the minimum acceptable syntax standard for the mutant, which may include basic requirements such as no syntax errors, no type errors, and no undefined references, as well as possible warning level restrictions (such as allowing minor warnings but not allowing severe warnings). Finally, variants that do not meet the preset grammatical conditions are filtered out, and only grammatically correct variants are retained for the next stage of analysis. For example, if a mutation operation results in mismatched parentheses, illegal operator usage, or type-incompatible assignment, then this variant will be eliminated at this stage.

[0105] Therefore, the syntax checking phase ensures that the variants entering subsequent analysis are at least syntactically executable, avoiding invalid tests caused by simple syntax errors during the test execution phase, and improving the efficiency and quality of variant testing results.

[0106] Following syntax checking, this embodiment further analyzes the functional equivalence between the variant and the original program, filtering out variants that, while syntactically correct, have identical functionality. This embodiment employs multiple techniques for equivalence analysis, including: using a pre-defined theorem prover to convert the code into logical formulas for equivalence proof; comparing the control flow structure of the original source code and the variant; and comparing output results through input sampling. This multi-layered equivalence analysis ensures the system can accurately identify and filter functionally equivalent variants.

[0107] Theorem Prover is a formal verification tool that verifies program properties, including program equivalence, using mathematical logic methods. In mutation testing, theorem provers (such as Z3, CVC4, Isabelle / HOL, etc.) are used to transform the original program and its variants into logical formulas, and then the equivalence of these formulas is verified. Logical formula transformation is the process of representing program code as mathematical logical formulas. In this embodiment, the program is first symbolized, converting variables, operators, and control structures into logical symbols and expressions. For example, the assignment statement "x = a + b" can be transformed into the equation "x' = a + b", where x' represents the value of x after the assignment; the conditional statement "if (c) then s1 elses2" can be transformed into the conditional expression "c → s1 ∧ ¬c → s2". In this way, the behavior of the entire program can be precisely described by a set of logical formulas. Equivalence proof is the process of verifying whether two sets of logical formulas produce the same result under all possible inputs. This embodiment combines the logical formulas of the original program and the variant into an implication relation (such as "the output of the original program equals the output of the variant"), and then uses a theorem prover to verify whether this relation always holds. If the theorem prover can prove that this relation always holds, then the original program and the variant are functionally equivalent.

[0108] In addition to formal equivalence proofs, this embodiment also uses control flow structure comparison as an auxiliary means. Control flow structure comparison is the process of analyzing whether the execution paths and branch logic of the original program and the variant are the same. This embodiment constructs the control flow graphs (CFGs) of both programs and compares the structural features of the graphs (such as the number of nodes, edges, and path distribution) and the conditional expressions of key decision points. If the control flow structures and key decision points of the two programs are exactly the same, they are likely to be functionally equivalent.

[0109] In addition, another practical equivalence detection method is input sampling execution comparison. This embodiment generates a set of test samples covering different input scenarios, executes these samples on both the original program and the variant, and compares the execution results. If the outputs of both are exactly the same on all test samples, this variant is marked as "potentially equivalent" for further analysis. Input sampling strategies typically include: boundary values ​​(such as the maximum and minimum values ​​of integers), special values ​​(such as 0, null, and empty strings), random values, and typical inputs from historical tests.

[0110] Therefore, through the comprehensive application described above, this embodiment can effectively identify and filter functionally equivalent variants. The theorem proof provides rigorous mathematical guarantees, the control flow comparison provides structural-level judgment, and the input sampling provides empirical verification. This multi-faceted equivalence analysis greatly improves the accuracy and efficiency of variant screening.

[0111] After equivalence analysis, this embodiment obtained a set of non-equivalent valid variants. These variants satisfy two key conditions: syntactically correct (can be compiled and executed) and functionally non-equivalent (behave differently from the original program). They represent various possible defects in the original program and provide ideal targets for test case quality evaluation.

[0112] Furthermore, after identifying valid mutants, these mutants are run in parallel on the test execution cluster, tested using pre-defined test cases, and the test execution results for each valid mutant are recorded. A test execution cluster is a set of computing resources used to execute test tasks in parallel. In mutation testing, because a large number of mutants need to be executed, single-machine serial execution is often inefficient; therefore, a distributed cluster is used for parallel testing. A test execution cluster typically consists of multiple physical servers or virtual machines, each equipped with independent processor, memory, and storage resources, capable of executing multiple test tasks simultaneously.

[0113] For example, the parallel testing architecture used in this embodiment typically includes the following components: The scheduler is responsible for managing the allocation of test tasks and tracking their execution status. It combines mutants and test cases into test tasks, allocates tasks to worker nodes based on resource availability and priority, monitors task execution status, handles failure retries, and summarizes results. Worker nodes are the computational units that execute specific test tasks. Each worker node receives the tasks allocated by the scheduler, prepares the test environment (e.g., loading mutant code, configuring test dependencies), executes test cases, collects execution results, and returns the results to the result collector. The result collector is responsible for aggregating and storing test execution results. It receives execution results from each worker node, performs formatting and standardization processing, and stores the results in a central database for subsequent analysis and report generation. The monitoring system is responsible for monitoring the health status and performance metrics of the entire test execution process. It collects runtime data from each component (e.g., CPU utilization, memory usage, network traffic), detects anomalies (e.g., node failures, task timeouts), and provides a real-time monitoring interface and alarm mechanism.

[0114] During parallel test execution, this embodiment employs efficient resource allocation and task scheduling strategies to ensure rapid test completion:

[0115] 1. Resource-Aware Scheduling: Dynamically adjust task allocation based on the characteristics of mutants and test cases (such as execution time and resource requirements) to avoid resource bottlenecks and uneven load distribution. For example, compute-intensive mutants will be assigned to nodes with stronger CPU performance, while I / O-intensive mutants will be assigned to nodes with better storage performance.

[0116] 2. Batch processing optimization: Group similar variants or test cases together for processing, reducing the overhead of environment preparation and context switching. For example, for variants of the same type, the system will try to execute them continuously on the same node, reusing the already loaded test environment and dependency libraries.

[0117] 3. Prioritized Execution: Execution priorities are set based on the predicted value of the mutants and historical data. Mutants more likely to be killed by test cases are executed first, allowing useful test results to be obtained earlier. For example, high-value mutants predicted based on deep Q-learning models will receive higher execution priority.

[0118] For each variant's test execution, this embodiment records the following key information: Execution Status: This indicates whether the test completed successfully. Possible statuses include: successful completion (test ended normally), timeout termination (execution time exceeded a preset limit), and abnormal termination (an uncaught exception caused a crash). This status information helps identify serious defects in the variant, such as infinite loops or fatal errors. Test Result: This indicates whether the test case passed. For each variant and test case combination, the system records whether the test result is pass or fail. If a test case that passed on the original program fails on the variant, the test case is considered to have successfully "killed" the variant; conversely, if the test case still passes on the variant, the variant is considered to be "alive." Output Difference: This records the output differences between the variant and the original program when executing the same test cases. The system collects various output information, including return values, output streams (such as standard output and file output), and state changes (such as database state and file system state). By comparing these outputs, a detailed understanding of the behavioral changes caused by the variant can be obtained. Performance metrics record the performance characteristics of test execution, including execution time, memory usage, and CPU utilization. These metrics help identify performance-related defects, such as performance degradation or resource leaks caused by mutations. Therefore, the above execution result data is standardized and stored in a central database, providing a complete data foundation for subsequent analysis and report generation. This embodiment performs real-time aggregation and analysis of execution results, calculating key metrics such as mutation score (the proportion of mutants killed) and test case effectiveness (the number of mutants killed per test case), to initially assess the quality and coverage of the test suite. Among these, the parallel test execution phase is the most time-consuming and critical part of mutation testing, directly generating the core result data of mutation testing. Through an efficient parallel architecture and fine-grained task scheduling, this embodiment can complete the test execution of a large number of mutants within an acceptable time, providing comprehensive data support for subsequent result analysis and test optimization.

[0119] Therefore, this embodiment ensures high quality and efficiency in mutation testing through three stages: syntax checking, equivalence analysis, and parallel test execution. Syntax checking filters out unexecutable mutants, equivalence analysis filters out equivalent mutants with no testing value, and parallel test execution efficiently obtains the test results of the mutants. These three stages together constitute a rigorous and efficient mutant processing flow, which is the key link in the entire mutation testing method.

[0120] In one specific embodiment, based on the test execution results, the step of calculating mutation test indicators and locating code weaknesses, and identifying test blind spots based on surviving mutants, so as to generate a visual analysis report containing test strategy optimization suggestions based on the mutation test indicators, the code weaknesses, and the test blind spots, including:

[0121] Based on the test execution results, mutation test metrics are calculated, including mutation score, kill rate, test case validity score, and mutation coverage. The mutation score indicates the proportion of killed mutants to the total number of mutants, and the killed mutants indicate the effective mutants whose test execution results are in the killed state.

[0122] Analyze the code region features corresponding to the surviving mutants to determine the test blind zone. The code region features include complex branching logic and boundary conditions.

[0123] Based on the test execution results, combined with code complexity and pre-acquired historical defect data, analyze the defect-dense areas and high-risk areas in the code, and locate the weak points in the code;

[0124] The mutation test indicators, test blind spots, and code weaknesses are transformed into mutation score trend charts, mutant state distribution charts, and test coverage heatmaps, and then visualized.

[0125] Based on the mutation score trend map, the variant state distribution map, and the test coverage heatmap, a visualization analysis report is generated. The visualization analysis report is used to indicate the direction of test case enhancement, identify high-value test areas, and automate test coverage.

[0126] In this embodiment, after completing the mutant test execution, a deep analysis of the test execution results is conducted to calculate mutation test metrics, locate code weaknesses, identify test blind spots, and ultimately generate an intuitive and effective visual analysis report. This not only provides a comprehensive assessment of the current test quality but also offers specific and feasible suggestions for test strategy optimization. Specifically, firstly, based on the test execution results, a series of mutation test metrics are calculated to provide a quantitative basis for test quality evaluation. Mutation test metrics are a set of quantitative indicators used to measure the effectiveness of the test suite and code coverage, forming the core data foundation for evaluating test quality. First, the Mutation Score is the most basic and important metric in mutation testing, indicating the proportion of mutants killed out of the total number of mutants. The Mutation Score directly reflects the test suite's ability to find program defects; a higher score indicates a more effective test suite. Second, the Kill Rate refers to the proportion of a specific type of mutant that is killed. Unlike the overall Mutation Score, the Kill Rate focuses on the testing effectiveness of different types of mutants, helping to identify which types of defects the test performs poorly on. Kill rates are typically calculated based on mutation type (e.g., logical operator mutations, conditional boundary mutations, etc.), code structure (e.g., loop mutations, exception handling mutations, etc.), or functional module. Third, the Test Case Effectiveness Score is used to evaluate the quality and contribution of individual test cases. For each test case, this embodiment calculates the number of mutants killed independently (i.e., mutants that can only be killed by this test case) and the total number of mutants killed, taking both factors into account to arrive at the test case effectiveness score. Efficient test cases can independently kill multiple mutants, indicating their significant value to the test suite; while redundant test cases may not kill any mutants independently, indicating they can be replaced by other test cases. Therefore, this embodiment typically uses a weighted calculation method to obtain the test case effectiveness score, reflecting the relative importance of independent and total contributions. Fourth, Mutation Coverage measures the proportion of mutants covered by test cases, similar to code coverage, but focusing on mutation points rather than lines of code. Mutation coverage reflects whether test cases have adequately executed the code paths containing mutations.

[0127] To address this, this embodiment first preprocesses the test execution results when calculating the aforementioned metrics, cleaning up abnormal data and incomplete records to ensure the analysis is based on valid data. For example, incomplete test records caused by system failures are removed, and results from repeated executions are merged. Next, the status of the variants is determined according to predefined criteria: killed state (test case detected a variant), alive state (no variant detected by any test case), or timeout state (execution exceeded the predetermined time limit). Timeout variants are typically excluded from the calculation or analyzed separately, as they may represent specific types of program errors (such as infinite loops). Then, each metric is calculated according to the above formula, while simultaneously generating confidence intervals and error estimates to reflect the statistical reliability of the results. For large projects, sampling analysis methods may be used to estimate overall metrics based on representative samples, improving analysis efficiency. Finally, the calculated results are compared with historical data and industry benchmarks to assess the relative level of current test quality. For example, the current variant score is compared with the project's historical average or with typical variant scores from projects of similar size and complexity. Therefore, the variant test metrics collectively constitute a multi-dimensional view of test quality assessment, ensuring the accuracy and reliability of the results.

[0128] Following the calculation of metrics, this embodiment further analyzes the characteristics of the code regions corresponding to surviving mutants to identify test blind spots. Test blind spots refer to code regions that test cases have failed to effectively cover or verify; these regions may conceal undiscovered program defects. Surviving mutants are mutants that have not been killed after all test cases have been executed. Surviving mutants reflect deficiencies in the test suite; either the tests failed to reach the mutation point, or they were executed but failed to detect the behavioral changes caused by the mutation. This embodiment reveals weaknesses in test coverage by analyzing the distribution and characteristics of surviving mutants.

[0129] Furthermore, code region characteristics refer to the features of code structure, logic, and context, which affect the difficulty and effectiveness of testing. This embodiment focuses on analyzing two key characteristics: 1. Complex Branch Logic refers to code structures containing multiple conditional judgments, nested conditions, or complex expressions. These structures often have multiple execution paths, requiring carefully designed test cases to fully cover them. This embodiment identifies complex branches through static analysis, such as conditional expressions containing multiple logical operators (&&, ||), if-else structures with nesting depth exceeding a threshold, and switch statements with multiple case branches. For each complex branch, the distribution of surviving variants is analyzed to determine which branch condition combinations are not covered by tests. For example, in the conditional expression "if ((a>0&&b>0) || (c>0&&d>0))", the test may only cover the case where the first sub-condition (a>0&&b>0) is true, while the case where the second sub-condition is true is not tested. 2. Boundary conditions refer to the logic of a program handling extreme or special values, such as array index boundaries, numerical range boundaries, and null value handling. Boundary conditions are common areas of defect occurrence and are often overlooked in testing. Identify boundary condition-related code through pattern matching and semantic analysis, such as expressions containing boundary comparisons (=, >=, <=), array index calculations, division operations (which may lead to division by zero errors), and pointer or reference operations (which may lead to null pointer exceptions). Pay special attention to surviving variants in these areas and analyze whether test cases consider boundary and special value cases. For example, for the array access code "array[index]", check whether the tests cover the cases where index is 0, the maximum valid value, and out-of-bounds values.

[0130] In this embodiment, test blind spots can be identified using the following methods: First, Cluster Analysis: Surviving variants are clustered by code location, variant type, and functional module to identify regions where surviving variants are concentrated. These regions typically represent major blind spots in test coverage. Density clustering algorithms (such as DBSCAN) or hierarchical clustering methods are used to group variants based on their similarity and identify high-density groups. Second, Path Analysis: This checks which execution paths have the most surviving variants, as these paths may not be adequately covered by tests. This embodiment constructs a control flow graph, marks the locations of surviving variants, and identifies paths with a high proportion of surviving variants, which are usually blind spots in test design and require supplementary targeted test cases. Third, Data Flow Analysis: This tracks the flow and processing of data in the program to identify insufficiently tested data processing stages. Special attention is paid to the links between data definition points (variable assignment) and usage points (variable reading) to check if most variants survive on any data flow path, which may indicate that the tests have failed to verify the correctness of data processing. Fourth, Condition Coverage Analysis checks whether various combinations of values ​​for a conditional expression are covered by tests. It analyzes the distribution of surviving variants in the conditional expression to infer which conditional value combinations have not been tested or verified. For example, for the condition "A&&B", it checks whether the four combinations (true, true), (true, false), (false, true), and (false, false) are covered. Therefore, through the above analysis, this embodiment generates a test blind spot report, clearly identifying code areas with insufficient test coverage, untested conditional combinations, and potentially overlooked boundary conditions. This directly guides the supplementation and improvement of test cases, filling the gaps in test coverage.

[0131] Furthermore, in addition to analyzing test coverage, this embodiment also analyzes defect-intensive and high-risk areas in the code based on test execution results, combined with code complexity and pre-acquired historical defect data, to pinpoint code weaknesses. Code weaknesses refer to areas in the code that are prone to defects, have low quality, or are poorly maintainable. These areas typically have high complexity, frequent modification history, a large number of historical defects, or poor design structures. Identifying code weaknesses helps optimize test resource allocation, allowing more testing effort to be focused on high-risk areas.

[0132] Secondly, code complexity is an indicator that measures the complexity and difficulty of understanding code structure. This embodiment uses several complexity measurement methods, including: First, cyclomatic complexity measures the number of linear independent paths in the code, reflecting the complexity of branching logic. Second, cognitive complexity measures the difficulty of understanding the code, considering factors such as nesting levels, recursion, and interrupted control flow. Unlike cyclomatic complexity, cognitive complexity focuses more on the readability and understanding cost of the code, and is closer to the actual experience of developers. Third, size complexity considers the physical size of the code, such as the number of function lines, the number of parameters, and the number of variables. Fourth, historical defect data is a record of defects that have occurred in the code's history, including defect location, severity, and difficulty of fixing. This embodiment extracts this data from defect tracking systems (such as JIRA and Bugzilla) and version control systems to analyze the distribution patterns and trends of defects. Historical defect data is an important basis for predicting future defect risks, based on the empirical observation that defects tend to cluster.

[0133] In this embodiment, code weaknesses are located through multi-angle analysis: First, Defect Density Analysis calculates the historical defect density (number of defects found per unit line of code or function) for each code region, identifying the areas with the highest historical concentration of defects. Spatial statistical methods, such as HotSpot Analysis or Kernel Density Estimation, are used to mark areas with high defect density on the code map. These areas typically represent weak points in code quality and require more testing attention. Second, Change Frequency Analysis examines the code's modification history to identify areas with frequent changes. Frequently changed code is often unstable, and each change may introduce new defects. This embodiment extracts commit records from the version control system, calculates the change frequency of each file, function, or code block, and compares it with the average change rate of the entire codebase to identify change hotspots. Third, Complexity Risk Analysis combines code complexity with the distribution of surviving variants to identify areas that are both complex and under-tested. This embodiment categorizes code by complexity and then analyzes the proportion of surviving variants at each complexity level, paying particular attention to regions with high complexity but also high proportions of surviving variants. These regions represent points where high complexity and insufficient testing risks overlap. Next, Change Impact Analysis assesses the scope and potential risks of code modifications. This embodiment constructs a code dependency graph to analyze other components that may be affected by modifying one component, considering the historical defect rates and complexities of these components to assess the overall risk of the modification. Code areas surrounding high-risk modification points typically require more rigorous testing. Finally, Cross-Component Interface Analysis examines the interfaces and interaction points between different components or modules. Inter-component interfaces are common sites of defects because they involve complex operations such as data transfer, format conversion, and hypothesis sharing. This embodiment identifies all inter-component interfaces, analyzes the clarity of their interface contracts (such as parameter types and return value specifications) and test coverage, and marks insufficiently tested interface points. Therefore, this embodiment generates a code vulnerability report through the above analysis, identifying high-risk code areas and their specific risk factors (such as high complexity, high defect history, frequent changes, etc.), providing guidance for the optimized allocation of test resources, and enabling the concentration of limited test resources in the areas that require the most attention.

[0134] Furthermore, to make the analysis results more intuitive and easier to understand, mutation test metrics, test blind spots, and code weaknesses are transformed into mutation score trend charts, mutant state distribution charts, and test coverage heatmaps for visualization. A mutation score trend chart is a time series chart that shows the trend of mutation scores over time or version. The horizontal axis of the chart represents a time point or version number, and the vertical axis represents the mutation score (percentage). The trend line visually illustrates the evolution of test quality, helping the team understand the effect of test strategy adjustments and the overall trend of project quality. This embodiment typically adds several enhancements to the chart: Key event marking: Marking important project milestones, test strategy adjustment points, or major code refactoring points on the chart helps understand the impact of these events on test quality. Multi-metric comparison: Displaying trend lines for multiple related metrics on the same chart, such as mutation score, code coverage, and defect discovery rate, facilitates analysis of the correlation and differences between these metrics. Target lines and warning lines: Adding horizontal lines representing target values ​​(such as the mutation score required by the project quality target) and warning lines (such as the minimum acceptable mutation score), visually showing the gap between the current state and the target. Predicting Trends: Based on historical data, time series forecasting methods (such as moving averages and ARIMA models) are used to predict future mutation score trends, helping teams plan and adjust testing strategies in advance. A Mutant Status Distribution Chart is a chart that displays the distribution of mutant statuses from multiple dimensions. Common formats include pie charts, stacked bar charts, or tree diagrams. These charts display the distribution of mutant statuses (killed, alive, timed out, etc.) according to different dimensions (such as mutation type, code module, developer, etc.), helping to identify imbalances in test performance.

[0135] Optionally, this embodiment provides multiple grouping views: Grouping by mutation type: Displaying the state distribution of different types of mutations (such as conditional mutations, operator mutations, etc.) to help identify which type of defect test coverage is insufficient; Grouping by code module: Displaying the mutation state distribution of different functional modules or components to help locate weakly tested modules; Grouping by developer: Displaying the mutation state distribution of code areas responsible for different developers to help identify team members who may require additional test training or support; Grouping by code complexity: Displaying the mutation state distribution of code at different complexity levels to verify whether the tests have appropriately focused on high-complexity code; A test coverage heatmap is a chart that visualizes test coverage as color intensity, usually directly mapped to the code structure or project component diagram. The heatmap uses a color gradient (such as red-yellow-green) to represent the degree of test coverage, with red indicating insufficient coverage and green indicating sufficient coverage.

[0136] Optionally, this embodiment provides multi-level heatmap views: a code-level heatmap, which directly uses background color to mark the test coverage and variant status of each line of code in the code file view, directly indicating which lines of code are undertested; a component-level heatmap, which uses color to mark the test coverage of each component on the project architecture diagram or component dependency diagram, helping to understand the test distribution from a macro perspective; a risk heatmap, which combines code complexity, change frequency, and historical defect data to generate a comprehensive risk heatmap, with colors representing the overall risk level of code areas, guiding the allocation of test resources; and a time-dimensional heatmap, which adds a time dimension to show the changes in test coverage over time, helping to identify areas of test degradation (reduced test coverage). Since these visualizations are not isolated, this embodiment typically provides interactive functionality, allowing users to switch between different views, drill down into data details, filter specific conditions, or adjust display parameters. For example, users can click on a high-risk area in the heatmap to view detailed code and surviving variant information for that area; or select a specific time period to compare the changes in mutation scores across different versions.

[0137] Furthermore, based on the mutation score trend map, variant state distribution map, and test coverage heatmap, a comprehensive visual analysis report is generated, providing the testing team with clear suggestions for optimizing test strategies. The Visual Analysis Report is a structured document that integrates test results data, analytical findings, and optimization recommendations, providing the team with a comprehensive view of test quality and clear action directions. The report not only displays raw data and visualizations, but more importantly, it provides the underlying insights and actionable recommendations.

[0138] In this embodiment, the generated visual analysis report typically includes the following core components: 1. Test Case Enhancement Direction: This provides specific improvement suggestions for areas where the current test suite is lacking. Based on live variant analysis and test blind spot identification, this embodiment provides clear directions for test enhancement, including: a list of code regions requiring enhanced testing, prioritized and accompanied by code location, functional description, and current test status. 2. Suggested test scenarios and input values, especially for boundary conditions, special values, and uncovered condition combinations. 3. Optimization suggestions for existing test cases, such as modifying assertion conditions to make them more stringent, adding verification points, or merging redundant tests. 4. Test technology suggestions, such as adopting more suitable testing methods for specific problems (e.g., attribute-based testing, fuzz testing, etc.). 5. High-Value Testing Areas: This helps the team identify the code regions where testing resources should be invested most. Considering factors such as code complexity, change frequency, historical defect density, and business importance, the most valuable testing areas are identified: a risk scoring matrix displays the scores of different code regions on multiple risk factors and calculates a comprehensive risk score. 6. Return on Investment (ROI) Analysis: Estimate the costs (e.g., test writing difficulty) and expected benefits (e.g., number of defects potentially discovered) of increasing testing in different regions, and calculate the ROI of testing. 7. Critical Path Analysis: Identify the code paths most critical to system stability and functional correctness, and assess their current testing status. 8. Risk Comparison between New Features and Legacy Code: Help balance the allocation of testing resources for newly developed features and legacy code. 9. Automated Testing Coverage Recommendations: Provide specific guidance for improving the degree and efficiency of test automation. Analyze the current coverage of manual and automated tests, identify suitable test scenarios for automation: An automation priority list lists the most suitable test scenarios for automation, considering factors such as execution frequency, stability requirements, and automation difficulty. 10. Automated Testing Framework Recommendations: Recommend suitable automated testing tools and frameworks based on project characteristics and testing needs. 11. Continuous Integration Strategy Recommendations: Propose how to integrate mutation testing into the continuous integration / continuous deployment (CI / CD) process, including triggering conditions, execution frequency, and result processing methods. 11. Test automation ROI analysis: Calculate the long-term cost-benefit of investing in test automation to help the team make reasonable resource allocation decisions.

[0139] Optionally, in addition to text content, the report also includes interactive visualizations, allowing users to explore data details, adjust view parameters, or drill down into specific areas. This interactive reporting provides a multi-layered view of the data, meeting the diverse needs of different roles, such as test managers, developers, and quality analysts. This embodiment, through systematic results analysis and visual reporting, transforms variation testing from a mere testing technique into a comprehensive quality improvement tool. It not only evaluates the effectiveness of testing but also provides data-driven guidance for optimizing test strategies, effectively improving quality.

[0140] In one specific embodiment, the method further includes generating the mutant to be processed through the following steps:

[0141] The mutation testing process is modeled as a Markov decision process, and a mutation testing MDP model is constructed based on the Markov decision process. The mutation testing MDP model includes a state space, an action space, and a reward function. The state space includes code complexity, coverage, and historical defect density. The action space includes condition inversion and boundary value modification. The reward function is used to indicate the probability that the mutant is killed by the test case.

[0142] The state-action value function in the mutation test MDP model is represented by a preset rational function, and the Q value is expressed as a polynomial ratio to establish the value function representation.

[0143] The value function representation is iteratively optimized using a preset symbolic computation algorithm;

[0144] Based on the value function representation after iterative optimization, the long-term value of multiple mutation strategies used for mutation testing is compared, the behavior of the mutation strategy when the discount factor approaches the preset parameter is solved, and the corresponding mutation strategy is determined based on the comparison results and the solved behavior.

[0145] Based on the determined mutation strategy, the rational function value of each potential mutation point is calculated, and a mutation point priority queue is established based on the rational function value. The mutation point priority queue generates a mutant to be processed containing priority ranking information.

[0146] In this embodiment, by modeling the mutation testing process as a Markov Decision Process (MDP) and applying rational function approximation and symbolic computation techniques, intelligent prioritization of mutation points and automatic generation of high-value mutants are achieved, significantly improving the efficiency and effectiveness of mutation testing. Specifically, firstly, the mutation testing process is modeled as a Markov Decision Process, and a mutation testing MDP model is constructed based on this process, including a state space, action space, and reward function. A Markov Decision Process (MDP) is a mathematical framework used to model sequential decision problems, where the outcome is partly random and partly controlled by the decision-maker. MDP provides a mathematical way to describe and solve uncertainties in decision-making environments. In mutation testing, the MDP model can accurately capture the long-term impact and uncertainty of mutation decisions, facilitating the selection of optimal mutation strategies.

[0147] For example, in the mutation testing MDP model, these elements are concretized as quantities related to code analysis and testing effectiveness: First, the State Space defines all possible states. In mutation testing, states reflect the characteristics of the code and the testing environment. In this embodiment, the State Space mainly contains three types of key information: Code Complexity quantifies the structural complexity of the code, including loop complexity (measuring the number of decision points in the code), nesting depth (the nesting level of conditions and loops), and function size (number of lines of code, number of parameters, etc.). High-complexity code usually has more execution paths and boundary cases, making it a high-risk area for defects and an important target for mutation testing. Static code analysis tools are used to calculate the code complexity metrics and standardize them into a dimension of the State Space. Second, Coverage Status describes the degree to which existing test cases cover the code, including statement coverage (the proportion of lines of code executed), branch coverage (the proportion of branches of code executed), and path coverage (the proportion of paths of code executed). Coverage status reflects whether the code has been adequately tested, and low-coverage areas are usually a priority target for mutation testing. Coverage information is obtained by executing test cases and analyzing code instrumentation data, and then incorporated into the state representation. Third, historical defect density reflects the frequency and severity of defects in a code region throughout history, including the number of defects (the number of defects found per unit of code), defect severity (the average severity of defects), and repair cost (the average amount of work required to repair defects). Historical defect density is an important indicator for predicting the likelihood of future defects; regions with high defect density typically require more rigorous testing. Historical data is extracted from version control systems and defect tracking systems to calculate the defect density index for each code region. Therefore, the state space, coverage, and historical defect density together constitute a multi-dimensional state space, in which each code location has a corresponding state vector. This embodiment discretizes the continuous state space into a finite set of states to facilitate processing by the MDP algorithm. Discretization methods include equal-width binning (dividing a continuous value range into a fixed number of intervals), equal-frequency binning (ensuring each interval contains approximately the same number of samples), or cluster-based adaptive binning (automatically determining bin boundaries based on data distribution characteristics).

[0148] The Action Space defines all possible operations that can be performed in each state. In mutation testing, actions correspond to different types of code mutations. In this embodiment, the Action Space contains two main mutation types: 1. Condition Inversion: This is a mutation operation that changes the logic of conditional judgments in the code, including logical negation (changing conditional expression A to !A), logical operator substitution (replacing AND with OR, and OR with AND), and relational operator inversion (replacing > with <=, and == with !=, etc.). Condition inversion mutation can test the correctness of code behavior under different conditional branches and is an effective means of detecting logical errors. 2. Boundary Value Modification: This is a mutation operation that adjusts boundary judgments in the code, including boundary offset (adding or subtracting boundary values ​​by 1), boundary expansion (changing strict inequalities to non-strict inequalities, such as changing < to <=), and boundary contraction (changing non-strict inequalities to strict inequalities, such as changing <= to <). Boundary value modification mutation can test the correctness of code in handling boundary conditions and help to discover common defects such as out-of-bounds access and boundary calculation errors.

[0149] In this embodiment, the syntactic structure and semantic features of each code location are analyzed to determine the set of applicable mutation operations. Different code structures can be applied to different mutation operations; for example, conditional statements can be subjected to condition inversion mutation, and loop boundaries can be subjected to boundary value modification mutation. The action space is designed to consider both the effectiveness (capable of generating syntactically correct variants) and diversity (capable of simulating different types of defects).

[0150] It should be noted that the reward function defines the immediate feedback obtained after performing an action. In mutation testing, the reward is directly related to the test performance of the mutant. In this embodiment, the reward function is used to indicate the probability that the mutant will be killed by the test case, i.e., the mutant's ability to expose test deficiencies. The reward calculation is based on the following principle: if the mutant is killed by the test case (i.e., the test can detect the error introduced by the mutation), a lower reward is obtained; if the mutant survives (the test fails to detect the mutation), a higher reward is obtained. This design encourages this embodiment to generate mutants that can expose the weaknesses of the test suite, rather than mutants that are easily killed. Specifically, this embodiment uses historical mutation data and a machine learning model to predict the probability that the mutant will be killed. The prediction model considers factors such as code features (complexity, structure, etc.), mutation type, and test coverage, and is trained using supervised learning methods (such as logistic regression, random forest, or neural networks). For example, the reward function can be designed as the inverse function of the kill probability, such as R = 1 - P(killed), where P(killed) is the predicted probability that the mutant will be killed. Therefore, this embodiment uses MDP modeling to transform the mutation testing problem into a sequence decision problem. That is, at each potential mutation point in the code, it is necessary to decide which mutation operation to apply (or not to mutate) to maximize the long-term cumulative reward (i.e., generate the most valuable set of mutants).

[0151] Furthermore, after constructing the MDP model, a pre-defined rational function is used to represent the state-action value function in the mutation testing MDP model, and the Q-value is expressed as a polynomial ratio to establish the value function representation. The State-Action Value Function (Q-function) is a core concept in reinforcement learning, used to evaluate the long-term value of performing a specific action in a specific state. Specifically, in mutation testing, the Q-function represents the long-term test value of applying a specific mutation operation (action) at a specific code location (state). A high Q-value indicates that the mutation operation may produce high-value mutants, helping to expose test deficiencies and improve test quality. In this embodiment, a rational function is used to represent the Q-function, balancing expressive power and computational efficiency.

[0152] The rational function is the ratio of two polynomials. In mutation tests, the rational function represents the ability to capture the complex nonlinear relationship between state and action value, especially the asymptotic behavior when the discount factor is close to 1.

[0153] In this embodiment, the Q-function is represented as a polynomial ratio. The specific form of the polynomial is designed according to the characteristics of the problem. Common choices include: 1. Feature-based polynomials, where the features are extracted from the state and action (such as code complexity, coverage, etc.). 2. Tensor product polynomials: using all possible product combinations between the components of the state and action vectors as polynomial terms. 3. Orthogonal polynomials: using orthogonal basis function expansions such as Chebyshev polynomials or Legendre polynomials to improve numerical stability. Therefore, this embodiment uses rational function representation, which has strong expressive power, i.e., it can accurately approximate complex nonlinear Q-functions, especially functions with singularities and asymptotic behavior. It improves generalization, i.e., by selecting appropriate polynomial basis functions, rational functions can provide reasonable value estimates for unseen state-action pairs. It improves computational efficiency, i.e., compared to complex models such as neural networks, the computation and optimization of rational functions are more efficient, especially suitable for online decision-making scenarios requiring rapid evaluation. It also has strong interpretability, i.e., the structure of rational functions is relatively simple, allowing for analysis of their mathematical properties, providing theoretical guarantees, and enhancing the interpretability of the decision. To construct a rational function representation, this embodiment first defines feature extraction functions for states and actions, mapping the original states and actions to a feature space. The feature design considers domain knowledge of mutation testing, including code structure features (such as conditional complexity and loop nesting depth), test coverage features (such as statement coverage and branch coverage), and historical performance features (such as historical mutant survival rate).

[0154] Then, this embodiment selects appropriate polynomial basis functions to construct expressions for the numerator and denominator polynomials. The selection of basis functions considers factors such as the problem's dimensionality, data distribution, and computational efficiency. Commonly used basis functions include monomial bases, Chebyshev polynomials (used to improve numerical stability), or radial basis functions (suitable for local approximation). Finally, this embodiment initializes the polynomial coefficients to prepare for subsequent iterative optimization. Initialization methods include random initialization, heuristic initialization based on prior knowledge, or initialization using the fitting results of a simple model (such as linear regression). Therefore, through this rational function representation, this embodiment transforms the complex mutation decision problem into an optimization problem of rational function parameters.

[0155] Furthermore, after establishing the value function representation, this embodiment uses a pre-defined symbolic computation algorithm to iteratively optimize the value function representation, improving its accuracy and generalization ability. Symbolic computation algorithms are a class of algorithms that process mathematical expressions and equations. Unlike numerical computation, symbolic computation preserves the precise form of the expression and does not introduce rounding errors. In reinforcement learning, symbolic computation can accurately handle value function iteration, especially when rational functions and limit calculations are involved. In the mutation test MDP optimization, this embodiment uses a symbolic dynamic programming algorithm for value function iteration, which can maintain the accuracy of the calculation and is particularly suitable for analyzing behavior when the discount factor is close to 1.

[0156] Specifically, the symbolic computation iterative optimization steps include: First, initializing the parameters of the rational function representation. The coefficients of the numerator and denominator polynomials can be randomly initialized or set based on prior knowledge; for example, a simple linear regression model can be used to fit historical variation data, and the result can be used as the initial parameters. Then, performing symbolic value iteration. In symbolic computation, this iterative process is transformed into updating the rational function parameters. This embodiment uses a symbolic algebra system (such as Mathematica, SymPy, etc.) to perform polynomial addition, multiplication, integration, and differentiation to update the coefficients of the rational function. In particular, this embodiment performs the following symbolic operations: polynomial expansion, polynomial simplification, rational function decomposition, and symbolic integration. After each iteration, the quality of the current rational function representation is evaluated, and its error compared to the true Q-function (in the case of sample data) or the change between consecutive iterations (in the case of no true labels) is calculated. If the error is below a preset threshold or the iterative change is very small, the iteration is considered to have converged, and the optimization process stops.

[0157] To improve computational efficiency, this embodiment may employ the following optimization techniques: Polynomial order constraint: limiting the highest order of the numerator and denominator polynomials to prevent polynomial complexity explosion; Sparse regularization: encouraging the sparsity of polynomial coefficients, reducing the number of non-zero terms, and simplifying the expression; Piecewise rational functions: using different rational functions to represent different state regions to enhance local fitting accuracy; Parallel symbolic computation: utilizing the parallel processing capabilities of modern computers to process multiple symbolic expressions simultaneously. Through iterative optimization of symbolic computation, this embodiment obtains a high-precision state-action value function representation, capable of accurately evaluating the long-term value of different mutation operations. This representation considers not only immediate rewards (the probability of the mutant being killed by the test case) but also long-term impacts (contribution to the quality assessment of the test suite), providing a reliable basis for subsequent strategy comparison and decision-making.

[0158] Subsequently, after obtaining the optimized value function representation, the long-term value of multiple mutation strategies used for mutation testing is compared based on this representation. The behavior of the mutation strategies when the discount factor approaches a preset parameter is solved, and the corresponding mutation strategy is determined based on the comparison results and the solved behavior. A mutation strategy defines the rules for which mutation operations are applied at various locations in the code. Different mutation strategies generate different sets of variants, affecting the effectiveness and efficiency of the test. In this embodiment, multiple potential mutation strategies are evaluated and compared, and the optimal strategy is selected for actual variant generation.

[0159] In this embodiment, the mutation strategy types considered include: Greedy Strategy: Selects the action with the highest Q-value in each state, i.e., selects the mutation operation with the highest expected long-term value. Greedy strategies aim to maximize test value but may result in a single mutation type and incomplete coverage. ε-Greedy Strategy: Selects the action with the highest Q-value with a probability of 1-ε, and randomly selects an action with a probability of ε. This strategy balances value maximization and exploration diversity, suitable for initial mutation testing. Priority-based Strategy: Sorts mutation operations according to Q-value, but considers diversity constraints to ensure that different types of mutation operations have a chance to be selected. This strategy helps generate a diverse set of mutants. Threshold-based Strategy: Selects only mutation operations with Q-values ​​exceeding a specific threshold, filtering out low-value mutations. This strategy helps control the number of mutants and concentrate resources on testing high-value mutations. Weighted Random Strategy: Sets the selection probability based on Q-value, with mutation operations with higher Q-values ​​having a higher probability of being selected. This strategy maintains randomness while favoring high-value mutations.

[0160] To compare the long-term value of these strategies, this embodiment performs the following steps: First, a symbolic policy evaluation is performed for each strategy. Traditional policy evaluation requires estimating policy value through Monte Carlo simulation or temporal difference learning, methods that typically rely on large numbers of samples and iterations. This embodiment leverages the advantages of symbolic computation to directly solve for the closed-form expression of the value function under the policy. For the deterministic policy π, this embodiment constructs a system of linear equations. By symbolically solving this system of linear equations, this embodiment obtains the closed-form expression of the policy value function without iteration or sampling. Next, the limiting behavior is calculated. In reinforcement learning, the discount factor controls the balance between immediate and future rewards. When the discount factor approaches 1, more emphasis is placed on long-term cumulative rewards. In mutation testing, long-term test value is typically the focus; therefore, it is necessary to analyze the policy behavior when the discount factor approaches 1.

[0161] In this embodiment, symbolic limit calculation is used to analyze the value function expressions of each strategy when the discount factor approaches a preset parameter (usually close to 1), and to select the mutation strategy that best suits the current project characteristics and testing objectives. The selected strategy will guide the subsequent prioritization of mutation points and the mutation generation process.

[0162] Furthermore, after determining the mutation strategy, this embodiment calculates the rational function value of each potential mutation point according to the selected strategy, and establishes a mutation point priority queue based on the rational function value. The mutation point priority queue generates unprocessed mutants containing priority ranking information. A mutation point is a specific location in the code where mutation operations can be applied, usually a specific node in the syntax tree, such as a conditional expression, operator, or constant. The selection of mutation points directly affects the effectiveness of mutation testing; prioritizing testing high-value mutation points can improve testing efficiency. The rational function value is the mutation point value calculated using the rational function representation obtained earlier. For each potential mutation point in the code, this embodiment extracts its state characteristics (complexity, coverage, historical defect density, etc.), combines them with applicable mutation operations, and substitutes them into the rational function expression to calculate its value.

[0163] For example, the calculation process is as follows:

[0164] First, this embodiment performs static analysis on the source code to identify all potential mutation points. The analysis process includes: Syntax analysis: constructing an Abstract Syntax Tree (AST) to identify syntactic structures such as expressions, statements, and blocks. Semantic analysis: determining variable types, scope, and data flow to understand the semantics of the code. Pattern matching: identifying code structures that conform to mutation patterns, such as conditional expressions, arithmetic operations, and boundary checks. Specifically, this embodiment extracts a state feature vector for each potential mutation point, including: Code complexity metrics: calculating the loop complexity, nesting depth, and SLOC (Lines of Source Code) of the function containing the mutation point; Test coverage data: extracting the execution frequency, coverage, and path coverage of the mutation point from the coverage report; Historical defect information: extracting historical defect records, modification frequency, and developer information for the mutation point area from the version control system and defect tracking system.

[0165] Then, this embodiment applies the previously selected mutation strategy to each mutation point, determining the mutation operation to be applied (such as condition inversion or boundary value modification). Depending on the strategy type, this could be a deterministic choice (such as a greedy strategy) or a probabilistic choice (such as a weighted random strategy).

[0166] Next, this embodiment calculates the rational function value of each mutation point-operation pair. This embodiment substitutes the state characteristics of the mutation point and the selected mutation operation into the optimized rational function expression. This calculated rational function value directly reflects the long-term testing value of the mutation point when applying a specific mutation operation. Based on the calculated value, this embodiment establishes a mutation point priority queue, which can efficiently manage the insertion of elements and the extraction of operations according to priority. In this embodiment, the priority queue is used to manage the testing order of mutation points, ensuring that high-value mutation points are tested first.

[0167] For example, the queue construction process includes: initializing an empty queue and setting priority calculation rules (based on rational function values); traversing all mutation point-operation pairs, calculating their priority scores, and inserting them into the queue; applying diversity constraints (such as ensuring balanced representation of different types of mutations) and resource constraints (such as limiting the total number of mutations); and optimizing the queue structure (such as using a Fibonacci heap) to improve the efficiency of subsequent operations.

[0168] Finally, this embodiment generates mutants to be processed from a priority queue. This embodiment extracts mutation point-operation pairs from the queue in priority order and applies mutation operations to generate specific mutant code.

[0169] For example, the mutant generation process includes: code parsing: parsing the original source code into an abstract syntax tree (AST); mutation application: applying mutation operations to specified nodes of the AST, such as mutating "a>b" to "a<= b"; code generation: generating new source code from the mutated AST; mutation tagging: adding metadata to each mutant, recording information such as mutation point, mutation type, priority score, etc.

[0170] Therefore, the variants generated in this embodiment not only contain the mutated code but also rich priority ranking information, such as mutation point value scores, mutation operation types, and expected test results. This is extremely useful in subsequent test execution and result analysis, helping to understand the test value of variants and improve test strategies. By prioritizing based on MDP and rational functions, this embodiment can intelligently select the most valuable mutation points and mutation operations, generating a high-quality variant set. Therefore, by considering the long-term impact of mutation decisions, this embodiment can identify mutation points that are not immediately obvious but have high long-term test value. Rational function representation and symbolic computation methods improve computational efficiency, enabling it to handle the mutation testing needs of large-scale codebases with high computational efficiency. Simultaneously, it can learn patterns from historical mutation data and adjust mutation strategies accordingly, continuously optimizing the mutation testing process as the project progresses and improving adaptability. This significantly improves the efficiency and effectiveness of mutation testing, allowing limited testing resources to be concentrated on the most valuable mutation points, maximizing the return on investment in testing.

[0171] In one specific embodiment, the step of analyzing the code structure and semantic features of the multi-dimensional code features using a preset large language model to identify potential defect types and error patterns includes:

[0172] A smart agent model is constructed, comprising a syntax analysis smart agent for constructing code syntax structure and program, a semantic understanding smart agent for indicating code intent and function, a vulnerability mining smart agent for identifying security vulnerabilities and boundary conditions, a defect pattern smart agent for matching historical defect patterns, and a test generation smart agent for instructing the updating of test cases based on the discovered problems. A neural algorithm inferencer is configured for each smart agent in the smart agent model. The neural algorithm inferencer includes an analysis network and an algorithm knowledge base adapted to a preset code analysis task, built based on a preset Transformer architecture. The algorithm knowledge base includes programming paradigms, design patterns, and error patterns. The neural algorithm inferencer is used to instruct each smart agent to perform algorithm step derivation.

[0173] Based on a standardized message format, a collaborative framework between agents in the agent model is determined. The standardized message format includes code snippets, analysis results, and confidence scores. The analysis results are obtained by the agents after analyzing their execution and / or the code snippets. The collaborative framework includes a knowledge-sharing mechanism and a conflict resolution mechanism based on a graph structure.

[0174] Through the intelligent agent collaboration framework, code analysis tasks are performed based on the multi-dimensional code features. The code analysis tasks are used to instruct the syntax analysis agent to create a syntax understanding graph, the semantic understanding agent to interpret code functions, and the vulnerability discovery agent and the defect pattern agent to identify potential problems in parallel and generate their respective analysis results.

[0175] Based on the analysis results obtained from the code analysis task, a targeted testing strategy is determined through the test-generated agent, so that each agent in the agent model verifies each other's analysis results through the neural algorithm inferencer, forming multi-angle verification of analytical evidence.

[0176] The analytical evidence is integrated using weighted voting, and the confidence scores of each agent are merged using a preset Bayesian inference algorithm. A preset ensemble learning algorithm is then used to aggregate the analytical evidence and the confidence scores from multiple analytical perspectives to generate defect types and error patterns that include multi-agent consensus.

[0177] In this embodiment, a multi-agent collaborative system is constructed to achieve in-depth analysis of code structure and semantic features, effectively identifying potential defect types and error patterns. This overcomes the limitations of traditional static analysis and combines the semantic understanding capabilities of a large language model with specialized domain knowledge to build an intelligent system capable of collaboratively analyzing code from multiple perspectives. Specifically, firstly, an agent model composed of multiple specialized agents is constructed. Each agent is responsible for a specific code analysis task and is equipped with a dedicated neural algorithm inference engine. An agent is a software entity capable of autonomously executing specific tasks and possessing certain decision-making abilities. In this embodiment, the agents are specialized analysis components built based on a large language model. Each agent focuses on a specific aspect of code analysis and has clearly defined responsibilities and professional knowledge.

[0178] For example, this embodiment constructs five core intelligent agents, which together form a complete code analysis system:

[0179] First, the Syntax Analysis Agent focuses on constructing the syntactic structure and program flow representation of the code. This agent is responsible for parsing the source code, building an Abstract Syntax Tree (AST) and a Control Flow Graph (CFG), and identifying structured components of the code such as functions, classes, conditional statements, and loops. Syntax analysis is the foundation for all further code analysis, providing the skeleton structure of the code. Key tasks performed by the Syntax Analysis Agent include: code tokenization (decomposing code text into a sequence of tokens), syntax parsing (constructing an AST according to the programming language's syntax rules), control flow analysis (identifying code execution paths and jump relationships), and structure recognition (identifying high-level structural units such as functions, classes, and methods). This agent not only identifies syntactically correct code structures but also detects syntactic anomalies and potential structural problems, such as mismatched parentheses, missing statement terminators, or unreachable code.

[0180] Second, the Semantic Understanding Agent is responsible for interpreting the intent and function of the code, understanding the business logic and expected behavior of code snippets. Unlike analysis that only focuses on syntax, semantic understanding involves the actual meaning and purpose of the code; for example, understanding whether a function performs a sorting algorithm or data validation. The core tasks performed by the Semantic Understanding Agent include: variable tracking (analyzing the lifecycle, scope, and usage patterns of variables), data flow analysis (tracking how data flows and transforms within the program), function identification (identifying the algorithm or business function implemented by the code snippet), and annotation understanding (understanding the developer's intent by combining code comments). This agent can generate natural language descriptions of the code, explain the working principles of complex algorithms, and identify potential discrepancies between the actual behavior of the code and its expected function.

[0181] Third, the Vulnerability Mining Agent is specifically designed to identify security vulnerabilities and boundary case handling issues in code. Security vulnerabilities refer to weaknesses in code that attackers can exploit, such as buffer overflows, SQL injection, or cross-site scripting attacks. Boundary cases refer to the behavior of a program under extreme or special conditions, such as empty input, maximum values, or unexpectedly formatted data. The Vulnerability Mining Agent possesses in-depth security knowledge, and its main tasks include: vulnerability pattern matching (identifying code patterns with known security vulnerabilities), input validation analysis (checking whether the program adequately validates and sanitizes input), resource management auditing (checking the proper management of resources such as memory allocation and file handles), and boundary test analysis (evaluating the code's ability to handle boundary cases). This agent can not only discover explicit security issues but also identify potential security risks, such as insecure default configurations or outdated encryption algorithms.

[0182] Fourth, the Defect Pattern Agent focuses on identifying code structures that match known historical defect patterns. Software defects often follow certain patterns, and some programming errors recur in different projects. This agent maintains a detailed defect pattern library, containing common programming errors, anti-patterns, and domain-specific pitfalls. The core tasks performed by the Defect Pattern Agent include: pattern matching (comparing code with known defect patterns), context analysis (considering the code's runtime environment and context to understand defect risks), historical similarity analysis (finding code snippets similar to historical defects), and defect risk assessment (assessing the severity and scope of potential defects). The agent's analysis relies on a large amount of historical defect data, learning from past errors through machine learning methods and applying them to new code analysis.

[0183] Fifth, the Test Generation Agent is responsible for guiding the updating and generation of test cases based on the discovered issues. Effective test cases are key tools for verifying code correctness and discovering potential problems. This agent transforms the analysis results of other agents into specific test strategies and test cases. The main tasks performed by the Test Generation Agent include: test requirement analysis (determining test requirements based on discovered issues), test case design (creating test cases that can verify specific functions or expose specific defects), test coverage analysis (evaluating the degree to which test cases cover the code), and test priority ranking (ranking test cases according to risk and importance). This agent can not only generate basic unit tests but also design complex integration tests and boundary tests to ensure comprehensive verification of code functionality and robustness.

[0184] To address this, a Neural Algorithm Reasoner, configured for each agent, serves as the agent's core computing engine, responsible for performing complex code analysis and reasoning tasks. The Neural Algorithm Reasoner combines the pattern recognition capabilities of neural networks with the precise reasoning capabilities of symbolic algorithms, forming a hybrid intelligent system.

[0185] Subsequently, the neural algorithm inference engine comprises two core components: First, the Analysis Network is a neural network model built upon a predefined Transformer architecture, specifically adapted to predefined code analysis tasks. The Analysis Network processes code through the following steps: First, it tokenizes the code, converting it into a sequence of tags; then, through a multi-layered self-attention mechanism, it calculates the relationships and importance weights between tags; next, through a feedforward neural network layer, it processes the output of the attention mechanism to generate rich tag representations; finally, through a specific task layer, it generates corresponding analysis results based on the agent's responsibilities, such as syntactic structure, semantic interpretation, or defect prediction. By configuring the Analysis Network, it can handle variable-length code input, capture dependencies between different syntactic elements, have a good understanding of the local and global structure of the code, and perform accurate reasoning based on context. Second, the Algorithm Knowledge Base is a structured knowledge store containing programming paradigms, design patterns, and error patterns. Unlike pure neural networks, the Algorithm Knowledge Base introduces explicit symbolic knowledge, enhancing interpretability and expertise.

[0186] Furthermore, the workflow of the neural algorithm inference engine is as follows: receiving code input and analysis tasks, initially processing the code through the analysis network, querying the algorithm knowledge base to obtain relevant knowledge, combining the neural network output and knowledge base information to perform comprehensive reasoning, generating specific analysis results and suggestions, and updating the knowledge base and model weights based on feedback. Thus, through this neural-symbolic combined architecture, the neural algorithm inference engine can simultaneously utilize the pattern recognition capabilities of deep learning and the precision of symbolic reasoning to achieve more accurate and interpretable code analysis.

[0187] Furthermore, to enable agents to collaborate effectively, this embodiment establishes a collaborative framework between agents in the agent model based on a standardized message format. The standardized message format in this embodiment includes three core components: Code Snippets are portions of source code involved in communication, which can be complete functions, classes, or specific lines or statements. Code snippets typically contain unique identifiers, location information (such as filenames and line numbers), code text, and contextual information. Standardized code snippets ensure consistent understanding among different agents when discussing the same code. Analysis Results are the agent's findings from analyzing the code snippets, including identified problems, suggested solutions, or functional explanations. Analysis Results typically include the problem type (such as syntax errors, security vulnerabilities, logical flaws, etc.), problem description, severity, possible solutions, and relevant code locations. The standardized analysis results format allows different agents to understand and compare each other's findings. Confidence Score is the agent's level of confidence in its analysis results, typically represented by a value between 0 and 1. Confidence scores reflect an agent's level of confidence in a particular analysis result. High confidence indicates that the agent believes the result is highly likely to be correct, while low confidence indicates that the result has significant uncertainty. Confidence scores are particularly important when integrating the analysis results of multiple agents, as they facilitate determining the weight of differing opinions.

[0188] Secondly, the Agent Collaboration Framework defines the interaction rules, communication patterns, and collaboration mechanisms between agents, serving as the foundation for the operation of multi-agent systems. An effective collaboration framework can promote information sharing, reduce redundant work, and resolve conflicts between agents. The agent collaboration framework in this embodiment includes two core mechanisms: First, a graph-based knowledge sharing mechanism uses graph data structures to organize and share knowledge and analysis results among agents. In this graph structure, nodes represent code elements (such as functions, classes, and variables) or analysis findings (such as potential defects and functional descriptions), and edges represent relationships between elements (such as call relationships and dependency relationships) or connections between analysis findings (such as causal relationships and correlations). The knowledge graph construction process includes: initializing a basic code structure graph (provided by the syntax analysis agent), each agent adding domain-specific nodes and edges to the graph, maintaining the attributes of nodes and edges (such as confidence and timestamps), and providing a graph query interface for agents to retrieve relevant information. Therefore, by constructing a graph structure, it is possible to naturally represent the complex relationships between code and analysis, support seamless switching between local and global views, facilitate agents in locating relevant information, and gradually enrich and improve the structure as the analysis deepens.

[0189] Furthermore, the Conflict Resolution Mechanism handles situations where different agents produce contradictory or inconsistent analysis results. In this embodiment, the conflict resolution process includes the following steps: Conflict Detection: Monitoring the analysis results submitted by agents, and marking potential conflicts when contradictory conclusions are found (e.g., one agent believes the code is safe, while another finds a security vulnerability). Conflict Classification: Classifying conflicts into factual conflicts (different understandings of objective facts), reasoning conflicts (different reasoning paths based on the same facts), or priority conflicts (different assessments of the importance of the problem). Evidence Collection: Requesting relevant agents to provide detailed evidence and reasoning processes to support their conclusions, enriching the contextual information of the conflict. Conflict Arbitration: Resolving conflicts based on evidence strength, agent expertise, and historical accuracy, using methods such as majority voting, evidence weight comparison, or requesting expert agent arbitration. Result Integration: Updating the conflict resolution results to a shared knowledge graph, including the final conclusion and a record of the resolution process, to provide a reference for similar conflicts in the future. Therefore, this embodiment solves the problem of inconsistent analysis by configuring a conflict resolution mechanism, and also improves the overall quality and reliability of the analysis by promoting in-depth discussion and evidence exchange among agents.

[0190] Therefore, the implementation of the agent collaboration framework adopts the design principles of modern distributed systems, including message queues, publish-subscribe patterns, and event-driven architecture. This embodiment maintains a central coordinator responsible for message routing, task allocation, and conflict management to ensure efficient collaboration between agents.

[0191] Furthermore, after establishing the agent model and collaboration framework in this embodiment, code analysis tasks are executed based on multi-dimensional code features through the agent collaboration framework, enabling collaborative work among the agents. Specifically, the code analysis task is a process of systematically reviewing and analyzing source code, with the aim of understanding code functionality, evaluating code quality, and identifying potential problems. In this embodiment, the code analysis task is a structured workflow completed collaboratively by multiple agents, each responsible for specific aspects of analysis. In addition, multi-dimensional code features are multifaceted feature data extracted from the source code to support in-depth code analysis. These features describe the nature and behavior of the code from different perspectives, providing rich analytical basis for the agents. Multidimensional code features typically include: Static structural features: describing the static organization and structure of the code, such as code complexity metrics (loop complexity, nesting depth), inheritance relationships, component dependency graphs, and function call graphs; Dynamic behavioral features: describing the runtime behavior of the code, such as execution paths, memory access patterns, performance analysis data, and exception handling; Historical evolution features: describing the changes in the code over time, such as modification frequency, contributor distribution, historical defect density, and code age; Semantic context features: describing the semantic background of the code, such as business domain terminology, the types of algorithms implemented, the design patterns used, and the programming standards followed.

[0192] In this regard, the execution process of code analysis tasks unfolds according to a specific workflow:

[0193] First, the parsing agent creates a Syntax Understanding Graph. A Syntax Understanding Graph is a graphical representation of code structure, capturing the syntactic relationships and dependencies between code elements. Unlike a simple abstract syntax tree, a Syntax Understanding Graph also includes cross-file references, type information, and symbol resolution results, providing a more complete view of the code structure. The parsing agent creates the Syntax Understanding Graph through the following steps: code parsing (parsing the source code into an AST), symbol table construction (identifying and associating all code symbols), type resolution (determining the types of variables and expressions), reference analysis (identifying the definitions and usage locations of symbols), control flow analysis (constructing a control flow graph), preliminary data flow analysis (identifying the definitions and usage of data), and graph structure generation (integrating all analysis results into a unified graph structure). Nodes in the Syntax Understanding Graph represent code elements (such as functions, classes, and variables), and edges represent relationships between elements (such as calls, inheritance, and inclusion). Each node and edge comes with rich attribute information, such as position, type, and access modifiers. This graph structure becomes the foundational framework for all subsequent analyses.

[0194] Next, the semantic understanding agent interprets the code's functionality. Building upon the syntactic structure, the semantic understanding agent is responsible for understanding the code's actual meaning and purpose. This step involves deep semantic analysis, going beyond pure syntactic parsing, and requires understanding the code's intent and business logic. Specifically, the tasks performed by the semantic understanding agent include: function intent analysis (understanding the function's purpose and expected behavior), variable role identification (determining the role of variables in the program, such as counters, flags, accumulators, etc.), in-depth data flow analysis (tracking how data is transformed and processed in the program), algorithm identification (identifying the type of algorithm implemented in the code), business rule extraction (identifying implicit business rules and constraints from the code), and natural language description generation (converting the code's functionality into a clear natural language description). Thus, the results of semantic understanding are added to the shared knowledge graph, adding semantic annotations and explanations to code elements. This is crucial for understanding the code's correctness and identifying potential defects, as many defects stem from a mismatch between the code's implementation and its intended functionality.

[0195] Simultaneously, the vulnerability discovery agent and the defect pattern agent identify potential problems in parallel, generating their respective analysis results. Parallel analysis improves system efficiency and provides problem detection from different perspectives. Specifically, the vulnerability discovery agent focuses on security issues and boundary conditions, performing the following analyses: security vulnerability pattern matching (detecting known security vulnerability patterns), input validation analysis (checking the validation and sanitization of external inputs), security API usage auditing (evaluating the correct use of security-related APIs), resource management checks (verifying the proper allocation and release of resources), anomaly path analysis (checking the handling of anomalies), and boundary condition testing (evaluating the behavior of code under extreme conditions). The defect pattern agent focuses on common programming errors and quality issues, performing the following analyses: known defect pattern matching (comparing with patterns in the defect database), code smell detection (identifying bad practices in the code), logical error reasoning (inferring possible logical defects), performance problem analysis (identifying code patterns that may lead to performance degradation), and maintainability problem evaluation (detecting problems affecting code maintainability). Therefore, the two agents work in parallel, each generating analysis results and confidence scores, with results including detailed information such as problem type, location, severity, potential impact, and remediation recommendations. Parallel analysis not only improves efficiency, but also ensures that the code is thoroughly examined from different professional perspectives, avoiding omissions that may be caused by a single perspective.

[0196] Following the code analysis task, based on the analysis results obtained, a test-generating agent determines targeted testing strategies. Each agent in the agent model then verifies each other's analysis results through a neural algorithm inference engine, forming multi-faceted analytical evidence and improving testing efficiency and relevance. Specifically, the process by which the test-generating agent determines targeted testing strategies based on the analysis results of other agents includes: Problem classification and prioritization: Classifying discovered problems by type (e.g., functional defects, security vulnerabilities, performance issues) and severity to determine test priorities. Test objective definition: Clearly defining the specific problems or functions that each test needs to verify and setting clear test success criteria. Test method selection: Selecting appropriate testing methods based on the nature of the problem, such as unit testing, integration testing, fuzz testing, performance testing, or security penetration testing. Test case design: Designing specific test cases that can trigger the target problem, including input data, execution conditions, and expected results. Test environment configuration: Determining the required environment configuration for testing, such as hardware requirements, software dependencies, network settings, or database status. The test-generating agent not only generates test plans but also automatically generates executable test code. For common testing frameworks (such as JUnit, pytest, Mocha, etc.), the agent can generate test cases that conform to the framework specifications, including test methods, assertion statements, and necessary environment setup code. Multi-perspective validation is a cross-validation mechanism that improves the reliability and accuracy of results by allowing different agents to validate each other's analysis results from their respective professional perspectives. A single agent may draw erroneous conclusions due to limitations in expertise or analytical bias, while multi-perspective validation reduces this risk through collective wisdom. Analysis evidence is the specific facts and reasoning processes that support a particular analysis result or conclusion. In code analysis, evidence may include code snippets, execution paths, data flow analysis results, historical defect records, or relevant knowledge base references. High-quality analysis evidence enhances the credibility and interpretability of conclusions.

[0197] For example, the implementation process of multi-angle verification includes: Cross-review assignment: The system assigns the analysis results of each agent to other relevant agents for review. For example, a semantic understanding agent may review the findings of a defect pattern agent and assess their consistency with the code semantics. Independent verification: Each reviewing agent independently evaluates the analysis results and provides verification opinions and confidence scores based on its own expertise. Evidence provision: Reviewing agents provide specific evidence and reasoning processes for their verification opinions, enhancing the reliability and transparency of the verification. Consistency assessment: The system assesses the consistency of the verification opinions of different agents. Highly consistent results are generally more reliable, while discrepancies may require further investigation. Therefore, through multi-angle verification, not only is the existence of the problem verified, but its severity, scope of impact, and remediation priority are also assessed, ensuring that the finally reported problem is fully reviewed and confirmed, reducing false positives and false negatives.

[0198] In this embodiment, analytical evidence is generated and verified through the neural algorithm inference engines of each agent. The inference engine not only provides conclusions but also records in detail the reasoning steps and their basis, making the analysis process traceable and verifiable. Typical analytical evidence includes: Code evidence: directly referenced code snippets, AST structures, or control flow paths, showing the specific code location and context of the problem. Pattern evidence: matching with known defect patterns or best practices, including pattern descriptions, matching degrees, and historical reference cases. Logical evidence: reasoning steps based on program logic, explaining why a specific code structure leads to the expected problem. Experimental evidence: results obtained through testing or simulation execution, verifying the reproducibility of the problem under specific conditions. Domain knowledge evidence: professional judgment based on programming language characteristics, framework behavior, or business domain knowledge, explaining the root cause and impact of the problem. Therefore, analytical evidence verified from multiple perspectives forms the basis of the final conclusion, ensuring the depth, breadth, and reliability of the analysis.

[0199] Therefore, this embodiment uses weighted voting to integrate analytical evidence, applies a pre-defined Bayesian inference algorithm to merge the confidence scores of each agent, and uses a pre-defined ensemble learning algorithm to aggregate analytical evidence and confidence scores from multiple analytical perspectives, generating defect types and error patterns that incorporate multi-agent consensus. Weighted voting is a decision-making method that considers the weight or importance of different participants. In a multi-agent system, weighted voting assigns different weights to the votes of agents based on their domain of expertise, historical accuracy, or confidence level, ensuring that the final result reflects the distribution of expertise.

[0200] Specifically, the weighted voting process in this embodiment includes: Weight allocation: Assigning a basic weight to each agent to reflect its expertise in a specific analysis type. For example, in security vulnerability analysis, a vulnerability mining agent may receive a higher weight; in semantic understanding, a semantic understanding agent has a higher weight. Weight adjustment: Dynamically adjusting the weights based on the agent's historical accuracy, the confidence level of the current analysis, and the quality of the evidence provided. Agents that perform well and provide high-quality evidence receive a weight increase. Weighted voting: For each potential issue, calculating the weighted sum of supporting and opposing opinions to determine the final judgment. The system may use a simple majority decision (support weight exceeds opposition weight) or set a higher threshold (e.g., support weight must reach 2 / 3 of the total weight). Result ranking: Ranking the finally confirmed issues according to support weights and issue severity to determine priority. Therefore, weighted voting is used to determine the existence of issues, as well as the issue type, severity, and remediation priority, ensuring that the final report reflects the collective judgment of all agents.

[0201] In multi-agent analysis, Bayesian inference is used to merge the confidence scores of different agents, considering prior probabilities, likelihood, and new evidence to generate more accurate posterior probability estimates. In this embodiment, the process of applying Bayesian inference includes: Prior probability definition: Based on historical data or domain knowledge, prior probabilities are defined for different types of problems. For example, the historical probability that a specific code pattern leads to a defect. Agent reliability model: A reliability model is established for each agent on different problem types, including the true positive rate (correctly identifying existing problems) and the false positive rate (incorrectly identifying non-existent problems). Likelihood calculation: Based on the agent's analysis results and confidence, the likelihood of observing current evidence is calculated. Posterior probability update: Applying Bayes' theorem, combining prior probabilities, likelihood, and agent reliability, the posterior probability of the problem's existence is calculated. Uncertainty quantification: In addition to the posterior probability, the variance or confidence interval of the probability distribution is calculated to quantify the uncertainty of the conclusion. Therefore, Bayesian inference can naturally handle uncertainty and conflicting evidence, generating probabilistic conclusions rather than simple binary judgments. It is particularly suitable for the "grey area" problems often encountered in code analysis, namely situations that cannot be simply judged as absolutely correct or incorrect.

[0202] Furthermore, ensemble learning algorithms are machine learning methods that combine the predictions of multiple learners to achieve better performance. The ensemble learning methods used in this embodiment include: Bagging (Bootstrap Aggregating): Generating multiple subsamples from the original data, training multiple similar analysis models, and merging the results through voting or averaging. This method reduces the risk of overfitting and improves the stability of the results. Boosting: Sequentially training a series of weak analyzers, with each new analyzer focusing on samples where the previous analyzer performed poorly. This method particularly focuses on code snippets that are difficult to analyze, improving overall accuracy. Stacking: Training a meta-learner to combine the predictions of different agents. The meta-learner learns the performance patterns of each agent under different conditions and intelligently selects the most reliable result.

[0203] In this embodiment, multiple analytical perspectives are aggregated to analyze evidence and confidence scores. Specific steps include: Feature extraction: Extracting structured features from the analysis results of each agent, including problem type, location, severity, confidence level, and supporting evidence. Cluster analysis: Clustering similar or related problems to identify problem groups that may share common root causes. Association rule mining: Discovering association patterns between problems, such as one type of problem frequently co-occurring with another. Hierarchical classification: Constructing a hierarchical classification of problems, from specific symptoms to root causes, to help understand the causal relationships of the problems. Comprehensive scoring: Combining the scores and evidence from all agents, calculating a comprehensive severity and confidence score for each problem. Therefore, through ensemble learning and data mining, deeper insights can be extracted from the raw analysis results, identifying problem patterns and root causes, rather than just an isolated list of problems.

[0204] Ultimately, this embodiment generates defect types and error patterns incorporating multi-agent consensus. This comprehensive analysis report not only lists specific problems but also provides higher-level insights and pattern recognition, helping development teams understand systemic issues and improvement directions in the code. Specifically, the defect types and error patterns identified through multi-agent consensus include: Specific Defect Instances: A detailed description of each discovered defect, including its location, type, severity, evidence, and remediation recommendations. Error Pattern Analysis: Identifying recurring error patterns in the code, such as specific types of logical errors, improper resource management, or inadequate exception handling. Root Cause Analysis: Tracing the root causes of defects, such as design flaws, knowledge gaps, or process issues. Correlation and Impact Analysis: Assessing the correlation and potential impact range between different defects, identifying possible cascading effects or systemic risks. Improvement Recommendations: Providing specific improvement recommendations based on the discovered problems, including code modifications, architectural adjustments, or process optimizations. Therefore, the analysis results through multi-agent consensus integrate insights from different professional perspectives, undergo rigorous cross-validation and evidence support, and possess high reliability and practical value. It not only helps development teams fix current problems but also provides guidance for preventing similar problems in the future, promoting continuous improvement in code quality.

[0205] Therefore, this embodiment, through comprehensive analysis based on a multi-agent large language model, can deeply understand the structure and semantics of the code, identify potential problems from multiple professional perspectives, and generate high-quality analysis results through a rigorous verification and integration process. It overcomes the limitations of traditional static analysis, combines the semantic understanding capabilities of artificial intelligence with the professional knowledge of domain experts, and provides strong support for code quality assurance.

[0206] In one specific embodiment, the iterative generation of new test cases based on the current surviving variants and the visualization analysis report, and the testing of the current surviving variants using the new test cases, includes:

[0207] A test execution path graph is constructed based on the code execution path of each effective mutant. An execution probability is assigned to each edge in the test execution path graph, and the graph node where the mutation point is located is marked. The graph node in the test execution path graph represents the code state, and the edge in the test execution path graph represents the execution transition.

[0208] A set of multiple constraints, including resource constraints, coverage constraints, dependency constraints, value constraints, and state constraints, is identified. A recursive scaling function and a constraint optimization model are constructed to reduce the problem size. The constraint optimization model is used to indicate how to transform the multi-constraint problem into a weighted single-objective optimization problem.

[0209] The set of multiple constraints is processed using a pre-defined Lagrange multiplier algorithm to determine constraint priorities. A pre-defined randomization algorithm is used to handle uncertainties in the test execution path graph to generate a solution space of probability distribution. A heuristic pruning strategy is constructed, and a scaling algorithm is executed based on the heuristic pruning strategy, the recursive scaling function, the constraint optimization model, the set of multiple constraints, the constraint priorities, and the solution space to obtain a constraint random path.

[0210] Based on the bundled random paths, a test path satisfying the set of multiple constraints is calculated for each surviving mutant. A shared test path that can be shared by multiple surviving mutants is identified. A test execution sequence is generated from the test paths and the shared test paths. The test execution sequence is used to indicate the order in which test cases are executed.

[0211] Based on the test execution sequence, high-value paths not covered by the current test cases are analyzed. Input conditions that trigger specific paths are calculated using a preset symbolic execution algorithm. Test input data that satisfies multiple constraints is generated from the input conditions. Boundary values ​​are designed based on the mutation points of the surviving mutants and the abnormal situations indicated in the visualization analysis report. A mapping relationship between the current test cases and the surviving mutants is established so that new test cases can be generated based on the high-value paths, the test input data, and the mapping relationship.

[0212] In this embodiment, the test suite is continuously improved through an iterative optimization process. First, an accurate test execution path model is constructed. Then, efficient test paths are generated through multi-constraint optimization. Finally, targeted test data is designed to kill surviving variants. This effectively expands the test coverage, specifically exposes potential defects in the code, and significantly improves test efficiency and quality.

[0213] Specifically, this embodiment constructs a test execution path graph based on the code execution path of each valid mutant, assigns an execution probability to each edge in the path graph, and marks the graph nodes where mutation points are located, establishing an accurate model of code execution behavior and laying the foundation for subsequent path analysis and test generation. The test execution path graph represents the possible state transitions and control flow during program execution. It not only includes static code structure information but also incorporates dynamic execution data, such as execution frequency and probability distribution, more accurately reflecting the actual running behavior of the program. In the test execution path graph, graph nodes represent code states, representing state points during program execution. Code states typically correspond to the state when the program reaches a specific location, including the currently executing code position, variable values, and environmental conditions. Graph nodes can correspond to different granular units in the code, such as a single statement, a basic block (a continuously executed code segment without branches), or function entry / exit points. Graph edges represent execution transitions, representing the execution path from one state to another. Edges typically correspond to control flow transitions in code, such as conditional branches, loop iterations, or function calls. Each edge comes with additional attribute information, the most important of which is the execution probability, representing the likelihood that the transition will be triggered during actual program execution.

[0214] The process of constructing the test execution path graph includes the following key steps: First, an initial control flow graph (CFG) is built through static code analysis. The control flow graph is a static representation of the program's control flow, where nodes correspond to basic blocks and edges correspond to control flow transitions. The system parses the source code, identifies control structures such as functions, branches, and loops, and constructs a complete cross-function control flow graph, including function call relationships and exception handling paths. Next, execution frequency information is collected using code instrumentation and dynamic execution data. Code instrumentation is a technique that inserts monitoring code into the original code to collect behavioral data during program runtime. Counter code is inserted at key points in the control flow (such as branch conditions and loop entries), existing test cases are run, and the execution count of each control flow edge is recorded. Based on the collected execution frequency data, the system calculates the execution probability of each edge: the execution probability of an edge equals the number of times that edge is executed divided by the sum of the execution counts of all outgoing edges from the starting node. Finally, mutation points are precisely marked. Mutation points are specific locations in the source code where mutation operations are applied, corresponding to specific statements or expressions in the program. By analyzing the mutation operations of each mutant, the exact location of the mutation point in the source code is determined. Then, the mutation point is mapped to the corresponding node in the test execution path graph, ensuring that the system can clearly identify the critical code locations that need to be tested. Therefore, by constructing a test execution path graph that includes the static structure of the code and integrates dynamic execution characteristics and mutation point information, a comprehensive and accurate program behavior model is provided for subsequent constraint solving and test generation. The enhanced path graph helps the system identify the triggering conditions of mutation points and design test cases that can efficiently kill mutants.

[0215] Subsequently, after constructing the test execution path graph, a set of multiple constraints, including resource constraints, coverage constraints, dependency constraints, value constraints, and state constraints, is identified. A recursive scaling function and a constraint optimization model are then constructed to reduce the problem size. This model transforms the multi-constraint problem into a weighted single-objective optimization problem. The multiple constraint set refers to the various restrictions that must be satisfied simultaneously during test generation. These constraints stem from different considerations and collectively define the characteristics of effective test cases. In real-world testing environments, test generation not only needs to consider technical feasibility but also needs to balance resource efficiency and test value; therefore, a comprehensive constraint framework is required.

[0216] Furthermore, after establishing the constraint model, a pre-defined Lagrange multiplier algorithm is used to process the set of multiple constraints, determine constraint priorities, and a pre-defined randomization algorithm is used to handle uncertainties in the test execution path graph, generating a solution space of probability distributions. A heuristic pruning strategy is then constructed, and a scaling algorithm is executed based on these components to obtain the constrained random path. In test generation, the Lagrange method helps the system optimize test value or coverage while satisfying multiple constraints.

[0217] In this embodiment, the method for determining constraint priorities includes: Prioritization based on business value: Constraints related to core business functions and high-risk areas receive higher priority. For example, constraints ensuring coverage of the core payment processing path have higher priority than constraints ensuring log function coverage. Prioritization based on security: Security-related constraints typically have the highest priority because security issues can lead to the most severe consequences. For example, constraints ensuring full testing of encryption modules take precedence over performance testing constraints. Prioritization based on resource efficiency: In resource-constrained environments, resource constraints may receive higher priority to ensure testing can be completed within available resources. Prioritization based on historical defects: Constraints related to areas where problems have historically occurred receive higher priority, reflecting the empirical pattern of "defect clustering." Adaptive priority adjustment: Based on previous test results and newly discovered information, constraint priorities are dynamically adjusted to adapt the testing strategy to changing needs. Furthermore, numerical levels (e.g., 1-10) or hierarchical classifications (e.g., "must be satisfied," "should be satisfied," "can be satisfied") are typically used to represent constraint priorities, and constraint weights or processing order are adjusted accordingly during the optimization process.

[0218] In this embodiment, the randomization algorithms used mainly include: Monte Carlo Simulation: This estimates statistical properties through a large number of random samples, evaluating the probability distribution and expected behavior of different execution paths. Multiple random execution scenarios are generated to simulate the program's behavior under different conditions, establishing a more reliable statistical model. Random Walk: A controlled random traversal is performed on the test execution path graph to discover paths that traditional deterministic analysis might overlook. Random walks are particularly suitable for exploring large and complex state spaces, and can access rare but potentially important execution paths with a certain probability. Random Restart: The search algorithm is restarted multiple times from different random starting points to avoid local optima. This technique is particularly effective for complex path planning problems, increasing the chance of finding a global optimum. Probability-weighted Sampling: Weighted random sampling is performed based on the execution probability of a path, focusing on high-probability execution paths while not completely ignoring low-probability paths. This method balances test coverage for common and edge scenarios. Therefore, through the combined effects of randomization techniques, a solution space with probability distribution is generated, which is the set of all possible test paths and their corresponding probability characteristics. The solution space not only contains feasible solutions but also includes probability information for each solution, reflecting the likelihood of different test paths being triggered in actual execution.

[0219] Heuristic pruning strategy is a technique for reducing search space and improving algorithm efficiency. It uses heuristic rules to quickly eliminate unlikely high-quality solutions, concentrating computational resources on the most promising candidate solutions. In path analysis and test generation, effective pruning strategies can significantly improve algorithm performance. The constructed heuristic pruning strategies include: Mutation point coverage pruning: prioritizing paths that cover more untested mutation points and quickly eliminating paths that do not pass through any mutation points. Value density pruning: calculating the value density of paths (the ratio of value to complexity), prioritizing high-value-density paths and pruning low-value, high-cost paths. Redundant path pruning: identifying paths with overlapping functions or coverage, retaining the most effective representative paths, and pruning redundant paths. Constraint violation pruning: quickly eliminating paths that clearly violate hard constraints, such as those exceeding resource limits or failing to meet critical dependencies. Historical performance pruning: based on historical test data, pruning path types that have performed poorly in the past and focusing on historically more effective path patterns. Secondly, these pruning strategies, combined with recursive scaling functions, constrained optimization models, and the Lagrange algorithm, form a complete scaled algorithm solving process. Scaled algorithm solving, through problem decomposition, increasing complexity, and multi-stage solution, effectively handles problems that were originally computationally infeasible.

[0220] The main steps of the scaling algorithm solution process include: Problem decomposition: Based on the recursive scaling function, the large problem is decomposed into manageable subproblems, such as by functional modules or code structure. Initial solution construction: Using greedy algorithms or heuristic methods, initial feasible solutions are quickly constructed to provide a starting point for subsequent optimization. Iterative optimization: Applying the Lagrange multiplier algorithm and constrained optimization models, the quality of the solution is gradually improved, balancing multiple constraints and optimization objectives. Solution space exploration: Using randomization algorithms and heuristic pruning strategies, the solution space is efficiently explored in a probability distribution to discover high-quality solutions. Solution merging and verification: The solutions to the subproblems are merged into a complete solution, and the merged solution is verified to satisfy global constraints, with adjustments made as necessary. Through this complex and systematic solution process, constrained random paths are finally obtained, which are test execution paths that satisfy multiple constraints and have optimal value. They satisfy hard constraints such as resource limitations and coverage requirements, while maximizing test value and mutant killing efficiency.

[0221] Furthermore, after obtaining the constrained random paths, test paths satisfying multiple constraint sets are calculated for each surviving mutant based on these paths. Shared test paths that can be shared by multiple surviving mutants are identified. A test execution sequence is generated from the test paths and shared test paths, indicating the order in which test cases are executed. A test path is an execution sequence in a program that starts from the entry point, goes through a series of code statements and control flow transitions, and finally reaches a specific program point or exit point. In mutation testing, an effective test path needs to pass through mutation points and be able to expose the behavioral differences introduced by the mutation.

[0222] In this embodiment, the process of calculating test paths that satisfy multiple constraints for each surviving mutant includes: Mutation point analysis: determining the precise mutation location and mutation type of the mutant, and understanding the impact of mutation operations on code logic. Impact path identification: identifying execution paths that can be affected by mutations through static analysis and data flow analysis. These paths must meet three conditions: reaching the mutation point, activating the mutation (causing the mutated code to be executed), and propagating the mutation effect (making the impact of the mutation observable). Constraint application: applying the previously determined multiple constraints (resource constraints, coverage constraints, etc.) to candidate paths, and filtering out feasible paths that satisfy all constraints. Optimal path selection: selecting the optimal test path from all feasible paths based on factors such as mutation killing efficiency, test execution cost, and path complexity. Path concretization: transforming abstract paths into specific execution steps and test scenarios to prepare for subsequent test input generation. Therefore, multiple possible test paths are generated for each mutant. These paths each have their own characteristics and are suitable for different test scenarios or constraints. By considering multiple paths rather than a single path, the chance of finding effective test cases is increased, and more options are provided for the next step of path sharing analysis.

[0223] Furthermore, shared test paths refer to execution paths that can test multiple variants simultaneously. By covering multiple test targets with a single execution, testing efficiency is significantly improved. In actual testing, different variants may have similarities or overlapping coverage. Utilizing this overlap can reduce redundant testing. The process of identifying shared test paths includes: Path clustering analysis: Clustering candidate test paths for all variants using path similarity metrics to identify structurally similar path groups. Similarity calculation considers code segment overlap, control flow structure similarity, and data dependency patterns. Coverage overlap analysis: Calculating the coverage overlap between different test paths to determine which variants a path can simultaneously cover. This is typically quantified by comparing the intersection and union ratios of path node sets. Multi-variant sharing optimization: Constructing a variant-path bipartite graph, where edges represent the path's coverage relationship with variants, and then using a minimum path coverage algorithm to find the minimum number of paths that ensure each variant is covered by at least one path. Shared path evaluation: Evaluating the value of each shared path, considering factors such as the number of variants covered, path complexity, and execution cost, and assigning priorities to the paths. Constraint Consistency Check: This verifies whether the shared path satisfies the constraints of all relevant variants, ensuring that sharing does not lead to constraint violations. This sharing analysis significantly reduces the number of test paths required while maintaining effective coverage of all variants. In practice, a well-designed shared path can often replace multiple independent paths, greatly improving testing efficiency.

[0224] A test execution sequence is an ordered list that determines the execution order of test cases, taking into account factors such as test dependencies, resource utilization, and execution efficiency. A reasonable execution sequence can minimize test environment preparation costs, avoid interference between tests, and improve overall execution efficiency. Specifically, the process of generating a test execution sequence includes: Dependency analysis: Constructing a dependency graph between test paths and identifying prerequisite and successor relationships. Dependencies may stem from data dependencies (one test generates data needed by another test), state dependencies (a test requires the system to be in a specific state), or resource dependencies (tests share specific resources). Topology sorting: Performing topology sorting based on the dependency graph to ensure that prerequisite tests execute before dependent tests. For tests without direct dependencies, the system can flexibly arrange their relative order. Resource optimization: Considering resource utilization efficiency, arranging the test execution order to minimize resource switching costs. For example, scheduling tests using the same database or test environment to execute in close proximity. Minimizing failure impact: Prioritizing critical tests or historically stable tests to minimize the impact of potential test failures on the overall testing process. Parallel execution opportunities: Identify groups of test paths that can be executed in parallel and explicitly mark parallel execution blocks in the execution sequence to improve test throughput. The final generated test execution sequence not only specifies the execution order of each test case but also includes execution environment configuration, intermediate verification points, and resource management instructions to ensure that tests can be executed smoothly in a real-world environment. Each test path in the sequence corresponds to a specific test case to be generated in subsequent steps. Through the mapping relationship between paths and test cases, the system can achieve a complete transformation from abstract path planning to concrete test execution.

[0225] Finally, based on the test execution sequence, high-value paths not covered by current test cases are analyzed. Input conditions triggering specific paths are calculated using a pre-defined symbolic execution algorithm. These input conditions generate test input data satisfying multiple constraints. Boundary values ​​are designed based on the mutation points of surviving mutants, and anomalies are indicated in the visualization analysis report. A mapping relationship between current test cases and surviving mutants is established, ultimately generating new test cases. High-value paths refer to program execution paths with exceptionally high testing value that are not yet covered by existing test cases. These paths possess high defect discovery potential, cover critical functions, or pass through important mutation points, making them the primary target of test enhancement.

[0226] In this embodiment, the process of analyzing high-value paths not covered by current test cases includes: Coverage gap analysis: Comparing the actual coverage of the current test suite with the complete path set of the test execution path graph, identifying uncovered path segments and nodes, with particular attention to uncovered paths containing mutation points. Value assessment: Performing multi-dimensional value assessment on uncovered paths, considering factors such as the number of mutation points on the path, code complexity, historical defect density, business importance, and expected execution probability. Difficulty assessment: Analyzing the difficulty of triggering uncovered paths, considering factors such as path condition complexity, environmental dependence, and special input requirements, balancing value and feasibility. Path clustering: Clustering uncovered high-value paths according to similarity and functional association, identifying path groups that can be solved together. Prioritization: Assigning priorities to uncovered paths based on comprehensive value scores, creating a path coverage task queue to guide subsequent test generation work. Therefore, through high-value path analysis, it is ensured that test resources are concentrated on the most valuable targets, rather than blindly pursuing coverage numbers. The identified high-value paths directly guide the subsequent test input generation process, ensuring that newly generated test cases can cover the most critical untested areas.

[0227] Symbolic execution algorithms are program analysis techniques that systematically explore program execution paths and generate path constraints by executing programs using symbolic values ​​instead of concrete values. Symbolic execution is particularly suitable for calculating input conditions that trigger specific paths, providing precise guidance for test generation. The symbolic execution algorithm used in this embodiment has the following key characteristics: Symbolic value representation: Symbolic variables are used instead of concrete input values. For example, the integer input x is represented as the symbolic value X, instead of the concrete number 42. Path constraint collection: During program execution, whenever a conditional branch is encountered, the symbolic executor records the branch condition and adds it to the path constraints. For example, when executing if(x>0), if the true branch is selected, the constraint "X>0" is added. Constraint solving: Path constraints are solved using SMT (Satisfiability Modulus Theory) solvers such as Z3, CVC4, or Yices to calculate the concrete input values ​​that can satisfy the constraints. Path exploration strategy: The program's execution space is systematically explored using depth-first, breadth-first, or heuristic strategies, prioritizing high-value or uncovered paths. State merging and branching: Maintain state branches at program branch points and merge similar states at appropriate times to balance path coverage and computational efficiency.

[0228] To address this, this embodiment utilizes symbolic execution to trigger input conditions for a specific path, including: Path transformation: converting the target high-value path into a series of program points and branch decisions, creating a path execution specification. Symbolic initialization: creating symbolic values ​​for all relevant input parameters, preparing the symbolic execution environment. Constraint collection: executing the program along the target path, collecting path constraints for all branch points, and constructing a complete path condition expression. Constraint simplification: logically simplifying the path conditions, removing redundant constraints, and reducing solution complexity. Constraint solving: submitting the simplified path conditions to the constraint solver, calculating the specific combination of input values ​​that satisfies all constraints. For each high-value path, this embodiment may generate multiple different sets of input conditions, all of which can trigger the target path but may test different data boundary conditions or anomalies. This diverse generation of input conditions increases the comprehensiveness of the testing.

[0229] Test input data is the set of specific input values ​​required to execute a particular test case, including function parameters, system environment variables, and external resource states. High-quality test input data should not only trigger the target path but also consider factors such as boundary conditions, anomalies, and diversity. Specifically, the process of generating test input data that satisfies multiple constraints from input conditions includes: Constraint fusion: Combining the path constraints generated by symbolic execution with the data constraints in the test requirements (such as format requirements and valid range) to form a complete set of input constraints. Diversification strategy: In the solution space that satisfies the constraints, applying diversification strategies to generate multiple sets of different input data, covering different equivalence classes and boundary cases. Common diversification strategies include boundary value selection, random sampling, and outlier injection. Data dependency handling: For multiple input parameters with dependencies, ensuring their consistency and rationality, generating input combinations that conform to real-world scenarios. Domain knowledge application: Based on application domain knowledge, generating input data that conforms to business rules and actual usage patterns to improve the realism and effectiveness of the test. Data format conversion: Converting abstract input values ​​into the specific format required for test execution, such as JSON objects, XML documents, or binary data streams. In addition to input generation based on symbolic execution, this embodiment also pays special attention to the design of boundary values ​​for mutation points. Boundary values ​​refer to input values ​​located near the boundaries of the allowable range, which are usually high-risk areas for errors.

[0230] In this embodiment, the process of designing boundary values ​​based on the mutation points of surviving variants includes: Mutation type analysis: Determining key boundary points based on the type of mutation operation (e.g., condition inversion, boundary modification, arithmetic operator change). For example, for a mutation point that mutates ">" to ">=", the equivalence condition becomes a key boundary. Data range determination: Analyzing code and documentation to determine the effective value range and boundary conditions of relevant variables. Boundary value generation: Generating test data for each key boundary, typically including boundary values, boundary value ±1, minimum / maximum effective values, and out-of-range values. Outlier design: Designing special outlier inputs based on the anomalies indicated in the visual analysis report, such as null values, maximum values, and malformed data.

[0231] Finally, this embodiment establishes a mapping relationship between the current test cases and surviving mutants, ensuring that each mutant has a corresponding test case attempting to kill it, and that test resources are used efficiently. The mapping relationship establishment process includes: Coverage matrix construction: creating a test case-mutant coverage matrix to record which mutants each test case might affect. Validity prediction: predicting the probability of each test case killing a specific mutant based on historical data and code analysis. Test allocation optimization: using binary matching or network flow algorithms to optimize the allocation relationship between test cases and mutants, ensuring that each mutant has targeted testing while minimizing the total number of tests. Coverage verification: ensuring that all mutants are covered by at least one test case, with no coverage gaps. Finally, new test cases are generated based on high-value paths, test input data, and the mapping relationship. Each test case is a complete executable test unit, including test steps, input data, execution environment configuration, and expected results.

[0232] Therefore, the process of generating new test cases includes: Test code template selection: Selecting an appropriate test framework and code template based on the test objectives and programming language. Test method generation: Creating a test method structure, including three main parts: setup, execution, and assertion verification. Input data injection: Converting the generated test input data into code form and injecting it into the test method. Environment configuration code: Generating the necessary environment setup code to ensure the test executes in the correct context. Assertion statement generation: Generating appropriate assertion statements based on the expected program behavior and mutation characteristics to verify whether the program output meets expectations. Test annotation addition: Adding comments describing the test purpose, coverage path, and target mutants to improve test readability and maintainability. Therefore, the newly generated test cases are then added to the test suite for the next round of mutation test execution. This embodiment continuously improves the test suite through this iterative approach, gradually eliminating more mutants and improving test quality.

[0233] Therefore, this embodiment constructs a complete intelligent test generation loop from test execution path graph construction, multi-constraint modeling, path solving to test case generation. Each iteration generates more targeted test cases based on the current surviving mutants and visualization analysis reports, systematically expanding the test coverage, improving the mutation score, and ultimately significantly improving the efficiency and effectiveness of software testing.

[0234] In one specific embodiment, the scaling algorithm solution process is performed through the following steps:

[0235] Initialize the parameter matrix and weight vector of the constrained optimization model, determine the scaling factor and convergence threshold, establish the hierarchical structure of the recursive decomposition, and construct a scaling computation framework based on the parameter matrix, the weight vector, the scaling factor, the convergence threshold and the hierarchical structure of the recursive decomposition.

[0236] Based on the scaling computation framework and the recursive scaling function, the problem size is gradually reduced through a preset dynamic programming algorithm, and the constraints are decomposed at each scaling level to generate a set of subproblems.

[0237] For each subproblem in the set of subproblems, the set of multiple constraints is transformed into a penalty term of the objective function using a preset Lagrange multiplier algorithm. The gradient of the Lagrange function and the Hessian matrix are calculated. Based on the penalty term, the gradient of the Lagrange function, and the Hessian matrix, a local optimum is solved.

[0238] The local optimal solution is mapped back to the upper-level problem space through a scaling transformation, and the scaling factor is updated to perform cross-level solution space propagation of the local optimal solution;

[0239] Repeat the scaling hierarchy decomposition and solution space propagation process until the preset convergence condition is met or the preset number of iterations is reached. Then, merge the optimal solutions of each level and output the globally optimal test path scheme that satisfies all the multiple constraint conditions set to obtain the constrained random path.

[0240] In this embodiment, by establishing a multi-level recursive decomposition framework and combining dynamic programming and Lagrange optimization techniques, the complex constraint problem in large-scale test path generation is effectively solved. The entire solution process includes key steps such as constructing a scaling computational framework, decomposing the recursive problem, solving local optimization problems, propagating across the solution space across levels, and merging and verifying solutions. The implementation principle and technical details of this scaling algorithm solution process will be explained in detail below:

[0241] First, the parameter matrix and weight vector of the constrained optimization model are initialized, the scaling factor and convergence threshold are determined, a hierarchical structure of recursive decomposition is established, and a scaling computational framework is constructed based on these elements. The parameter matrix is ​​a mathematical structure in a constrained optimization model that represents the relationship between decision variables and constraints. In the test path generation problem, the parameter matrix typically represents the quantitative relationship between test path selection and various constraints. Each row of the parameter matrix corresponds to a constraint, each column corresponds to a possible decision variable (such as the selection of a specific test path), and the matrix elements represent the influence coefficient of a specific decision on the constraints. The weight vector defines the relative importance of multiple optimization objectives or constraints, used to transform multi-objective problems into single-objective optimization problems. In test path generation with multiple constraints, the weight vector reflects the priority ranking of different constraints and optimization objectives. The process of determining the weight vector includes: Business priority analysis: Based on project requirements and business priorities, the relative importance of different types of constraints is determined. For example, coverage constraints for security-related tests may have a higher weight than performance constraints. Risk Assessment: Based on the risk analysis results, higher weights are assigned to constraints in high-risk areas to ensure that testing resources are prioritized for the most critical areas. Expert Experience Input: Initial weight values ​​are set by combining the experience and judgment of domain experts, reflecting their subjective assessment of the importance of different constraints. Historical Data Analysis: Historical test performance data is analyzed to identify which constraints contribute more to defect discovery or test quality improvement, and the weight values ​​are adjusted accordingly. The weight vector is usually normalized so that the sum of all weights is 1 or another specific value, facilitating comparison and adjustment. During the optimization process, the weight vector may be dynamically adjusted based on intermediate results or additional information to adapt to constantly changing testing needs and priorities.

[0242] The scaling factor is a parameter that controls the proportion by which the problem size is reduced during recursive decomposition. The scaling factor determines the extent to which the problem is reduced in each recursive decomposition, directly affecting the convergence speed and computational efficiency of the algorithm. In complex optimization problems involving test path generation, a suitable scaling factor can balance computational complexity and solution quality. The process of determining the scaling factor includes: Problem size analysis: assessing the size and complexity of the original problem, including the number of possible test paths, the number of constraints, and the dimension of decision variables. Computational resource assessment: considering available computational resources and time constraints, determining a suitable problem decomposition granularity. Application of empirical rules: applying domain-specific empirical rules, such as setting the initial scaling factor to 0.5-0.7 for an n-dimensional decision space, meaning that each recursion reduces the problem size to 50%-70% of its original size. Adaptive adjustment mechanism: designing adaptive adjustment rules for the scaling factor, enabling it to dynamically adjust based on algorithm progress and intermediate results. For example, increasing the scaling factor accelerates convergence when the solution converges slowly; decreasing the scaling factor improves accuracy when the solution quality is poor. The scaling factor is usually dynamically adjusted during algorithm execution based on convergence and solution quality to achieve an optimal balance between computational efficiency and solution quality.

[0243] The convergence threshold is a numerical standard for determining whether an optimization algorithm has reached a stable state and can terminate. It defines the extent to which the change in the solution or the improvement in the objective function value between adjacent iterations is considered convergent. A reasonable convergence threshold can prevent premature termination or unnecessary overcomputation.

[0244] A hierarchical structure for recursive decomposition is an organizational framework for breaking down large optimization problems into multiple levels of nested subproblems. This allows complex problems to be solved incrementally by addressing a series of smaller, less complex subproblems. In test path generation, hierarchical structures are typically designed based on the modular organization of code, functional units, or complexity distribution.

[0245] Therefore, the Scaled Computation Framework is a comprehensive computational system that integrates parameter matrices, weight vectors, scaling factors, convergence thresholds, and recursive decomposition hierarchies, providing a unified computational environment and data structure for the execution of scaled algorithms. The Scaled Computation Framework is the infrastructure for implementing efficient scaling algorithms. A complete Scaled Computation Framework is not only a collection of algorithmic components but also includes complete mechanisms for problem representation, computational control, result verification, and dynamic adjustment, providing a stable and efficient execution environment for complex scaling algorithms.

[0246] Subsequently, after constructing the scaling computation framework, based on this framework and the recursive scaling function, the problem size is progressively reduced using a pre-defined dynamic programming algorithm. Constraints are decomposed at each scaling level, generating a set of subproblems. This step decomposes the original large-scale optimization problem into a series of manageable subproblems. Dynamic programming is a method for optimizing computation by decomposing complex problems into subproblems and storing their solutions. In the scaling solution process of test path generation, dynamic programming is used to systematically reduce the problem size, avoid redundant computations, and ensure the construction of a globally optimal solution.

[0247] This embodiment describes the process of decomposing constraints at each scaling level, including: Constraint Classification: Classifying the original multiple constraints according to their characteristics and relevance, identifying constraint groups that can be handled independently and those that require collaborative consideration. Constraint Simplification: Simplifying constraint expressions based on the level of abstraction at the current scaling level, retaining key features and reducing complexity. For example, at a high level, precise time constraints may be simplified to coarse-grained time levels. Constraint Assignment: Assigning constraints to appropriate subproblems, ensuring that each subproblem contains all constraints related to it, and that constraint assignment does not lead to strong coupling between subproblems. Constraint Transformation: Transforming global constraints into local constraints at the subproblem level, allowing subproblems to be solved independently. This may involve constraint decomposition, relaxation, or restatement. Constraint Consistency Check: Verifying whether the decomposed constraint system is equivalent to the original constraints, ensuring that no key constraints are omitted or contradictory constraints are introduced.

[0248] A subproblem set is a group of smaller, less complex optimization problems obtained by recursively decomposing the original problem. Each subproblem has well-defined decision variables, constraints, and optimization objectives, and can be solved independently or collaboratively with a finite number of other subproblems. The process of generating a subproblem set includes: defining the problem boundary: clearly defining the boundary for each subproblem, including the scope of code covered, the test objectives considered, and the available decision variables. For example, the test path planning of a large program can be decomposed into subproblems for each function or module. Decision variable partitioning: dividing the set of decision variables of the original problem into the subproblems, ensuring that each decision variable clearly belongs to a specific subproblem or is shared by multiple related subproblems. Constructing local objective functions: constructing local objective functions for each subproblem, reflecting the contribution of the subproblem to the global optimization objective. Local objective functions should be consistent with the global objective function, while considering the optimization direction specific to the subproblem. Establishing interface constraints: defining interface constraints between subproblems to ensure that subproblem solutions can be correctly combined into a global solution. Interface constraints are usually expressed as state consistency requirements or resource allocation rules at the subproblem boundaries. Priority allocation: Based on the complexity, importance, and dependencies of subproblems, solution priorities are assigned to guide subsequent allocation of computational resources and the order of solutions. Typical organizational forms for subproblem sets include tree structures (subproblems form a hierarchical tree, representing the recursive decomposition process), directed acyclic graphs (subproblems have dependencies but no cyclic dependencies), or grid structures (subproblems are divided according to multiple dimensions, forming a regular grid). The relationships between subproblems determine the propagation path and merging strategy of solutions. Therefore, through this systematic recursive problem decomposition, large-scale optimization problems that were originally difficult to solve directly are transformed into a series of manageable-scale, clearly structured subproblems, greatly reducing computational complexity and providing a good structural foundation for subsequent local optimization and solution integration.

[0249] Subsequently, for each subproblem in the generated set of subproblems, a pre-defined Lagrange multiplier algorithm is used to transform the set of multiple constraints into a penalty term of the objective function. The gradient of the Lagrange function and the Hessian matrix are calculated, and a local optimum is found based on these elements. This step applies an efficient numerical optimization method to each decomposed subproblem to find the optimal solution that satisfies the local constraints. In this embodiment, transforming multiple constraints into a penalty term of the objective function reformulates the original multi-constraint optimization problem into an unconstrained or simpler problem, which can be solved using mature unconstrained optimization methods. The transformation process preserves the optimality conditions of the original problem while improving computational efficiency and numerical stability.

[0250] The gradient is the rate of change of a function in each direction of the variables, representing the direction in which the function value increases the fastest. In optimization algorithms, the gradient is crucial information guiding the search direction; the negative direction of the gradient is usually the direction in which the function value decreases the fastest. Calculating the gradient of the Lagrange function is the first step in finding a local optimum. The process of calculating the gradient of the Lagrange function includes: variable gradient calculation; analytical gradient calculation: for simple functions with explicit mathematical expressions, the exact gradient expression can be obtained directly using symbolic differentiation, and then substituted into specific values ​​for calculation; numerical gradient estimation: for complex functions or black-box functions, numerical methods such as the finite difference method can be used to estimate the gradient, approximating the derivative by calculating the difference before and after a small change in the variables; automatic differentiation application: for complex functions with known structures, automatic differentiation techniques can be used to efficiently calculate the accurate gradient, avoiding the complexity of analytical calculations and the errors of numerical estimation. The result of gradient calculation is used to determine the direction of the optimization search, playing a key role in algorithms such as gradient descent, conjugate gradient, or quasi-Newton methods. The magnitude (norm) of the gradient is also commonly used as one of the criteria for convergence judgment; when the gradient is close to zero, it usually indicates that the algorithm is close to a local optimum.

[0251] The Hessian matrix is ​​the second-order partial derivative matrix of a function, describing the curvature of the function along the directions of each variable. In optimization algorithms, the Hessian matrix provides important information about the local shape of the function, which is crucial for determining the search step size and direction. The main uses of the Hessian matrix in optimization algorithms include: determining the search direction in Newton's method and quasi-Newton methods; analyzing the local convexity and saddle point characteristics of a function; estimating uncertainties near the optimal solution; and adjusting learning rate or step size strategies.

[0252] A local optimal solution is a solution that yields the optimal objective function value within a certain neighborhood under given constraints. For each subproblem, the system needs to find the optimal decision scheme that satisfies the local constraints as part of the overall optimization. The process of finding a local optimal solution based on penalty terms, gradients, and the Hessian matrix includes: Initial point selection: Choosing a suitable initial point for the optimization algorithm, which can be determined based on heuristic rules, random generation, or historical experience. A good initial point can significantly accelerate convergence and increase the probability of finding the global optimum. Search direction determination: Determining the search direction based on the gradient and Hessian information at the current point. Commonly used directions include the negative gradient direction (steepest descent method), the gradient direction multiplied by the inverse of the negative Hessian matrix (Newton's method), or a compromise between the two (quasi-Newton methods). Step size selection: Determining an appropriate step size along the search direction to allow the objective function value to decrease sufficiently. Commonly used step size selection techniques include line search (such as the Armijo criterion and Wolfe conditions) and trust region methods. Iterative Update: Update the current solution according to the search direction and step size, calculate the objective function value, gradient, and Hessian matrix at the new solution, and prepare for the next iteration. Convergence Check: Check if convergence conditions are met, such as gradient norm less than a threshold, objective function value change less than a threshold, constraint violation less than a threshold, etc. If the conditions are met, stop the iteration. Multi-point Restart: To avoid local optima, the optimization process can be started from multiple different initial points, and the best solution among all local optima is selected as the final result. In practical implementations, the system may use mature optimization algorithm libraries (such as IPOPT, SLSQP, or L-BFGS-B) to solve local optima. These libraries provide efficient and robust numerical optimization implementations capable of handling optimization problems of various sizes and complexities. The quality of local optima is crucial to the success of the overall algorithm. The system usually verifies and analyzes local solutions to ensure they satisfy all local constraints and evaluates their quality gap relative to the estimated global optimum. In some cases, if the quality of local solutions is poor, the system may trigger a re-solution or adjust the decomposition strategy.

[0253] Furthermore, after obtaining a local optimum, the local optimum is mapped back to the upper-level problem space through a scaling transformation, and the scaling factor is updated to propagate the local optimum across levels of the solution space. Then, the scaling hierarchy decomposition and solution space propagation process is repeated until the preset convergence condition is met or the preset number of iterations is reached. Finally, the optimal solutions of each level are merged, and the globally optimal test path scheme that satisfies all sets of multiple constraints is output, thus obtaining a constrained random path.

[0254] Scaling transformation is a mathematical operation used to transform solution vectors between problem spaces of different scales while preserving the structural properties and relative relationships of the solutions. In multi-level optimization, scaling transformation ensures that solutions to subproblems can be appropriately mapped back to the parent problem space, while maintaining the validity and quality of the solutions. The process of mapping local optima back to the upper-level problem space includes: Dimensional expansion: Extending the low-dimensional solution of the subproblem to the high-dimensional space of the parent problem, typically requiring filling in decision variables in the parent problem but not in the subproblem. Filling strategies may be based on default values, historical optima, or heuristic rules. Coordinate transformation: If the subproblem uses a different coordinate system than the parent problem (e.g., a rotated, translated, or scaled coordinate system), matrix transformations are needed to convert the solution back to the original coordinate system of the parent problem. Constraint adaptation: Ensuring that the mapped solution satisfies the constraints of the parent problem, adjusting or correcting as necessary. This may involve constraint projection, repair operations, or local searches. Solution quality preservation: Preserving key quality properties of the solution during the transformation process, such as objective function values, constraint satisfaction, and structural properties. The transformation should not significantly reduce the quality or feasibility of the solution. Interpretive maintenance: Ensures that the transformed solution still has a clear physical or business meaning, especially in problems involving discrete decision-making or combinatorial structures.

[0255] The specific form of the scaling transformation depends on the nature of the problem and the decomposition strategy. For linear problems, the transformation may be a simple linear mapping; for nonlinear problems, more complex nonlinear transformations or custom mapping functions based on the characteristics of the problem may be required.

[0256] Scaling factor update is the process of dynamically adjusting the scaling factor based on algorithm progress and solution quality, aiming to balance computational efficiency and solution accuracy. A suitable scaling factor update strategy can accelerate algorithm convergence and improve the quality of the final solution. Methods for updating the scaling factor include: **Adaptive convergence speed:** Adjusting the scaling factor according to the convergence speed of the optimization process. Increasing the scaling factor to accelerate convergence when the algorithm converges slowly; decreasing the scaling factor to improve accuracy when the solution quality deteriorates. **Solution quality feedback:** Adjusting the scaling factor based on the quality of the current solution (e.g., objective function value, constraint satisfaction). If the solution quality is high, increasing the scaling factor can accelerate convergence; if the solution quality deteriorates, decreasing the scaling factor allows for a more refined search. **Exploration and exploitation balance:** Using a larger scaling factor for extensive exploration in the early stages of optimization, and a smaller scaling factor for local refinement in the later stages, balancing global exploration and local exploitation. **Momentum mechanism:** Introducing a momentum-like mechanism to make the scaling factor changes consider historical adjustment trends, avoiding excessive oscillations and improving the stability and continuity of the update. Phase-based resetting: The scaling factor is reset at critical stages of the algorithm (such as when it gets stuck in a local optimum or reaches a certain percentage of iterations), injecting new vitality into the optimization process. Scaling factor updates typically employ a smooth adjustment strategy to avoid instability caused by drastic changes.

[0257] Cross-level solution space propagation is the process of passing optimization results from one level to adjacent levels, influencing their initial conditions, constraint settings, or search space. The process of performing cross-level solution space propagation includes: Top-down propagation: Decomposing the solution to the upper-level problem and passing it to the lower-level subproblems as initial conditions or constraints for solving the subproblems. For example, system-level test resource allocation decisions can be passed to the module level to guide test path planning for each module. Bottom-up propagation: Integrating the solutions to lower-level subproblems and passing them to the upper-level problem, providing a more accurate model of the subproblem behavior for the upper-level problem. For example, test path characteristics at the function level can be aggregated as input for module-level test planning. Lateral propagation: Passing information and constraints between adjacent subproblems at the same level to ensure the consistency and compatibility of subproblem solutions. For example, two code modules sharing a boundary need to coordinate the connection of their test paths at the boundary. Global constraint propagation: Decomposing and propagating global constraints to each level and subproblem to ensure that local optimization does not violate global requirements. For example, overall resource budget constraints need to be allocated to each module and function. Solution quality information propagation: This involves disseminating the quality assessment results of the solution (such as convergence rate and constraint violation rate) to relevant levels to guide resource allocation and optimization strategy adjustments. Solution space propagation is typically achieved through well-defined interfaces and transformation rules, ensuring orderly and consistent information flow between different levels. The propagation process can be deterministic (based on fixed rules) or adaptive (dynamically adjusted according to the current state).

[0258] Convergence criteria are the standards used to determine whether an iterative optimization algorithm has reached a stable state and can terminate. Reasonable convergence criteria can ensure solution quality while avoiding unnecessary waste of computational resources. Methods for determining whether preset convergence criteria are met include: objective function convergence; solution vector convergence; gradient convergence; constraint satisfaction; and Lagrange multiplier stability. Convergence criteria typically employ a combination of multiple criteria, requiring the simultaneous satisfaction of multiple conditions for convergence. Furthermore, this embodiment may set a maximum number of iterations as a fallback condition to ensure the algorithm terminates within a finite time, even if the ideal convergence state is not reached.

[0259] The global optimal solution is the solution with the optimal objective function value across the entire feasible region, and it is the ultimate goal of multi-level scaling optimization. In complex test path generation problems, a strict global optimum is often difficult to guarantee; the system aims for a high-quality approximate global optimal solution.

[0260] The process of merging optimal solutions at different levels includes: Solution merging strategy formulation: Based on the problem structure and decomposition method, determine the specific strategy for merging solutions, such as hierarchical combination, weight averaging, or priority replacement. Sub-problem solution extraction: Extract key decision variables and state information from the optimization results of each sub-problem to prepare for the merging operation. Consistency check: Verify whether solution fragments from different levels and sub-problems are consistent, especially at sub-problem boundaries. If inconsistencies are found, adjustments or constraint corrections are needed. Global constraint verification: Confirm that the merged solution satisfies all global constraints; if necessary, perform local adjustments to eliminate constraint violations. Solution optimization: Perform final optimization based on the merging, fine-tuning decision variables to improve the overall objective function value while maintaining constraint satisfaction. Solution quality assessment: Evaluate the quality of the final solution, including indicators such as objective function value, constraint satisfaction, coverage, and resource utilization efficiency.

[0261] The Global Optimal Test Path Scheme is the final output of the algorithm, representing the path combination scheme that achieves the highest test value while satisfying all constraints. Constrained Random Paths refer to test execution paths generated with a certain degree of randomness under multiple constraints. Compared to purely deterministic paths, constrained random paths maintain a degree of exploratory nature and diversity, helping to discover unexpected defects and boundary conditions. Specifically, the characteristics of generating constrained random paths include: Constraint Satisfaction Guarantee: The generated paths strictly satisfy all hard constraints, such as resource limitations, coverage requirements, and dependencies. Value Maximization: Under the premise of satisfying constraints, the path combination maximizes the test value, such as defect discovery probability, mutant kill rate, or code coverage. Randomness Preservation: Path generation retains a moderate degree of randomness, especially among multiple approximately equivalent path choices, increasing the diversity and robustness of the tests. Mutation Point Coverage: Special attention is paid to mutation point coverage in mutation testing, ensuring that each mutation point is effectively triggered by at least one path. Dynamically Adjustable: The path scheme is dynamically adjustable, capable of real-time adjustments and optimizations based on test execution feedback and newly discovered information. The final generated constrained random path is not only a mathematical optimization result but also a practical test execution guide, directly supporting subsequent test case generation and execution management. The path scheme typically includes information such as execution sequence, coverage objectives, resource requirements, and expected results, providing the testing team with a comprehensive execution guide.

[0262] Therefore, the scaling algorithm effectively addresses the challenges of generating large-scale, multi-constraint test paths, finding high-quality solutions within limited computational resources and time, and significantly improving testing efficiency and effectiveness. This method is particularly suitable for high-complexity, multi-constraint testing techniques such as mutation testing, intelligently balancing testing resources and testing value to achieve accurate and efficient test execution.

[0263] like Figure 2 As shown, the present invention also provides a mutation testing device based on intelligent automated scripts, comprising:

[0264] The code analysis module 201 is used to acquire the original source code, runtime information and version control data, and use a context-aware syntax tree constructed by a specific language parser to extract the statement execution order and branch dependencies in the original source code, generate a control flow graph and a data flow graph, and perform feature extraction on the control flow graph, the data flow graph, the runtime information and the version control data to obtain multi-dimensional code features, wherein each node in the context-aware syntax tree carries contextual meta-information;

[0265] The mutant generation module 202 is used to perform code semantic analysis on the multi-dimensional code features based on the multi-dimensional code features using a preset large language model, identify potential defect types and corresponding mutation rules, predict the test efficiency of the mutants by combining a preset deep Q-learning model, and generate a mutant to be processed that conforms to the defect type based on the test efficiency and the mutation rules. The test efficiency is used to evaluate the probability that the mutant will have a defect problem related to the test cases after executing preset test cases.

[0266] The test execution module 203 is used to perform syntax checking and equivalence analysis on the mutant to be processed to obtain a valid mutant, use the test cases to test the valid mutant, and record the test execution result of each valid mutant, wherein the test execution result is a survival state or a kill state.

[0267] The results analysis module 204 is used to calculate mutation test indicators and locate code weaknesses based on the test execution results, and identify test blind spots based on surviving mutants, so as to generate a visual analysis report containing test strategy optimization suggestions based on the mutation test indicators, the code weaknesses and the test blind spots, wherein the surviving mutants are used to indicate that the test execution results are valid mutants in the surviving state;

[0268] The test case generation module 205 is used to iteratively generate new test cases based on the current surviving mutants and the visualization analysis report, and to use the new test cases to test the current surviving mutants.

[0269] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for intelligent automation script based mutation testing, the method comprising: The method comprises the following steps: obtaining original source code, runtime information and version control data, extracting the statement execution order and branch dependency relationship in the original source code using a context-aware syntax tree constructed by a specific language parser, generating a control flow graph and a data flow graph, and performing feature extraction on the control flow graph, the data flow graph, the runtime information and the version control data to obtain multi-dimensional code features, wherein each node in the context-aware syntax tree carries context meta information; based on the multi-dimensional code features, using a preset large language model to perform code semantic analysis on the multi-dimensional code features, identifying potential defect types and corresponding mutation rules, combining a preset deep Q learning model to predict the test efficiency of the mutant, and based on the test efficiency and the mutation rule, generating a to-be-processed mutant conforming to the defect type, wherein the test efficiency is used to evaluate the possibility of the mutant to appear defect problems related to the test case after executing the preset test case; performing syntax checking and equivalence analysis on the to-be-processed mutant to obtain an effective mutant, testing the effective mutant using the test case, and recording the test execution result of each effective mutant, wherein the test execution result is a survival state or a kill state; based on the test execution result, calculating a mutation test index and locating a code weak point, identifying a test blind area according to a survival mutant, so that based on the mutation test index, the code weak point and the test blind area, a visual analysis report containing test strategy optimization suggestions is generated, wherein the survival mutant indicates an effective mutant with the test execution result in the survival state; iteratively generating a new test case according to the current survival mutant and the visual analysis report, and testing the current survival mutant using the new test case.

2. The method of claim 1, wherein, The method comprises the following steps: based on the original source code, an abstract syntax tree is constructed using a specific language parser, and a context-aware syntax tree is generated based on the abstract syntax tree, wherein the nodes of the context-aware syntax tree include variable nodes, function call nodes and conditional statement nodes, the variable nodes are attached with type and scope information, the function call nodes are attached with parameter type and return value type, and the conditional statement nodes are attached with branch dependency variable information; performing control flow analysis on the context-aware syntax tree to extract the statement execution order and branch dependency relationship, and constructing a control flow graph, wherein the control flow graph is used to map the program execution path; Tracking definition and usage paths of data variables in the control flow graph, and analyzing data dependency relationships of the control flow graph to construct a data flow graph, establishing a data usage relationship chain according to the control flow graph and the data flow graph; Performing non-intrusive monitoring through a preset dynamic instrumentation algorithm to obtain runtime information during program execution, the runtime information including execution paths, variable actual values, and method call frequencies; Obtaining code history records, identifying added, deleted, and modified code change areas based on the code history records, and analyzing change context relationships to generate version control data according to the code change areas and the change context relationships, the code history records including code repository history submission records and branch differences; Based on the data usage relationship chain, the runtime information, and the version control data, extracting a code feature vector, generating multi-dimensional code features from the code feature vector, the code feature vector including code complexity indicators, test coverage, and historical defect density.

3. The method of claim 2, wherein, Based on the multi-dimensional code features, using a preset large language model to perform code semantic analysis on the multi-dimensional code features, identifying potential defect types and corresponding mutation rules, combining a preset deep Q learning model to predict the test efficiency of mutants, and generating mutants that meet the defect types based on the test efficiency and the mutation rules, including: Using a preset large language model to analyze the code structure and semantic features of the multi-dimensional code features, identifying potential defect types and error patterns; Matching the defect types and error patterns with a pre-constructed defect pattern knowledge base, selecting mutation rules that adapt to the current code context, generating preliminary mutation candidate areas, the mutation rules including target error patterns, and the target error patterns including logical relationship reversal, boundary condition error, and null value processing omission; Determining key mutation point positions according to the preliminary mutation candidate areas, the runtime information, and the version control data, adjusting the application position and intensity of the mutation rules in combination with the code application factors of the original source code, the code application factors including execution frequency, branch coverage, and modification; Predicting the test efficiency of different mutants through a preset deep Q learning model, and selecting the mutation types and positions corresponding to the high-value mutants when the test efficiency is greater than a preset value threshold; According to the high-value mutant combination, applying the corresponding mutation rules at the key mutation point positions to generate mutants that meet the defect types and error patterns and group similar mutants to obtain the mutants to be processed.

4. The method of claim 3, wherein, Performing syntax checking and equivalence analysis on the mutants to be processed to obtain effective mutants, testing the effective mutants using the test cases, and recording the test execution results of each effective mutant, including: calling a preset language compiler or interpreter to verify syntax correctness of the to-be-processed mutant and capture compilation error information, filtering out the to-be-processed mutant whose syntax information does not meet a preset syntax condition, and retaining the to-be-processed mutant whose syntax information meets the syntax condition; using a preset theorem prover to convert code of the retained to-be-processed mutant into a logical formula for equivalence proof, comparing control flow structures of the original source code and the retained to-be-processed mutant, and comparing output results of input sampling execution to filter out the to-be-processed mutant equivalent to the original program function corresponding to the original source code, and obtain an effective mutant; running the effective mutant in parallel on a test execution cluster, and testing the effective mutant using a preset test case, and recording test execution results of each effective mutant.

5. The method of claim 4, wherein, based on the test execution results, calculating a mutation test index and locating a code weakness, identifying a test blind area according to a surviving mutant, so that a visual analysis report containing test strategy optimization suggestions is generated based on the mutation test index, the code weakness and the test blind area, including: based on the test execution results, calculating a mutation test index, wherein the mutation test index includes a mutation score, a kill rate, a test case effectiveness score and a mutation coverage, the mutation score is used to indicate a proportion of killed mutants in a total number of mutants, and the killed mutant is used to indicate the effective mutant whose test execution result is the killed state; analyzing code region features corresponding to the surviving mutant to determine a test blind area, the code region features including complex branch logic and boundary conditions; based on the test execution results, analyzing defect dense areas and high-risk areas in the code in combination with code complexity and pre-acquired historical defect data to locate a code weakness; converting the mutation test index, the test blind area and the code weakness into a mutation score trend graph, a mutant state distribution graph and a test coverage heat map, and then performing visual display; based on the mutation score trend graph, the mutant state distribution graph and the test coverage heat map, generating a visual analysis report, and the visual analysis report is used to indicate an enhancement direction of formulating a test case, identify a high-value test area and automatic test coverage.

6. The method of claim 5, wherein, The method further includes generating the to-be-processed mutant by the following steps: modeling a mutation test process as a Markov decision process, constructing a mutation test MDP model based on the Markov decision process, the mutation test MDP model including a state space, an action space and a reward function, the state space including code complexity, coverage and historical defect density, the action space including conditional inversion and boundary value modification, and the reward function being used to indicate a probability that a mutant is killed by a test case; adopting a preset rational function to represent a state-action value function in the mutation test MDP model, representing the Q value as a polynomial ratio form, and establishing a value function representation; using a preset symbolic operation algorithm to iteratively optimize the value function representation; Based on the value function expression obtained by iterative optimization, the long-term values of multiple mutation strategies for mutation testing are compared, the behaviors of the mutation strategies when the discount factor approaches a preset parameter are solved, and a corresponding mutation strategy is determined based on the comparison result and the solved behaviors; According to the determined mutation strategy, the rational function value of each potential mutation point is calculated, and a mutation point priority queue is established based on the rational function value, and a to-be-processed mutant containing priority sorting information is generated from the mutation point priority queue.

7. The method of claim 6, wherein, The code structure and semantic features of the multi-dimensional code features are analyzed using a preset large language model, and potential defect types and error patterns are identified, including: An agent model is constructed, which includes a syntax analysis agent for constructing code syntax structure and program, a semantic understanding agent for indicating code intent and function, a vulnerability mining agent for identifying security vulnerabilities and boundary conditions, a defect pattern agent for matching historical defect patterns, and a test generation agent for indicating updating test cases according to the problems found, and a neural algorithm reasoner is configured for each agent in the agent model, which contains an analysis network and an algorithm knowledge base adapted to a preset code analysis task based on a preset Transformer architecture, and the algorithm knowledge base contains programming paradigms, design patterns and error patterns, and the neural algorithm reasoner is used to instruct each agent to perform algorithm step derivation; Based on a standardized message format, an agent collaboration framework between agents in the agent model is determined, wherein the standardized message format includes code snippets, analysis results and confidence scores, the analysis results are obtained by agents after analyzing their execution and / or the code snippets, and the agent collaboration framework includes a knowledge sharing mechanism and a conflict resolution mechanism based on a graph structure; Through the agent collaboration framework, code analysis tasks are performed according to the multi-dimensional code features, the code analysis tasks are used to instruct the syntax analysis agent to create a syntax understanding graph, the semantic understanding agent to interpret code functions, and the vulnerability mining agent and the defect pattern agent to identify potential problems in parallel and generate their respective analysis results; Based on the analysis results obtained by the code analysis tasks, the test generation agent determines a targeted test strategy, and each agent in the agent model verifies each other's analysis results through the neural algorithm reasoner to form multi-angle verified analysis evidence; The analysis evidence is integrated using weighted voting, the confidence scores of each agent are combined using a preset Bayesian inference algorithm, and the analysis evidence and the confidence scores are aggregated using a preset ensemble learning algorithm from multiple analysis perspectives to generate defect types and error patterns containing multi-agent consensus.

8. The method according to claim 6 or 7, characterized in that, The new test cases are generated iteratively according to the current surviving mutants and the visual analysis report, and the current surviving mutants are tested using the new test cases, including: constructing a test execution path graph based on a code execution path of each of the effective variants, assigning an execution probability to each edge in the test execution path graph, and marking a graph node where a mutation point is located, wherein a graph node in the test execution path graph represents a code state, and an edge in the test execution path graph represents an execution transition; determining a multi-constraint condition set including resource constraints, coverage constraints, dependency constraints, value constraints, and state constraints, and constructing a recursive scaling function for reducing a problem size and a constraint optimization model for indicating a transformation of a multi-constraint problem into a single-target optimization problem with weights; processing the multi-constraint condition set by using a preset Lagrange multiplier algorithm to determine constraint priorities, processing uncertainty in the test execution path graph by using a preset randomization algorithm to generate a solution space of a probability distribution, and constructing a heuristic pruning strategy, and performing a scaling algorithm solving process according to the heuristic pruning strategy, the recursive scaling function, the constraint optimization model, the multi-constraint condition set, the constraint priorities, and the solution space to obtain a constraint random path; according to the constraint random path, calculating a test path satisfying the multi-constraint condition set for each surviving variant, identifying a shared test path that can be shared by multiple surviving variants, and generating a test execution sequence from the test path and the shared test path, the test execution sequence being used to indicate an execution order of test cases; based on the test execution sequence, analyzing a high-value path that is not covered by a current test case, calculating an input condition triggering a specific path by using a preset symbolic execution algorithm, generating test input data satisfying multi-constraint conditions from the input condition, and establishing a mapping relationship between the current test case and the surviving variant according to a boundary value designed according to a mutation point of the surviving variant and an abnormal condition indicated in the visual analysis report, so that a new test case is generated based on the high-value path, the test input data, and the mapping relationship.

9. The method of claim 8, wherein, The scaling algorithm solving process is performed by the following steps, including: initializing a parameter matrix and a weight vector of the constraint optimization model, determining a scaling factor and a convergence threshold, establishing a hierarchical structure of recursive decomposition, and constructing a scaling calculation framework based on the parameter matrix, the weight vector, the scaling factor, the convergence threshold, and the hierarchical structure of recursive decomposition; based on the scaling calculation framework and the recursive scaling function, gradually reducing a problem size by using a preset dynamic programming algorithm, decomposing constraint conditions at each scaling level to generate a sub-problem set; for each sub-problem in the sub-problem set, converting the multi-constraint condition set into a penalty term of an objective function by using a preset Lagrange multiplier algorithm, calculating a gradient and a Hessian matrix of a Lagrange function, and solving a local optimal solution based on the penalty term, the gradient of the Lagrange function, and the Hessian matrix; mapping the local optimal solution back to an upper problem space through a scaling transformation, updating the scaling factor to perform cross-level solution space propagation of the local optimal solution. The scale level decomposition and the solution space propagation process are repeatedly performed until a preset convergence condition is met or a preset iteration number is reached, the optimal solutions of each level are combined, a global optimal test path scheme satisfying all the multiple constraint condition sets is output, and a constraint random path is obtained.

10. An apparatus for intelligent automation script based mutation testing, comprising: Comprise: A code analysis module configured to obtain original source code, runtime information, and version control data, extract statement execution order and branch dependency in the original source code using a context-aware syntax tree constructed by a specific language parser, generate a control flow graph and a data flow graph, and perform feature extraction on the control flow graph, the data flow graph, the runtime information, and the version control data to obtain multi-dimensional code features, wherein each node in the context-aware syntax tree carries context meta information; A variant generation module configured to perform code semantic analysis on the multi-dimensional code features using a preset large language model based on the multi-dimensional code features, identify potential defect types and corresponding mutation rules, predict the test efficiency of variants using a preset deep Q learning model, and generate to-be-processed variants conforming to the defect types based on the test efficiency and the mutation rules, wherein the test efficiency is used to evaluate the possibility of occurrence of defect problems related to the test case after the variants execute the preset test case; A test execution module configured to perform syntax checking and equivalence analysis on the to-be-processed variants to obtain effective variants, test the effective variants using the test case, and record the test execution results of each effective variant, wherein the test execution result is a survival state or a kill state; A result analysis module configured to calculate mutation test indicators and locate code weak points based on the test execution results, identify test blind areas from survival variants, and generate a visual analysis report containing test strategy optimization suggestions based on the mutation test indicators, the code weak points, and the test blind areas, wherein the survival variant indicates an effective variant with the survival state of the test execution result; A test case generation module configured to iteratively generate new test cases according to the current survival variants and the visual analysis report, and test the current survival variants using the new test cases. A code analysis module configured to obtain original source code, runtime information, and version control data, extract statement execution order and branch dependency in the original source code using a context-aware syntax tree constructed by a specific language parser, generate a control flow graph and a data flow graph, and perform feature extraction on the control flow graph, the data flow graph, the runtime information, and the version control data to obtain multi-dimensional code features, wherein each node in the context-aware syntax tree carries context meta information; A variant generation module configured to perform code semantic analysis on the multi-dimensional code features using a preset large language model based on the multi-dimensional code features, identify potential defect types and corresponding mutation rules, predict the test efficiency of variants using a preset deep Q learning model, and generate to-be-processed variants conforming to the defect types based on the test efficiency and the mutation rules, wherein the test efficiency is used to evaluate the possibility of occurrence of defect problems related to the test case after the variants execute the preset test case; A test execution module configured to perform syntax checking and equivalence analysis on the to-be-processed variants to obtain effective variants, test the effective variants using the test case, and record the test execution results of each effective variant, wherein the test execution result is a survival state or a kill state; A result analysis module configured to calculate mutation test indicators and locate code weak points based on the test execution results, identify test blind areas from survival variants, and generate a visual analysis report containing test strategy optimization suggestions based on the mutation test indicators, the code weak points, and the test blind areas, wherein the survival variant indicates an effective variant with the survival state of the test execution result; A test case generation module configured to iteratively generate new test cases according to the current survival variants and the visual analysis report, and test the current survival variants using the new test cases.

Images