A source code analysis-based test range accurate positioning method and system

Abstract

This invention discloses a method and system for precise test scope localization based on source code analysis. By statically analyzing source code changes, a call relationship model is constructed, and execution path and coverage data are collected during program runtime. The results of dynamic and static analysis are then fused to calculate the true impact range and determine the set of test cases requiring priority execution. The system supports defect localization, performance monitoring, call chain tracing, and test report generation, achieving end-to-end quality analysis from code changes to test feedback. This invention improves the accuracy and execution efficiency of regression testing, reduces test resource consumption, and is suitable for automated test optimization in continuous integration environments.

Description

Technical Field

[0001] This invention relates to the field of software testing and quality assurance technology, and in particular to a method and system for accurately locating the testing scope around the source code. Background Technology

[0002] Currently, in the field of software testing and quality assurance, although various source code analysis or runtime monitoring techniques have been applied to test scope identification, coverage assessment, performance analysis, and defect localization, these techniques generally suffer from fragmented functionality, disjointed tools, and limited analytical dimensions. There are currently no mature commercial products or publicly available technical solutions that can use source code as the core, integrate static structure analysis and dynamic execution tracing, accurately pinpoint the scope of test impact starting from code changes, and simultaneously provide a closed-loop support for the entire testing chain, including coverage statistics, performance bottleneck analysis, call chain backtracking, and defect root cause prediction.

[0003] Current practices often rely on multiple independent tools working together, lacking a unified data model and linkage mechanism, which makes it difficult to meet the comprehensive requirements of modern agile development and continuous integration environments for testing efficiency, accuracy and automation.

[0004] The following are some representative technical paths and their typical implementation methods: A method for identifying the scope of influence based on static dependency analysis Some R&D collaboration platforms construct function call graphs or module dependency matrices by parsing the syntax structure of source code. After code submission, they automatically identify the direct callers of the modified functions and recommend related test cases to be executed accordingly.

[0005] Regression Test Selection Mechanism Based on Coverage Mapping Some systems record the specific classes, methods, or lines of code covered during test case execution, and then select test cases that previously covered the changed areas for re-execution when the source code changes.

[0006] A call chain visualization system based on distributed tracing In a microservice architecture, the cross-service call path of requests can be collected through probes or SDK instrumentation to form a complete execution trajectory, which can be used for call chain backtracking and performance bottleneck analysis.

[0007] Defect localization algorithm based on execution spectrum By leveraging the execution differences between failed and successful tests, a suspicion score is calculated for each line of code, thereby locating potentially defective code areas.

[0008] Automated quality feedback mechanism in CI / CD pipeline Mainstream continuous integration platforms automatically trigger unit tests, static analysis, and coverage checks after code is pushed, and then feed the results back to the code review interface.

[0009] However, while existing technologies can improve testing efficiency in certain aspects, they lack a unified mechanism for integrating static analysis and dynamic execution. They cannot track execution paths in real time and dynamically update the scope of impact, nor have they formed an integrated framework covering test management, coverage, performance, call chains, and defect analysis. Summary of the Invention

[0010] To address the problems existing in the prior art, this invention aims to provide a method and system for precise test range localization based on source code analysis, in order to solve the following technical problems: How to use source code as a unified anchor point, integrate static structure analysis and dynamic execution data, and build an impact propagation model for code changes; How to track code execution path in real time during program execution and dynamically associate test cases with affected code areas; How to establish an integrated analysis framework for coverage test management, coverage statistics, performance analysis, call chain backtracking, and defect localization; How to improve the granularity and accuracy of test range identification to avoid wasting test resources or missing risks due to reliance on misjudgments.

[0011] To address the aforementioned technical problems, this invention provides a method and system for accurately locating the test range based on source code analysis.

[0012] This system uses source code as a unified analysis anchor. Through static code parsing, dynamic execution monitoring, and multi-dimensional data fusion analysis, it can accurately identify the scope of impact of code changes and determine the scope of test cases that need to be executed.

[0013] This system comprises four subsystems: a static analysis subsystem, a dynamic monitoring subsystem, an analysis engine subsystem, and a support management subsystem. These subsystems interact through a unified data model, and their connections are as follows.

[0014] (1) Static analysis subsystem The static analysis subsystem includes a source code parsing module, a static inspection engine, a problem list generator, a defect transformation module, and an impact propagation modeling module.

[0015] The source code parsing module retrieves code change information from the code repository and performs syntax parsing on the changed code. When a developer commits code to the code repository, the source code parsing module listens for the commit event via a webhook and calls the Git interface to obtain the code differences corresponding to this commit. The source code parsing module uses an abstract syntax tree parser to parse the source code files, generating an abstract syntax tree structure, and further constructs a control flow graph (CFG) and a variable dependency chain (DU-Chain).

[0016] The parsed syntax structure information is passed to the static analysis engine. The static analysis engine scans the source code according to a pre-defined rule base to identify potential security, performance, and coding style issues. The scan results are sent to the issue list generator, which organizes the scan results into a structured issue list. Each issue record includes the file path, line number, issue rule number, severity level, and suggested fixes. The generated issue list is then passed to the defect conversion module. The defect conversion module determines whether a defect record needs to be generated based on the issue severity level. When an issue with a severity level of "Error" is detected, a defect entry is created in the external defect management system by calling the defect management interface.

[0017] The impact propagation modeling module is connected to the source code analysis module to construct a function-level call graph based on the source code analysis results. The impact propagation modeling module generates a call graph based on the abstract syntax tree and method call information, and establishes call relationships between functions. When a function undergoes code changes, the impact propagation modeling module recursively calculates the direct and indirect callers of that function through the call graph, thereby obtaining a theoretical set of affected functions. This set of affected functions is sent to the multi-dimensional analysis engine in the analysis engine subsystem for subsequent impact scope calculation.

[0018] (2) Dynamic monitoring subsystem The dynamic monitoring subsystem includes an execution path acquisition agent, a dynamic execution monitoring module, a link tracing component, and a coverage acquisition module.

[0019] The execution path acquisition agent is deployed in the runtime environment of the application under test. When the application starts, runtime instrumentation is achieved by adding a Java Agent to the Java Virtual Machine startup parameters. The execution path acquisition agent performs bytecode enhancement on the target method, records call information at the method entry and exit points, and generates execution event data. The generated execution events include: Trace ID, Span ID, method name, start time, end time, and exception information. These execution events are sent to the dynamic execution monitoring module via the network.

[0020] The dynamic execution monitoring module is responsible for receiving and storing the execution event stream and merging it according to the Trace ID. The tracing component further constructs a complete call chain structure based on the relationship between the Span ID and the Parent ID.

[0021] Meanwhile, after the test execution is completed, the coverage acquisition module obtains coverage data from the coverage tool and sends statement coverage, branch coverage, and method coverage information to the multi-dimensional analysis engine.

[0022] (3) Analyze the engine subsystem The analysis engine subsystem includes a multi-dimensional analysis engine, a test range localization module, a defect root cause deduction module, a real-time thread monitor, a dump file export component, and a memory / thread analyzer.

[0023] The multi-dimensional analysis engine receives static call graph data from the impact propagation modeling module of the static analysis subsystem, execution path data from the dynamic execution monitoring module of the dynamic monitoring subsystem, and coverage data from the coverage acquisition module. The engine compares the static call graph with the actual execution paths using a graph matching algorithm, eliminating paths that are theoretically reachable but not executed during actual operation. This analysis yields a set of functions that truly affect the code changes, which is then sent to the test scope localization module.

[0024] The test scope localization module calculates the set of test cases that need to be prioritized for execution based on the set of impact functions output by the multi-dimensional analysis engine and the coverage mapping relationship between test cases and source code. The module can generate either a minimum coverage test set or a reinforced verification test set based on different strategies. The generated test scope information is sent to the test management interface module in the support management subsystem, and the continuous integration platform triggers the corresponding test tasks.

[0025] The real-time thread monitor periodically collects system thread status during test execution. When the number of blocked threads exceeds a preset threshold, the real-time thread monitor sends an alarm signal to the dump file export component. The dump file export component calls system commands to export a Heap Dump or Thread Dump file and sends the generated dump file to the memory / thread analyzer. The memory / thread analyzer parses the dump file, identifies potential memory leaks or thread deadlocks, and sends the analysis results to the global statistics calculator.

[0026] When a test fails, the defect root cause inference module receives the failed test log information and obtains the complete call chain data corresponding to the Trace ID from the dynamic execution monitoring module. The defect root cause inference module calculates the suspicion score of each line of code based on the execution spectrum algorithm and outputs the code location most likely to contain the defect. The calculation results are visualized through a web console.

[0027] (4) Support Management Subsystem The supporting management subsystem includes a defect management interface, a test management interface module, a global statistics calculator, a report template engine, and a web console.

[0028] The global statistics calculator summarizes coverage data, defect information, and performance monitoring data generated during test execution and generates statistical results. These results are then sent to the report template engine. The report template engine generates test reports in HTML or PDF format based on preset templates. The final report is available for download and viewing via a web console.

[0029] The defect management interface is used for bidirectional synchronization with the external defect management system, while the test management interface module is used for unified integration with external continuous integration and test management platforms.

[0030] Beneficial effects Compared with existing technologies, the method and system for precise test range localization based on source code analysis provided by this invention have the following beneficial effects: 1. Achieve the integration of static analysis and dynamic execution data to improve the accuracy of identifying the scope of test impact. This invention constructs a code structure model through a source code analysis module and combines it with runtime execution path data collection. A multi-dimensional analysis engine then performs joint analysis of static call relationships and dynamic execution paths, thereby identifying the code regions truly affected during actual execution. Compared to methods that rely solely on static dependency analysis or coverage statistics, this invention effectively reduces overestimation and underestimation of the impact range, improving the accuracy of test range localization.

[0031] 2. Enable precise positioning of the test scope based on source code changes, reducing regression testing costs. By constructing a code change impact graph using the impact propagation modeling module and combining it with test coverage information to determine the affected code areas, this invention can automatically identify the set of test cases that need to be executed in a key manner based on code changes, thereby avoiding unnecessary full regression testing, reducing test resource consumption, and improving testing efficiency in the continuous integration environment.

[0032] 3. Enable real-time tracing of code execution paths, improving the observability of the testing process. This invention collects method call trajectories during program execution by executing a path acquisition agent, and constructs a complete call chain through a link tracing component, enabling testers to trace from the request entry point to the specific code location, thereby improving the observability of the system operation process and providing accurate data for problem analysis.

[0033] 4. Improve defect location efficiency and shorten problem investigation time. This invention uses a defect root cause deduction module to calculate the suspiciousness of code lines using an execution spectrum algorithm when a test fails, and outputs the code location most likely to have a problem, thereby helping developers quickly locate defective code areas and reducing manual troubleshooting time.

[0034] 5. Implement automatic monitoring and analysis of performance issues during the testing process. By using a real-time thread monitor, a dump file export component, and a memory / thread analyzer, this invention can monitor the system thread status during test execution and automatically export runtime dump data, analyze performance issues such as memory leaks or thread deadlocks, and improve the ability to detect system performance problems.

[0035] 6. Establish a quality analysis system for the entire process of coverage testing execution. This invention uses a global statistical calculator to uniformly summarize coverage data, defect data, and performance monitoring data, and generates test reports using a report template engine. This enables end-to-end quality data management from code changes and test execution to result analysis, thereby improving the automation level of test management.

[0036] In summary, this invention achieves accurate identification of the impact scope of code changes by integrating static source code analysis with runtime dynamic monitoring data. It can also automatically determine the test scope, locate defects, and generate test reports in a continuous integration environment, thereby improving software testing efficiency and quality assurance capabilities. Attached Figure Description

[0037] Figure 1 This is a system structure block diagram of the present invention; Figure 2 This is a flowchart of the method of the present invention; Note: It is recommended that the English terms in the attached diagram be replaced with Chinese terms in the formal submission, for example, "JVM" should be replaced with "Java Virtual Machine" and "JMX" should be replaced with "Java Management Extension". Detailed Implementation

[0038] The following describes specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto.

[0039] Example 1 To more clearly illustrate the implementation process of the test range precision positioning method and system based on source code analysis proposed in this invention, the invention will be described below in conjunction with specific application scenarios.

[0040] In this embodiment, we take the order microservice in an e-commerce system as an example. This system is developed using Java and deployed in a microservice architecture environment. The code is hosted in a Git repository, the continuous integration platform is Jenkins, and the defect management system is Jira.

[0041] When developers modify the OrderService.createOrder() method in the order service and commit the changes to the Git repository, the system begins a process of precise test scope localization based on source code analysis.

[0042] First, perform a test left-shift analysis in phase 1, which corresponds to... Figure 2 The illustrated method flow includes source code parsing and static analysis. The system listens for code commit events in the Git repository via Webhook. When a new commit is detected, the source code parsing module calls the Git API to obtain the code differences corresponding to this commit and downloads the changed source code files. Subsequently, the source code parsing module uses an abstract syntax tree parser to perform syntax analysis on the modified source code, constructing an abstract syntax tree structure and further generating a control flow graph (CFG) and a variable dependency chain (DU-Chain). After parsing, the static analysis engine scans the code according to a preset rule base to identify potential problems, such as null pointer risks, unreleased resources, or code structures that do not conform to coding standards. The scan results are sent to the issue list generator to generate a structured issue list. If the scan results contain issues with a severity level of "Error," the defect conversion module automatically creates a defect record in the Jira system by calling the defect management interface and assigns the defect to the appropriate developer.

[0043] Subsequently, test execution process management is performed in Phase 2, which corresponds to... Figure 2The illustrated method flow includes dynamic execution path collection and call chain construction. When the continuous integration platform triggers an automated test task, the execution path collection agent is loaded via Java Agent when the application under test starts and performs bytecode enhancement on the target method. During application runtime, the execution path collection agent records call information at method entry and exit points, including method name, call time, parameter information, and exception information, and generates execution event data. Each request generates a unique TraceID, and the Span data is reported to the dynamic execution monitoring module via the gRPC protocol. The dynamic execution monitoring module processes the received execution events and stores the Trace data. The tracing component constructs a complete call chain based on the relationship between the Span ID and Parent ID, thus reflecting the call path of a single request across multiple services. Simultaneously, the coverage collection module exports the exec file from the coverage tool after testing and parses it to obtain statement coverage, branch coverage, and method coverage information. The multi-dimensional analysis engine performs a fusion analysis based on the static call graph provided by the impact propagation modeling module and the execution path provided by the dynamic execution monitoring module, outputting the final list of influencing functions.

[0044] Defect localization analysis is performed in stage 3, which corresponds to... Figure 2 The defect localization and result output section of the illustrated method flow is as follows: When an automated test case fails, the defect root cause inference module receives the failure test log, which includes exception stack information, request ID, and test case name. The system queries the corresponding call chain data from the dynamic execution monitoring module based on the Trace ID and obtains the test execution path. Subsequently, the defect root cause inference module uses an execution spectrum defect localization algorithm to calculate the suspiciousness of each line of code. For example, it uses the Ochiai algorithm to score each line of code and sorts them from highest to lowest suspiciousness, finally outputting the most likely problematic code location. The system returns the most suspicious lines of code to the web console and automatically highlights the corresponding line numbers in the source code browsing interface, enabling developers to quickly locate the problem.

[0045] Performance monitoring and analysis are performed in phase 4, which corresponds to... Figure 2The performance monitoring and dump analysis sections of the illustrated method flow are as follows: During test execution, the real-time thread monitor periodically obtains Java Virtual Machine thread state information through the Java Management Extension Interface, such as obtaining the running status, lock wait status, and thread stack information of each thread through the ThreadMXBean interface. When the system detects that the number of blocked threads continuously exceeds a preset threshold, the real-time thread monitor triggers a performance alarm and notifies the dump file export component to perform a dump export operation. The dump file export component calls system commands to generate Heap Dump or Thread Dump files, such as executing the jmap -dump command to generate a heap.hprof file. The generated dump file is then sent to a memory / thread analyzer for analysis to identify whether there are memory leaks, duplicate instances, or thread deadlocks in the system.

[0046] Phase 5 involves processing test results, which corresponds to... Figure 2 The test report generation section of the illustrated method flow is as follows: After the test, the global statistical calculator collects data from modules such as the coverage acquisition module, defect root cause inference module, and real-time thread monitor, and summarizes and statistically analyzes the test execution results, such as calculating the system coverage trend, defect number distribution, and performance indicator changes. The statistical results are then sent to the report template engine, which generates a test report in HTML or PDF format based on a preset template. The test report includes information such as a code change summary, coverage heatmap, defect distribution map, and performance analysis conclusions.

[0047] Phase 6 involves performing full test lifecycle management, which corresponds to... Figure 2 The illustrated method flow includes test scope positioning and task management. Testers can create test submission tasks through the web console, filling in information such as the requirement number, iteration version, and responsible person. The system automatically pulls the commit records related to the task from the code repository through the test management interface module and associates the source code change scope with the test plan. Simultaneously, all defect records generated during the testing process are synchronized with the external defect system through the defect management interface. Once the test report is generated, the system binds the report to the corresponding test submission task and automatically archives it to the project space for subsequent version auditing and quality analysis.

[0048] Through the above implementation process, this invention can automatically identify the affected code areas after code changes occur, and calculate the actual impact range by combining dynamic execution paths and coverage data, thereby determining the set of test cases that need to be prioritized for execution. Simultaneously, the system can monitor system performance in real time during testing and quickly locate defective code when tests fail, thereby improving software testing efficiency and reducing regression testing costs.

[0049] Example 2 In another embodiment, the test scope accurate positioning method and system based on source code analysis proposed in this invention are applied to a continuous integration and continuous delivery (CI / CD) automated testing environment to achieve automatic identification of the impact scope of code changes and dynamic adjustment of test execution strategies.

[0050] In this embodiment, the system is deployed on an enterprise R&D platform and integrated with a code repository platform, a continuous integration platform, and a defect management platform through a test management interface module. For example, the code repository platform is GitLab, the continuous integration platform is Jenkins, the test management system is TestRail, and the defect management system is Jira.

[0051] When developers commit code to the Git repository during a feature iteration, the system listens for commit events via a webhook mechanism. Upon detecting a new commit, the source code parsing module calls the repository API to retrieve the code differences corresponding to this commit and downloads the changed source code files. Subsequently, the source code parsing module uses an abstract syntax tree parser to parse the source code, extracting the modified functions and their context call relationships, while constructing a control flow graph (CFG) and a variable dependency chain (DU-Chain).

[0052] After source code parsing, the static analysis engine performs a static rule scan to identify potential security or coding style issues. For example, it detects null pointer access risks, unreleased resources, or missing exception handling. The scan results are sent to the issue list generator, which generates a structured list of issues and stores it in JSON format. When an issue with a severity level of "Error" is found in the issue list, the defect conversion module automatically creates a defect record by calling the Jira system interface through the defect management interface, sets the defect status to "New," and assigns it to the responsible code handler.

[0053] Meanwhile, the impact propagation modeling module constructs a function-level call graph based on the source code analysis results. When a change to a function is detected, the impact propagation modeling module analyzes the direct and indirect callers of that function through the call graph, forming an initial set of affected functions. This set is then sent to the multi-dimensional analysis engine.

[0054] In a continuous integration pipeline, when Jenkins triggers an automated test task, the execution path acquisition agent is loaded into the runtime environment of the application under test. The execution path acquisition agent enhances the bytecode of the target method using a Java Agent and collects method call information at the method entry and exit points. When the application runs, the execution path acquisition agent records the execution time, parameter information, and exception information for each method call, and generates execution event data. Each request generates a unique Trace ID, and the Span data is reported to the dynamic execution monitoring module via the gRPC protocol.

[0055] The dynamic execution monitoring module stores the received execution event data and constructs a complete call chain structure using the tracing component. Meanwhile, the coverage acquisition module exports coverage data files from the coverage tool after test execution and parses them to obtain statement coverage, branch coverage, and method coverage information.

[0056] The multi-dimensional analysis engine matches and analyzes the static call graph provided by the impact propagation modeling module with the execution paths provided by the dynamic execution monitoring module. By comparing static dependencies with actual execution paths, the multi-dimensional analysis engine can eliminate theoretically reachable but not actually executed paths, thereby obtaining the set of functions that truly affect the code changes. This set is then sent to the test scope localization module.

[0057] The test scope localization module calculates the set of test cases to be executed based on the set of affected functions and the coverage mapping relationship between test cases and source code. For example, the system can generate a minimum coverage test set to ensure that all affected functions are covered by at least one test case; it can also generate a reinforced verification test set to increase the testing intensity of critical functional paths. The generated test scope information is then sent to the continuous integration platform through the test management interface module, where the continuous integration platform schedules the execution of the corresponding test cases.

[0058] During test execution, the real-time thread monitor continuously monitors the system thread status and obtains Java Virtual Machine thread runtime information through the Java Management Extension Interface. When the number of blocked threads exceeds a preset threshold and persists for a certain period, the real-time thread monitor triggers a performance alarm and notifies the dump file export component to perform a dump file export operation. The dump file export component generates a Heap Dump or Thread Dump file via system commands and sends the generated dump file to the memory / thread analyzer. The memory / thread analyzer analyzes the dump file to identify potential memory leaks or thread deadlock issues.

[0059] When a test case fails, the defect root cause inference module receives the failed test log and retrieves the corresponding call chain data from the dynamic execution monitoring module based on the Trace ID in the log. Subsequently, the defect root cause inference module uses an execution spectrum defect localization algorithm to calculate the suspiciousness of code lines and outputs the code locations with the highest suspiciousness. The system visualizes these code locations through a web console and highlights the corresponding code lines in the source code browsing interface, enabling developers to quickly locate the problem.

[0060] After the testing task is completed, the global statistics calculator summarizes the coverage data, defect information, and performance monitoring data generated during the test execution and generates statistical results. The report template engine generates a test report based on the statistical results. The test report includes information such as a code change summary, test coverage analysis, defect distribution statistics, and performance analysis results. The final generated test report is stored in the project space and can be viewed and downloaded through a web console.

[0061] As can be seen from this embodiment, the test scope accurate positioning method and system based on source code analysis proposed in this invention can automatically identify the impact range of code changes in a continuous integration environment, and dynamically adjust the test execution strategy according to the impact range, thereby reducing unnecessary test execution, improving test efficiency, and achieving integrated support for defect location and performance monitoring during the test process.

[0062] Example 3 In another embodiment, the method and system for precise test scope positioning based on source code analysis proposed in this invention are applied to software systems with microservice architecture to achieve analysis of the impact of code changes and test scope positioning under cross-service call relationships.

[0063] In this embodiment, the target system consists of multiple independently deployed microservices, which communicate with each other through REST interfaces or message queues. Each microservice deploys an execution path collection agent from the present invention, which collects method call information at runtime and reports the collected execution event data to the dynamic execution monitoring module.

[0064] When a developer modifies code in a microservice and commits it to the code repository, the system receives the commit event pushed by the code repository through the test management interface module. Subsequently, the source code parsing module obtains the source code files involved in this commit and parses the relevant source code. The source code parsing module extracts code structure information through an abstract syntax tree parser, and simultaneously constructs a control flow graph (CFG) and a variable dependency chain (DU-Chain) to identify the functions and variable dependencies involved in the code changes.

[0065] After completing the source code analysis, the impact propagation modeling module constructs a function-level call graph based on the analysis results and performs dependency propagation analysis on the changed functions. The impact propagation modeling module first identifies the direct callers and called functions of the changed functions, and then recursively analyzes the call relationships to form the change impact propagation graph. In a microservice system, when the interface function of a service changes, the impact propagation modeling module also analyzes the call behavior of that interface in other services, thereby identifying cross-service call relationships.

[0066] During system operation, each microservice instance records method call traces through an execution path collection agent and generates a unique Trace ID for each request. The execution path collection agent records call information at method entry and exit points using bytecode enhancement technology and sends the collected Span data to the dynamic execution monitoring module. The dynamic execution monitoring module receives execution event data from each microservice instance and uses a distributed tracing component to correlate the call relationships between different services, thus forming a complete distributed call chain.

[0067] During the testing phase, when automated test cases trigger system interface requests, the dynamic execution monitoring module records the complete cross-service call path and collects code coverage information from each microservice through the coverage collection module. After the test is completed, the coverage collection module exports the coverage data file and parses it to obtain information such as statement coverage, branch coverage, and method coverage.

[0068] The multi-dimensional analysis engine integrates and analyzes the static call relationships generated by the impact propagation modeling module with the call chain data collected by the dynamic execution monitoring module. By comparing the static dependency paths with the call paths generated during actual operation, the multi-dimensional analysis engine can identify the actual executed code paths and filter out theoretically reachable but unexecuted paths. After analysis, the multi-dimensional analysis engine generates a joint impact graph across services and determines the actual impact scope of code changes in each microservice.

[0069] Subsequently, the test scope localization module calculates the set of test cases that need to be prioritized for execution based on the joint impact graph and test case coverage information. In a microservice system, different test cases may cover different service modules. Therefore, the test scope localization module can automatically identify the interface tests, integration tests, or end-to-end test cases that need to be executed based on the location of code changes, thereby avoiding the need to perform full testing on all services.

[0070] When a failed test case occurs during test execution, the defect root cause inference module retrieves the corresponding distributed call chain based on the Trace ID of the failed test case and analyzes the suspicious code location in conjunction with code coverage information. The defect root cause inference module calculates the suspicion value of each line of code using a spectrum defect localization algorithm and outputs the code location with the highest suspicion value to the web console for display, enabling developers to locate the problem.

[0071] In addition, during system operation, the real-time thread monitor continuously monitors the thread running status of each microservice instance. When thread blocking or an abnormal number of threads is detected, the real-time thread monitor triggers the dump file export component to export thread dump or memory dump files, which are then analyzed by the memory / thread analyzer to identify potential thread deadlock or memory leak issues.

[0072] After the testing tasks are completed, the global statistics calculator summarizes the coverage data, defect data, and performance monitoring data generated by each microservice and performs statistical analysis according to service or module dimensions. The report template engine generates a test report based on the statistical results, which includes code change impact analysis, service call chain analysis, test coverage statistics, and defect distribution. The final generated test report is visualized through a web console and supports downloading and archiving.

[0073] As can be seen from this embodiment, the test scope accurate positioning method and system based on source code analysis proposed in this invention can perform cross-service analysis on the impact scope of code changes in microservice architecture software systems, and determine the real impact path by combining dynamic execution data, thereby achieving accurate positioning of the test scope, improving testing efficiency and reducing testing resource consumption.

Claims

1. A method for accurately locating the test range based on source code analysis, characterized in that, include: The code changes in the source code repository are analyzed, an abstract syntax tree is constructed, and function call relationships and variable dependencies are extracted. Based on the analysis results, a static rule scan is performed to generate a problem list, and high-risk problems are automatically converted into defect entries. Establish a code change impact propagation model based on the function call relationships; During program execution, the method call trajectory is collected by the execution path acquisition agent and an execution event stream is generated. The execution event stream is processed to construct a call chain and collect code coverage data; By combining static analysis results with dynamic execution path data, the true impact range of code changes can be calculated. Based on the scope of impact, determine the set of test cases that need to be prioritized for execution; During test execution, monitor thread status and memory usage, and export dump files for analysis when exceptions occur. When a test fails, the suspiciousness of a line of code is calculated based on the execution spectrum algorithm to locate potentially defective code; Summarize coverage data, defect information, and performance monitoring data during test execution and generate a test report.

2. The method according to claim 1, characterized in that: The source code parsing changes include using an abstract syntax tree parser to perform syntax parsing on the source code and constructing a control flow graph (CFG) and a variable dependency chain (DU-Chain).

3. The method according to claim 1, characterized in that: The static rule scanning matches defect patterns in the source code through a built-in rule base, including null pointer risks, unreleased resources, and coding standard issues.

4. The method according to claim 1, characterized in that: The execution path acquisition agent records call information at the method entry and exit points through bytecode enhancement, and generates execution event data containing Trace ID and Span ID.

5. The method according to claim 1, characterized in that: The coverage data collection is achieved by parsing the execution data file generated by the coverage tool after the test is completed to obtain statement coverage, branch coverage, and method coverage.

6. The method according to claim 1, characterized in that: The fusion of static analysis results and dynamic execution path data includes using graph algorithms to match static call graphs and dynamic execution paths, and eliminating theoretically reachable but not actually executed paths.

7. The method according to claim 1, characterized in that: The defect localization process calculates the code line suspicion level by executing a spectrum defect localization algorithm, and outputs the code segments most likely to contain defects according to the suspicion level.

8. A test range precise positioning system based on source code analysis, characterized in that, include: The static analysis subsystem includes: The source code analysis module is used to analyze code changes and extract syntax structure information; A static analysis engine is used to scan for potential problems in the source code; A question list generator for generating structured lists of questions; The defect conversion module is used to automatically convert high-risk issues into defect entries; The impact propagation modeling module is used to create a graph showing the propagation of the impact of code changes. The dynamic monitoring subsystem includes: Execution path collection agent, used to collect runtime method call traces; The dynamic execution monitoring module is used to process the execution event stream and record call chain data; Link tracing component, used to build distributed call chain structure; The coverage acquisition module is used to collect statement, branch, and method coverage. The analysis engine subsystem includes: A multi-dimensional analysis engine is used to integrate dynamic and static data and calculate the true scope of impact. The test scope positioning module is used to output the code blocks and test case sets that need to be tested in detail; The defect root cause derivation module is used to locate the most likely defective line of code; A real-time thread monitor is used to monitor thread status and identify blocked threads. A dump file export component for exporting Heap Dump or Thread Dump files; A memory / thread analyzer used to analyze memory leaks or deadlocks in dump files; The supporting management subsystem includes: A defect management interface for bidirectional synchronization with external defect systems; The test management interface module is used for unified integration with external CI / CD and test management platforms; A global statistics calculator for summarizing coverage, defects, and performance data; A report template engine for generating test reports; The web console provides a visual management interface.

Images