Code change test influence analysis method and system based on multi-dimensional dependency analysis

Abstract

The application relates to the technical field of software testing and code change influence analysis, in particular to a code change test influence analysis method and system based on multidimensional dependence analysis, which adopts a layered architecture and comprises, from bottom to top, a code change detection layer, a multidimensional dependence analysis layer, a dependence graph construction and management layer, an influence propagation analysis layer and a test selection and optimization layer; code dependence relations are extracted through three-dimensional mixed analysis of source code syntax, compiled bytecode and program runtime; a multi-level call graph is adaptively constructed; a change influence boundary is determined through bidirectional slicing and risk propagation evaluation; a minimum test set is solved by using a weighted set covering algorithm; and test intelligent priority sorting is realized through a scoring model enhanced by machine learning; the application can significantly reduce the test set size under the premise of ensuring test safety, improve regression test efficiency and defect discovery speed, and adapt to continuous integration and deployment scenes of large Java projects and microservice architectures.

Description

Technical Field

[0001] This invention relates to the field of software testing and code change impact analysis technology, specifically to a code change testing impact analysis method and system based on multi-dimensional dependency analysis. Background Technology

[0002] Regression test selection is a critical activity in software maintenance, aiming to select a subset of tests affected by code changes from the existing test suite. This reduces testing costs while ensuring defect detection capabilities. Its core metrics include safety, accuracy, and efficiency. Safety refers to the selection of test cases that include all test cases that could potentially detect defects introduced by the changes. Accuracy means that the selected test cases are all genuinely affected by the changes. Efficiency means that the overhead of the selection process itself should be significantly less than the overhead of executing excluded test cases. Test impact analysis identifies the subset of tests affected by code changes by establishing a mapping relationship between code and tests. In the Java ecosystem, this is typically achieved using techniques such as bytecode analysis, call graph construction, and code coverage correlation. Bytecode analysis extracts call relationships between classes and methods by analyzing Java bytecode. Call graph construction generates static or dynamic call graphs to represent program dependencies. Code coverage correlation establishes a corresponding relationship between code coverage data during test execution and test cases. Dependency analysis, a core technique for regression test selection, primarily includes control flow analysis, data flow analysis, and slicing techniques. Control flow analysis analyzes the impact of code changes on execution paths based on control flow graphs. Data flow analysis determines data dependencies by analyzing variable definitions and usage chains. Slicing techniques identify sets of code statements affected by changes through program slicing. Currently, common Java regression test selection implementation schemes fall into two categories: one is a dynamic analysis scheme based on file dependencies, which establishes dependencies by monitoring file access during test execution and identifies changes by comparing file checksums in subsequent builds, thereby selecting test cases that depend on the changed files; the other uses static analysis techniques, which construct class-level dependency graphs by analyzing Java bytecode and identify test classes affected by changes based on these graphs, completing the selection without executing the tests.

[0003] Existing regression test selection techniques have several shortcomings in practical applications. Static analysis schemes cannot distinguish between actually reachable and unreachable execution paths, resulting in significant over-selection and the selection of a large number of unaffected test cases, wasting computational resources. Pure dynamic analysis schemes require monitoring file access during test execution, incurring additional runtime overhead, and must run the complete test suite on the first execution to collect dependency information, making implementation extremely costly in large projects. Furthermore, existing technologies lack adaptive call graph construction strategies, making it difficult to achieve an optimal balance between call graph complexity and impact on prediction accuracy. They are also mostly based on class-level or file-level granularity analysis, lacking fine-grained analysis capabilities at the method and statement levels. When only a few methods in a class are modified, class-level analysis may select all dependent test cases for that class, resulting in unnecessary test execution. In layered and microservice architectures, existing tools struggle to effectively analyze indirect dependencies generated by frameworks, as well as cross-service dependencies generated by message queues and remote procedure calls. Their cross-layer and cross-service dependency analysis capabilities are weak. Furthermore, existing technologies typically execute test cases in a fixed order after selection, lacking the ability to dynamically adjust priorities based on risk, business criticality, and historical defect density. This can lead to delayed execution of high-risk test cases, delaying defect discovery and making it difficult to adapt to the rapid feedback development requirements of continuous integration or continuous deployment environments.

[0004] Therefore, in view of the above situation, there is an urgent need to develop a code change test impact analysis method and system based on multi-dimensional dependency analysis to overcome the shortcomings in current practical applications. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for analyzing the impact of code change testing based on multi-dimensional dependency analysis, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The code change test impact analysis system based on multi-dimensional dependency analysis adopts a layered architecture, which includes, from bottom to top, a code change detection layer, a multi-dimensional dependency analysis layer, a dependency graph construction and management layer, an impact propagation analysis layer, and a test selection and optimization layer. Data is transmitted unidirectionally between each layer and supports a closed loop of result feedback. The code change detection layer is used to capture code change events, perform multi-granularity identification and feature extraction on changes, and output a standardized change feature vector. The multi-dimensional dependency analysis layer is used to dynamically select the combination of analysis paths based on change characteristics, extract code dependencies through multiple parallel analysis paths, and output the original dependency set. The dependency graph construction and management layer is used to adaptively construct a multi-level call graph based on change characteristics, and to incrementally update and version-store the call graph, outputting a structured call graph. The impact propagation analysis layer is used to perform bidirectional slicing analysis and risk propagation assessment on the multi-level call graph, identify cross-boundary dependencies, and determine the impact boundaries of code changes; The test selection and optimization layer is used to solve for the minimum test set based on the influence boundary, and to intelligently prioritize and schedule test cases, and output a test execution plan.

[0007] As a further aspect of the present invention: the code change detection layer includes a change detector, a multi-granularity change recognizer, and a change feature extractor; The change detector supports three triggering modes: incremental detection mode, full comparison mode, and real-time monitoring mode, to capture code change events. The multi-granularity change identifier performs four levels of granularity identification on the captured changes, from coarse to fine: package-level identification, class-level identification, method-level identification, and statement-level identification. For method-level and statement-level changes, they are further subdivided into signature changes, control flow changes, data flow changes, and exception handling changes. The change feature extractor extracts syntactic features, semantic features, dependency features, and historical features from the changed code to form the change feature vector.

[0008] As a further aspect of the present invention: the multi-dimensional dependency analysis layer includes a source code parser, a bytecode dependency extractor, a runtime dynamic monitor, and a differential processing strategy library; The multiple parallel analysis paths include source code syntax analysis path, compiled bytecode analysis path, and program runtime monitoring path; The differentiated processing strategy library stores a variety of analysis path combination strategies, which are used to dynamically match the optimal analysis path combination based on change characteristics and project characteristics; The multi-dimensional dependency analysis layer also supports two alternative implementation modes: pure static analysis mode and pure dynamic analysis mode, which are adapted to resource-constrained environments and scenarios with high security requirements, respectively.

[0009] As a further aspect of the present invention: the dependency graph construction and management layer includes an adaptive call graph construction engine, a multi-level call graph collaboration manager, an incremental update processor, and a versioned storage engine; The adaptive call graph construction engine dynamically selects a call graph construction strategy based on change characteristics, supporting three construction strategies: a lightweight analysis strategy based on class hierarchy, a fast type analysis strategy, and a dynamic call graph construction strategy. The multi-level call graph coordinator maintains call graphs at three levels: class-level call graph, method-level call graph, and statement-level call graph. The three levels are associated with each other through a mapping mechanism. The incremental update processor supports three incremental update granularities: node-level incremental, edge-level incremental, and propagation-level incremental, which are used to perform local updates only on the affected parts of the call graph when code changes occur.

[0010] As a further aspect of the present invention: the influence propagation analysis layer includes a two-way slice analyzer, a risk propagation assessor, and a cross-boundary propagation identifier; The bidirectional slice analyzer performs forward and backward slice analysis simultaneously and supports three propagation termination conditions: depth limit, boundary limit, and risk threshold limit. The risk propagation evaluator calculates the risk propagation coefficient for each propagation path and achieves intelligent propagation interception by combining the propagation attenuation effect and the propagation amplification effect; The cross-boundary propagation identifier identifies four types of cross-boundary dependencies: framework-level indirect dependencies, reflection-level indirect dependencies, cross-service dependencies, and interface contract change propagation.

[0011] As a further aspect of the present invention: the test selection and optimization layer includes a minimum test set selection engine, an intelligent priority sorting model, and a test scheduler executor; The minimum test set selection engine is based on the weighted set covering algorithm, which sequentially performs candidate set generation, redundancy elimination, weighted cover solution, security verification and overhead balance optimization to output the minimum test set that satisfies the security constraints. The security verification check determines whether the final selected test set covers the critical paths involving interface contracts, exception handling, and concurrency control. The intelligent priority ranking model uses a machine learning-enhanced multi-dimensional scoring mechanism to calculate the priority score of test cases, and supports online learning to continuously optimize the scoring results.

[0012] A code change test impact analysis method based on multi-dimensional dependency analysis includes the following steps: Step S1: Code Change Detection and Feature Extraction: Capture code change events, perform multi-granularity identification and feature extraction on the changes, and generate standardized change feature vectors; Step S2: Multi-dimensional dependency analysis: Dynamically select the combination of analysis paths based on the changed feature vector, extract code dependencies through multiple parallel analysis paths, and output the original dependency set; Step S3: Adaptive construction and updating of multi-level call graph: Adaptively construct a multi-level call graph based on the change characteristics, and incrementally update and version-store the call graph; Step S4: Two-way impact propagation and boundary determination: Perform two-way slicing analysis and risk propagation assessment on the multi-level call graph to identify cross-boundary dependencies and determine the impact boundary of code changes; Step S5: Test selection and optimization: Based on the influence boundary, solve for the minimum test set, and intelligently prioritize and schedule the test cases to output the test execution plan.

[0013] As a further aspect of the present invention: step S1 specifically includes: Step S11: Capture code change events using incremental detection mode, full comparison mode, or real-time monitoring mode; Step S12: Perform four-level granularity identification on changes: package level, class level, method level, and statement level. For method level and statement level changes, further subdivide them into signature changes, control flow changes, data flow changes, and exception handling changes. Step S13: Extract syntax features, semantic features, dependency features, and historical features from the changed code to generate the changed feature vector.

[0014] As a further aspect of the present invention: step S3 specifically includes: Step S31: Select the corresponding call graph construction strategy according to the change characteristics, construct and maintain the call graph at three levels: class level, method level and statement level, and maintain the association between each level through a mapping mechanism; Step S32: Update the call graph using an incremental update method, supporting three update granularities: node-level incremental, edge-level incremental, and propagation-level incremental. Only the affected parts of the call graph are locally updated. Step S33: Version the call graph and maintain the isolation of call graphs for different versions and branches.

[0015] As a further aspect of the present invention: step S4 specifically includes: Step S41: Simultaneously perform forward slice and backward slice analysis, calculate the risk propagation coefficient along the call path, and achieve intelligent propagation truncation by combining propagation attenuation effect and propagation amplification effect; Step S42: Identify framework-level indirect dependencies, reflection-level indirect dependencies, cross-service dependencies, and interface contract change propagation to determine the impact boundaries of code changes.

[0016] Compared with the prior art, the beneficial effects of the present invention are: Through multi-dimensional dependency analysis and fine-grained impact propagation algorithms, it can accurately identify test cases that are truly affected by code changes, avoid the over-selection problem of existing static analysis techniques, and achieve an average reduction of more than 50% in test cases. In some scenarios, the reduction rate can reach more than 80%, shortening the regression testing time from several hours to minutes, and significantly improving the feedback speed of continuous integration or continuous deployment pipelines. By constructing an adaptive call graph and implementing a risk propagation assessment mechanism, accuracy can be improved while ensuring security. This can reduce the gap between defect detection capability and full-scale testing to an acceptable range of less than 3%, while avoiding security violations of existing technologies. The adaptive dependency graph construction mechanism can dynamically select analysis strategies based on change characteristics, avoiding the high overhead of complex call graph construction; a lightweight analysis strategy is adopted for simple changes that do not involve reflection or dynamic proxies, and high-cost dynamic analysis is only enabled for complex scenarios. This on-demand analysis strategy can reduce dependency analysis overhead by more than 40%. The machine learning-enhanced priority ranking model can dynamically adjust the test execution order based on historical data and real-time changing features. Compared with traditional heuristic methods, the intelligent test priority ranking can improve the average defect detection rate by 33.9%, enabling critical defects to be discovered in the early stages of testing and reducing defect repair costs. In response to the characteristics of commonly used development frameworks, microservice architectures, and cloud-native technologies in modern Java applications, a cross-layer dependency analysis and contract change detection mechanism was designed, filling the analysis gaps in existing tools in handling dependency injection, aspect-oriented programming, and inter-service calls. The incremental update mechanism and the continuous learning capability of the machine learning model enable the system to continuously optimize the analysis accuracy as the project evolves; by continuously collecting test execution results and defect data, the system can automatically adjust the dependency analysis strategy and priority weights to achieve continuous improvement in analysis results. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the layered architecture of the code change test impact analysis system based on multi-dimensional dependency analysis in an embodiment of the present invention.

[0018] Figure 2 This is a schematic diagram of the minimum test set selection process in an embodiment of the present invention. Detailed Implementation

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

[0020] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.

[0021] Please see Figure 1 and Figure 2 The code change test impact analysis system based on multi-dimensional dependency analysis provided in this embodiment of the invention also provides corresponding analysis and minimum test set selection methods. It is suitable for large-scale software projects developed in Java language, and is especially suitable for regression test selection scenarios in continuous integration or continuous deployment environments. It can significantly reduce the size of the test set and improve test feedback efficiency while ensuring test security.

[0022] I. Code Change Test Impact Analysis System Based on Multi-Dimensional Dependency Analysis This system adopts a layered architecture design, which, from bottom to top, includes a code change detection layer, a multi-dimensional dependency analysis layer, a dependency graph construction and management layer, an impact propagation analysis layer, and a test selection and optimization layer. Data is transferred unidirectionally between each layer and supports a closed loop of result feedback. The specific structure is as follows: 1. Code Change Detection Layer The code change detection layer is located at the bottom layer of the system and serves as the system's input point. It is responsible for real-time detection of change events in the code repository, performing multi-granularity identification and feature extraction of changes, and outputting standardized change feature vectors to the upper layers. This layer includes three functional units: a change detector, a multi-granularity change recognizer, and a change feature extractor.

[0023] The change detector is used to capture code change events and supports three trigger modes: Incremental detection mode: Based on the version differences of the version control system, it obtains a list of files that differ from the baseline version in the current commit, which is suitable for frequent code commit scenarios in daily development; Full comparison mode: When the system runs for the first time or the baseline is rebuilt, the overall state of the complete codebase is compared. It is suitable for scenarios such as system initialization and branch switching. Real-time monitoring mode: Captures change events in real time through file system monitoring or network hook mechanisms, suitable for continuous integration pipeline scenarios that require immediate feedback.

[0024] The change detector can be triggered and differences can be obtained by interfacing with the hook interface of common version control systems such as Git and SVN.

[0025] The multi-granularity change identifier performs four levels of granularity identification on the captured changes, from coarse to fine: The first level is package-level identification, which identifies newly added, deleted, or modified package structures; The second level is class-level identification, which identifies newly added, deleted, or modified class files; The third level is method-level identification, which identifies methods that are added, deleted, or modified within a class. The fourth level is statement-level recognition, which precisely locates the specific statement block that is modified within the method.

[0026] For method-level and statement-level changes, they are further subdivided into four types of changes: signature changes, i.e., changes to the method name, parameter list, and return type; control flow changes, i.e., changes to conditional branching structures and loop structures; data flow changes, i.e., changes to variable definition, assignment, and usage chains; and exception handling changes, i.e., changes to exception catching blocks and exception throwing declarations.

[0027] The change feature extractor extracts four key features from the changed code to form a change feature vector: Syntactic features: including changes in the types of abstract syntax tree nodes involved in the changes, code nesting depth, and the amount of change in cyclomatic complexity; Semantic features: Identify whether the changes involve key semantic patterns such as null pointer checks, resource shutdown, and concurrency control; Dependency characteristics: Determine whether the change involves elements with a propagation effect, such as interface definitions, abstract classes, generic parameters, and annotations; Historical characteristics: Statistics on the historical defect density and historical change frequency of this document or method.

[0028] This layer provides a precise input basis for upper-level analysis through multi-granularity change identification and multi-dimensional feature extraction, avoiding the problem of subsequent over-analysis caused by excessively coarse change granularity, and providing a decision basis for subsequent adaptive strategy selection.

[0029] 2. Multi-dimensional Dependency Analysis Layer The multi-dimensional dependency analysis layer is the core analysis module of the system. It constructs a comprehensive view of code dependencies through three parallel analysis paths: source code syntax analysis, post-compiled bytecode analysis, and runtime monitoring. Simultaneously, it configures a differentiated processing strategy library to dynamically select the optimal combination of analysis paths based on change characteristics. This layer includes a source code syntax analyzer, a bytecode dependency extractor, a runtime dynamic monitor, and a differentiated processing strategy library.

[0030] The source code parser performs dependency extraction based on an abstract syntax tree, covering three analysis levels: Class level: Extract inheritance relationships, implementation relationships, and annotation dependencies between classes; Member level: Extract field type dependencies and method signature dependencies, including parameter types, return value types, and exception types; Call levels: Extract method call expressions, constructor calls, and static method calls.

[0031] For projects developed using a framework, additional framework-specific dependency patterns are identified: dependency injection declarations are identified through specific annotations, framework-managed objects are identified through component scanning annotations, and exposed service interfaces are identified through interface contract definition annotations.

[0032] The source code parser can build an abstract syntax tree and perform dependency extraction based on general Java syntax parsing tools such as Eclipse JDT and javac.

[0033] The bytecode dependency extractor analyzes class files during the post-compilation phase to supplement dependency information that cannot be obtained through source code analysis. By analyzing bytecode instructions, the actual call target can be determined, thus resolving the problem of polymorphic calls that cannot be determined in the source code. Identify the bridge methods generated by the compiler and handle special dependency situations caused by generic type erasure; Identify compiler-generated synthesized methods and implicit references from inner classes to outer classes; Analyze class references, method references, and field references in the constant pool to capture dependencies that are not visible at the source code level.

[0034] The bytecode dependency extractor can perform class file parsing and dependency extraction based on general bytecode manipulation tools such as ASM and Javassist.

[0035] The runtime dynamic monitor uses Java proxy technology to perform bytecode instrumentation when the virtual machine loads classes, and collects dynamic dependency information during test execution: it records the actual method call chain that occurs during test execution, captures calls initiated through reflection, identifies the actual call target of dynamic proxies, records the sequence of classes loaded by the class loader and the source class that triggers the loading, and records the access paths of configuration files and static resource files.

[0036] The runtime dynamic monitor described above implements bytecode instrumentation based on the Java Agent mechanism, which is a well-known runtime program monitoring method in the field.

[0037] The differentiated processing strategy library stores multiple analysis path combination strategies, dynamically matching the optimal strategy based on change characteristics and project characteristics: For ordinary business logic changes, only two paths are enabled: source code syntax analysis and bytecode dependency extraction, without introducing runtime overhead. For changes involving reflection or dynamic proxies, all three paths are enabled, and the actual call target is determined based on runtime information; For changes to interfaces or abstract classes, enable source code syntax analysis and bytecode dependency extraction to perform a full analysis of the dependencies of all implementation classes; For framework configuration changes, enable source code syntax analysis and runtime dynamic monitoring to identify the actual injected object instances; For microservice interface contract changes, all three paths are enabled to analyze cross-service consumer dependencies.

[0038] In addition to the multi-dimensional hybrid analysis mode mentioned above, this layer also supports two alternative implementation modes to adapt to different project scenario requirements: (1) Pure static analysis mode For resource-constrained environments or environments where runtime instrumentation is not permitted, a purely static analysis mode is adopted: dependencies are built solely based on source code syntax analysis and bytecode dependency extraction, and conservative dependency assumptions are made, such as the assumption that reflection calls may access arbitrary classes; some accuracy is sacrificed in exchange for zero runtime overhead.

[0039] (2) Pure dynamic analysis mode For scenarios with extremely high security requirements, a purely dynamic analysis mode is adopted: static analysis paths are disabled, and only the precise dependency relationships collected by runtime dynamic monitoring are relied upon; the first execution requires a full run of the test to establish a baseline, and subsequent selections are based on the actual execution trajectory to ensure test security.

[0040] This layer addresses the issues of insufficient precision in single static analysis and excessive overhead in single dynamic analysis through complementary analysis across three dimensions: syntax, bytecode, and runtime. Simultaneously, it achieves on-demand analysis through a differentiated strategy, controlling overall analysis overhead while ensuring comprehensive dependency extraction.

[0041] 3. Dependency Graph Construction and Management Layer The dependency graph construction and management layer is responsible for transforming the raw dependency relationships output by the multi-dimensional dependency analysis layer into a structured, multi-level, incrementally updatable call graph, and supporting versioned management. This layer includes an adaptive call graph construction engine, a multi-level call graph collaboration manager, an incremental update processor, and a versioned storage engine.

[0042] The adaptive call graph building engine dynamically selects a call graph building strategy based on changing characteristics, supporting three building strategies in total: A lightweight analysis strategy based on class hierarchy: suitable for scenarios where changes do not involve dynamic binding, reflection, or dynamic proxy, with low time complexity; Quick type analysis strategy: suitable for scenarios where changes involve polymorphic calls but the specific type can be determined through the class instantiation point; Dynamic call graph construction strategy: suitable for changes involving mechanisms that cannot be statically resolved, such as reflection, dynamic proxy, and dependency injection, and obtains accurate call relationships through runtime monitoring.

[0043] The strategy selection logic is as follows: if the change involves reflection calls, dynamic proxies, or dependency injection frameworks, then the dynamic call graph construction strategy is selected; if the change involves polymorphic calls to interfaces or abstract classes, then the fast type analysis strategy is selected; for other simple changes, the lightweight analysis strategy based on class hierarchy is selected.

[0044] The multi-level call graph collaboration manager maintains a call graph at three levels simultaneously and supports level switching and join queries during analysis. The first layer is a class-level call graph: nodes are classes, and edges are inter-class dependencies, including inheritance, implementation, calling, and field access, used for quick initial screening; The second layer is a method-level call graph: nodes are methods or constructors, and edges are method call relationships, used for precise impact analysis; The third layer is a statement-level call graph: nodes are statement blocks, and edges represent the relationships between control flow and data flow, used for fine-grained slice analysis.

[0045] The three levels are linked through a mapping mechanism: expansion from class level to method level is achieved by associating class nodes with all their method nodes; expansion from method level to statement level is achieved by associating method entry nodes with their control flow graphs; at the same time, a reverse index from method signature to class fully qualified name is established to support fast location.

[0046] The incremental update processor performs only partial updates to the affected parts of the call graph when code changes occur, rather than a full rebuild, and supports three incremental update granularities: Node-level incremental updates: When a class or method is added, deleted, or modified, only the corresponding node and its directly associated edges are updated; Edge-level incremental: When dependencies change, newly added and deleted edges are identified by comparing dependency differences; Propagation-level increment: When a change has a propagation effect, it automatically triggers cascading updates of downstream dependent nodes.

[0047] The specific process of incremental update is as follows: First, receive the set of changed nodes output by the change detection layer; then locate the corresponding node in the existing call graph; next, perform local dependency reanalysis on the changed node; then update the node attributes and associated edges; finally, mark the affected connected subgraph and notify the impact propagation analysis layer for subsequent processing.

[0048] The versioned storage engine uses a graph database to persist the call graph and supports multi-version management: a complete snapshot of the call graph is saved after each code commit, supporting historical version backtracking; only the difference data is stored between adjacent versions, reducing storage overhead; it supports call graph isolation at the version control branch level to avoid confusion of analysis results between branches; hot call graph substructures are cached in memory to accelerate frequent queries.

[0049] The versioned storage engine can use general graph databases such as Neo4j and NebulaGraph to achieve persistent storage and efficient querying of the call graph.

[0050] This layer balances call graph accuracy and build overhead through an adaptive build strategy, meets analysis needs at different granularities through a multi-level call graph, and significantly reduces the resource consumption of repeated builds and improves system operating efficiency through incremental updates and version management.

[0051] 4. Impact Propagation Analysis Layer The impact propagation analysis layer performs propagation analysis of the impact of changes on a multi-level call graph, determining the complete impact boundaries of code changes and providing precise scope input for test selection. This layer includes a bidirectional slice analyzer, a risk propagation assessor, and a cross-boundary propagation identifyer.

[0052] The bidirectional slice analyzer performs both forward and backward slice analysis simultaneously: Forward slice: Starting from the changed node, traverse forward along the edges of the call graph to identify all downstream nodes that may be affected by the change, i.e., the code that is directly or indirectly called by the changed code. Backward slicing: Starting from the changed node, traverse backward along the edges of the call graph to identify all upstream nodes that may affect the execution path of the change, i.e., the code that calls the changed code.

[0053] Slice analysis supports three termination conditions: first, depth limit, which stops traversal when the propagation depth exceeds a preset threshold; second, boundary limit, which stops when a predefined system boundary is encountered, such as a core library or a third-party library; and third, risk threshold limit, which stops traversal when the cumulative risk coefficient on the propagation path is lower than a truncation threshold.

[0054] The risk propagation assessor calculates the risk propagation coefficient for each propagation path, enabling intelligent propagation interception. Base risk value: An initial value is assigned based on the characteristics of the change. Changes involving null pointers, concurrency control, and resource management are assigned a higher base risk value. Propagation attenuation coefficient: For each layer of the call relationship, the risk value is multiplied by an attenuation coefficient less than 1; Path cumulative risk: For the same node reached by multiple propagation paths, the maximum path risk value is taken as the risk value of that node; Cut-off decision: When the risk value of a node is lower than the cut-off threshold, stop propagating along that path.

[0055] The calculation of the risk propagation coefficient also takes into account the amplification effect on the propagation path: when the propagation passes through high-risk propagation points such as interfaces and abstract classes, the risk value is multiplied by an amplification factor greater than 1 to adapt to the wide cascading impact characteristics of such changes.

[0056] The cross-boundary propagation identifier specifically handles indirect dependencies that cross module boundaries and service boundaries: Framework-level indirect dependency identification: Identifies indirect calling relationships generated through dependency injection containers, aspect-oriented programming proxies, and event listening mechanisms; Reflection-level indirect dependency: Based on runtime monitoring data, establish explicit edges between the reflection call source and the reflection target; Cross-service dependency: By analyzing remote call interfaces, interface definitions, and the relationship between message queue producers and consumers, an inter-service call graph is established; Interface contract change propagation: When the interface method signature changes, the cascading effects on all implementing classes and consumers are automatically identified.

[0057] This layer achieves complete coverage of the impact scope through bidirectional slicing, intelligent truncation to avoid over-propagation through risk propagation assessment, and solves the problem of existing impact analysis technologies either being overly conservative or omitting indirect dependencies by identifying indirect dependencies across boundaries and covering the framework.

[0058] 5. Test Selection and Optimization Layer The test selection and optimization layer is located at the top layer of the system. It receives the impact boundary output from the impact propagation analysis layer, performs minimum test set selection and intelligent priority ranking, and outputs the final test execution plan. This layer includes the minimum test set selection engine, the intelligent priority ranking model, and the test scheduler executor.

[0059] The minimum test set selection engine is based on a weighted set coverage algorithm, which minimizes the test set size while ensuring safety constraints. The processing flow is as follows: Figure 2 As shown, it is divided into five steps: Candidate set generation: Based on the mapping relationship between code and tests, test cases that cover at least one code entity within the influence boundary are selected to form a candidate set; Redundancy elimination: For test cases whose coverage set is completely contained in other test cases, mark them as redundant candidates and remove them; Weighted coverage solution: A greedy algorithm is used to iteratively select the test cases with the greatest coverage gain per unit cost, that is, each time the test cases that can cover the most uncovered code entities with the least execution cost are selected; Security verification: Check whether the final selected test suite covers all critical paths, including those involving interface contracts, exception handling, and concurrency control. If there are any uncovered paths, force the addition of relevant test cases. Cost balancing optimization: Compare the cost of test selection with the cost of executing excluded test cases. If the cost of test selection is too high, appropriately expand the selection range to reduce the computational cost in the selection process.

[0060] The greedy algorithm for solving the weighted set cover is a well-known combinatorial optimization algorithm in this field.

[0061] The intelligent priority ranking model employs a machine learning-enhanced multi-dimensional scoring mechanism to calculate priority scores for selected test cases.

[0062] The feature vector contains five dimensions: Change relevance: This includes the shortest path length from the test case to the change node, and the number of changed methods or statements directly covered by the test case; Historical defect density: This includes the number of defects found in the history of this test case, as well as the historical defect rate of the test coverage code. The historical defect data is weighted by time decay, with recently discovered defects having a higher weight. Business criticality: This includes the importance level of related business modules and the interface exposure level, with higher weight given to interfaces exposed to the outside. Cost of failure: Assess the business impact of failure of related functions, giving higher weight to high-cost functions such as financial transactions and security authentication; Execution cost: This includes historical execution time and resource consumption. Prioritize short tests to obtain feedback quickly.

[0063] The scoring model employs either a gradient boosting decision tree or a lightweight neural network. Training data is derived from historical test execution results, defect reports, and code change records, with labels indicating whether a test case detected a defect. The model supports online learning, feeding the actual results back to the model after each test execution and updating feature weights through online gradient descent. For new test cases, a rule-based heuristic scoring method is used, switching to model scoring after accumulating sufficient data. Priority scores are obtained through weighted summation and activation function mapping; higher scores indicate that the test case should be executed with higher priority.

[0064] The test scheduler generates the optimal test execution sequence based on priority scores and system resource status. Prioritize rapid feedback: Place high-priority test cases with short execution times at the front of the queue to ensure that they are discovered and reported first. Dependency-aware parallel scheduling: Identifies dependencies between test cases and avoids conflicts in parallel execution; Resource adaptation: Dynamically adjusts the degree of parallelism based on the available resources in the current continuous integration environment; Timeout protection: Set a dynamic timeout threshold for each test case. If the timeout threshold is exceeded, the test will be forcibly terminated and marked as an exception.

[0065] This layer minimizes the test set size while ensuring security through a weighted set coverage algorithm, thereby reducing test execution costs; it prioritizes high-risk tests through machine learning-enhanced priority ranking, improving defect discovery efficiency; and it fully utilizes system resources through adaptive scheduling, ensuring the stability and efficiency of test execution.

[0066] The overall data flow of the system is as follows: After the code change detection layer captures a change, it passes the change feature vector to the multi-dimensional dependency analysis layer; after the multi-dimensional dependency analysis layer completes dependency extraction, it passes the original dependency relationship to the dependency graph construction and management layer; after the dependency graph construction and management layer completes the call graph construction and update, it passes the graph structure data to the impact propagation analysis layer; after the impact propagation analysis layer completes the impact boundary calculation, it passes the set of affected code entities to the test selection and optimization layer; the test selection and optimization layer outputs the final test execution plan and feeds the results back to the system after the test execution is completed, for continuous model learning and dependency graph correction and optimization.

[0067] II. Code Change Test Impact Analysis and Minimum Test Set Selection Method Based on Multi-Dimensional Dependency Analysis This method is based on the above system and includes the following steps: (1) Code change detection and feature extraction When a code commit or merge request triggers a change event, the code change information is obtained through the version control system, and the corresponding detection mode is used to complete the change capture; the change is identified at four levels of granularity: package level, class level, method level, and statement level, and the change type is further subdivided; the syntax features, semantic features, dependency features, and historical features of the change are extracted to generate a standardized change feature vector.

[0068] This step precisely identifies the location and type of change, providing refined input for subsequent analysis.

[0069] (2) Multidimensional dependency analysis Based on the differentiated processing strategy of the change feature vector, the corresponding combination of analysis paths is selected; static structural dependencies are extracted through source code syntax analysis, polymorphism and implicit dependencies are supplemented through bytecode analysis, and dynamic dependencies such as reflection and dynamic proxies are obtained through runtime monitoring, and finally the complete set of original dependency relationships is output.

[0070] This step ensures the comprehensiveness of dependencies through multi-dimensional complementary analysis, while controlling analysis costs by selecting strategies as needed.

[0071] (3) Adaptive construction and updating of multi-level call graph Select the corresponding call graph construction strategy based on the change characteristics, and build or incrementally update the call graph at the class level, method level, and statement level based on the original dependency relationship; store the call graph in a versioned manner to maintain the isolation of call graphs of different versions and branches.

[0072] This step enables efficient construction and maintenance of the call graph, balancing analysis accuracy and resource overhead.

[0073] (4) Two-way influence propagation and boundary determination Forward and backward slicing are performed on the multi-level call graph, and the risk propagation coefficient is calculated along the call path. Propagation stops when the risk value is lower than the truncation threshold or reaches the depth / boundary limit. At the same time, cross-boundary effects such as framework indirect dependencies, reflection dependencies, and cross-service dependencies are identified, and the complete code change impact boundary is finally determined.

[0074] This step precisely defines the scope of the change's impact, avoiding both redundancy caused by excessive propagation and security risks caused by overlooking indirect dependencies.

[0075] (5) Minimum test set selection A test candidate set is generated based on the code-test mapping relationship, and redundant test cases are eliminated through redundancy elimination. A weighted set coverage greedy algorithm is used to solve for the minimum test set. Security verification ensures full coverage of the critical path. The selection granularity is adjusted through cost balancing optimization, and the minimum test set that meets the security constraints is output.

[0076] This step minimizes the size of the test set and reduces test execution costs without omitting any defect detection capabilities.

[0077] (6) Test priority sorting and scheduling Five features of test cases are extracted: change relevance, historical defect density, business criticality, failure cost, and execution cost. A trained scoring model is used to calculate the priority score for each test case. Based on the priority score and system resource status, a test execution plan including execution order and parallel strategies is generated and output. After test execution, the results are fed back to the scoring model for online learning and optimization.

[0078] This step prioritizes the execution of high-risk test cases, accelerates the discovery of critical defects, and improves test feedback efficiency.

[0079] It should be noted that, in this invention, although the specification describes the embodiments, not every embodiment contains only one independent technical solution. This way of describing the specification is only for clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A code change test impact analysis system based on multi-dimensional dependency analysis, characterized in that, The architecture is layered, consisting of a code change detection layer, a multi-dimensional dependency analysis layer, a dependency graph construction and management layer, an impact propagation analysis layer, and a test selection and optimization layer, from bottom to top. Data is transferred unidirectionally between each layer and a closed loop of result feedback is supported. The code change detection layer is used to capture code change events, perform multi-granularity identification and feature extraction on changes, and output a standardized change feature vector. The multi-dimensional dependency analysis layer is used to dynamically select the combination of analysis paths based on change characteristics, extract code dependencies through multiple parallel analysis paths, and output the original dependency set. The dependency graph construction and management layer is used to adaptively construct a multi-level call graph based on change characteristics, and to incrementally update and version-store the call graph, outputting a structured call graph. The impact propagation analysis layer is used to perform bidirectional slicing analysis and risk propagation assessment on the multi-level call graph, identify cross-boundary dependencies, and determine the impact boundaries of code changes; The test selection and optimization layer is used to solve for the minimum test set based on the influence boundary, and to intelligently prioritize and schedule test cases, and output a test execution plan.

2. The code change test impact analysis system based on multi-dimensional dependency analysis according to claim 1, characterized in that, The code change detection layer includes a change detector, a multi-granularity change recognizer, and a change feature extractor; The change detector supports three triggering modes: incremental detection mode, full comparison mode, and real-time monitoring mode, to capture code change events. The multi-granularity change identifier performs four levels of granularity identification on the captured changes, from coarse to fine: package-level identification, class-level identification, method-level identification, and statement-level identification. For method-level and statement-level changes, they are further subdivided into signature changes, control flow changes, data flow changes, and exception handling changes. The change feature extractor extracts syntactic features, semantic features, dependency features, and historical features from the changed code to form the change feature vector.

3. The code change test impact analysis system based on multi-dimensional dependency analysis according to claim 1, characterized in that, The multi-dimensional dependency analysis layer includes a source code parser, a bytecode dependency extractor, a runtime dynamic monitor, and a differential processing strategy library. The multiple parallel analysis paths include source code syntax analysis path, compiled bytecode analysis path, and program runtime monitoring path; The differentiated processing strategy library stores a variety of analysis path combination strategies, which are used to dynamically match the optimal analysis path combination based on change characteristics and project characteristics; The multi-dimensional dependency analysis layer also supports two alternative implementation modes: pure static analysis mode and pure dynamic analysis mode, which are adapted to resource-constrained environments and scenarios with high security requirements, respectively.

4. The code change test impact analysis system based on multi-dimensional dependency analysis according to claim 1, characterized in that, The dependency graph construction and management layer includes an adaptive call graph construction engine, a multi-level call graph collaboration manager, an incremental update processor, and a versioned storage engine. The adaptive call graph construction engine dynamically selects a call graph construction strategy based on change characteristics, supporting three construction strategies: a lightweight analysis strategy based on class hierarchy, a fast type analysis strategy, and a dynamic call graph construction strategy. The multi-level call graph coordinator maintains call graphs at three levels: class-level call graph, method-level call graph, and statement-level call graph. The three levels are associated with each other through a mapping mechanism. The incremental update processor supports three incremental update granularities: node-level incremental, edge-level incremental, and propagation-level incremental, which are used to perform local updates only on the affected parts of the call graph when code changes occur.

5. The code change test impact analysis system based on multi-dimensional dependency analysis according to claim 1, characterized in that, The impact propagation analysis layer includes a two-way slice analyzer, a risk propagation assessor, and a cross-border propagation identifier; The bidirectional slice analyzer performs forward and backward slice analysis simultaneously and supports three propagation termination conditions: depth limit, boundary limit, and risk threshold limit. The risk propagation evaluator calculates the risk propagation coefficient for each propagation path and achieves intelligent propagation cutoff by combining the propagation attenuation effect and the propagation amplification effect; The cross-boundary propagation identifier identifies four types of cross-boundary dependencies: framework-level indirect dependencies, reflection-level indirect dependencies, cross-service dependencies, and interface contract change propagation.

6. The code change test impact analysis system based on multi-dimensional dependency analysis according to claim 1, characterized in that, The test selection and optimization layer includes a minimum test set selection engine, an intelligent priority sorting model, and a test scheduler executor. The minimum test set selection engine is based on the weighted set covering algorithm, which sequentially performs candidate set generation, redundancy elimination, weighted cover solution, security verification and overhead balance optimization to output the minimum test set that satisfies the security constraints. The security verification check determines whether the final selected test set covers the critical paths involving interface contracts, exception handling, and concurrency control. The intelligent priority ranking model uses a machine learning-enhanced multi-dimensional scoring mechanism to calculate the priority score of test cases, and supports online learning to continuously optimize the scoring results.

7. A code change test impact analysis method based on multi-dimensional dependency analysis, characterized in that, Includes the following steps: Step S1: Code Change Detection and Feature Extraction: Capture code change events, perform multi-granularity identification and feature extraction on the changes, and generate standardized change feature vectors; Step S2: Multi-dimensional dependency analysis: Dynamically select the combination of analysis paths based on the changed feature vector, extract code dependencies through multiple parallel analysis paths, and output the original dependency set; Step S3: Adaptive construction and updating of multi-level call graph: Adaptively construct a multi-level call graph based on the change characteristics, and incrementally update and version-store the call graph; Step S4: Two-way impact propagation and boundary determination: Perform two-way slicing analysis and risk propagation assessment on the multi-level call graph to identify cross-boundary dependencies and determine the impact boundary of code changes; Step S5: Test selection and optimization: Based on the influence boundary, solve for the minimum test set, and intelligently prioritize and schedule the test cases to output the test execution plan.

8. The code change test impact analysis method based on multi-dimensional dependency analysis according to claim 7, characterized in that, Step S1 specifically includes: Step S11: Capture code change events using incremental detection mode, full comparison mode, or real-time monitoring mode; Step S12: Perform four-level granularity identification on changes: package level, class level, method level, and statement level. For method level and statement level changes, further subdivide them into signature changes, control flow changes, data flow changes, and exception handling changes. Step S13: Extract syntax features, semantic features, dependency features, and historical features from the changed code to generate the changed feature vector.

9. The code change test impact analysis method based on multi-dimensional dependency analysis according to claim 7, characterized in that, Step S3 specifically includes: Step S31: Select the corresponding call graph construction strategy according to the change characteristics, construct and maintain the call graph at three levels: class level, method level and statement level, and maintain the association between each level through a mapping mechanism; Step S32: Update the call graph using an incremental update method, supporting three update granularities: node-level incremental, edge-level incremental, and propagation-level incremental. Only the affected parts of the call graph are locally updated. Step S33: Version the call graph and maintain the isolation of call graphs for different versions and branches.

10. The code change test impact analysis method based on multi-dimensional dependency analysis according to claim 7, characterized in that, Step S4 specifically includes: Step S41: Simultaneously perform forward slice and backward slice analysis, calculate the risk propagation coefficient along the call path, and achieve intelligent propagation truncation by combining propagation attenuation effect and propagation amplification effect; Step S42: Identify framework-level indirect dependencies, reflection-level indirect dependencies, cross-service dependencies, and interface contract change propagation to determine the impact boundaries of code changes.

Images