Method and system for testing coverage rate of incremental code

Abstract

The invention discloses a coverage rate testing method and system for incremental codes, and the method comprises the steps: analyzing a current version code and a reference version code of a target project, so as to recognize a change function; performing influence range analysis on the change function to determine an associated code directly or indirectly influenced by the change function, and taking the change function and the associated code as a target monitoring code; executing acquisition logic at a preset position of the target monitoring code through instrumentation implantation so as to collect execution data of the target monitoring code in the running process; and calculating an incremental coverage rate of the target monitoring code based on the execution data. By analyzing and identifying a change function, analyzing and locking associated codes in combination with an influence range, collecting execution data through instrumentation, calculating an incremental coverage rate, accurately positioning a change point and determining a test range, the problems of resource redundancy and low efficiency of a full test are solved, and the defects of insufficient change positioning and coverage analysis are overcome; and precise quantification of incremental code testing is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of code testing, in particular to a coverage testing method and system for incremental code. BACKGROUND

[0002] In the software development process, code coverage testing is an important means to ensure software quality. By counting the proportion of executed code during testing, the sufficiency of testing can be evaluated, providing a basis for software iteration and quality optimization. With the increasing complexity of software systems and the accelerating speed of version iteration, how to accurately and efficiently test the coverage of incremental code in each iteration has become a key to improving testing efficiency and reducing testing costs.

[0003] Currently, existing code coverage testing solutions focus on the coverage of full-amount code, i.e., overall testing coverage analysis of all code in the software. However, in the context of frequent version iteration, full-amount coverage testing has obvious limitations: on the one hand, only part of the code changes in each iteration, and full-amount coverage testing consumes a lot of redundant resources, with low testing efficiency and difficulty in focusing on the incremental changes that need to be concerned; on the other hand, existing technologies are difficult to accurately identify changed functions between versions, especially difficult to distinguish between semantic changes and non-functional changes (such as format adjustment, comment modification, etc.) of code, resulting in inaccurate positioning of changed points. For the identified changed functions, existing solutions lack effective analysis of their direct or indirect impact range, making it difficult to accurately determine the target code that needs to be tested, which can easily cause the problem of too large testing range or missing key associated code. In addition, in the data collection and incremental coverage calculation stage, existing technologies often have problems such as insufficient data collection pertinence and difficulty in performing special coverage analysis based on execution data of changed code, which makes it difficult to accurately quantify the testing coverage of incremental code, affecting the judgment of the testing quality of the iteration version, and further increasing the risk of software release. SUMMARY

[0004] Therefore, the present application provides a coverage testing method and system for incremental code, which can collect execution data pertinently and calculate incremental coverage from multiple dimensions, achieving efficient and accurate testing coverage analysis of incremental code. The present application provides the following technical solutions: A coverage testing method for incremental code, the method comprising: analyzing the current version code and the baseline version code of a target project to identify changed functions; performing impact range analysis on the changed functions to determine associated code directly or indirectly affected by the changed functions, and taking the changed functions and associated code as target monitoring code; inserting execution collection logic at preset positions of the target monitoring code to collect execution data of the target monitoring code during running; calculating the incremental coverage of the target monitoring code based on the execution data.

[0005] Optionally, the analyzing the current version code and the benchmark version code of the target project to identify the changed function comprises: parsing source codes of the current version code and the benchmark version code into abstract syntax tree structures respectively; comparing the addition, deletion and modification of nodes in the abstract syntax tree structures corresponding to the current version code and the benchmark version code to distinguish semantic changes and structural changes, wherein the semantic changes include function logic changes, and the structural changes include function addition, function deletion and function renaming; outputting a structured function change result based on the semantic changes and the structural changes.

[0006] Optionally, the method further comprises: performing influence range analysis on the changed code to determine associated code directly or indirectly affected by the changed code, and including the changed code and the associated code as the target monitoring code. performing static scanning on full code of the target project to construct a function call graph; marking the changed function as a starting node, taking the starting node as a starting point, traversing all caller links calling the changed function upwards along the function call graph to determine direct callers and indirect callers, and traversing callee links called by the changed function downwards to determine direct callees and indirect callees; taking code corresponding to functions involved in the above caller links and callee links as the associated code, and taking the changed function and the associated code together as the target monitoring code.

[0007] Optionally, the inserting execution collection logic at preset positions of the target monitoring code to collect execution data of the target monitoring code during running comprises: traversing an abstract syntax tree structure of the target monitoring code, and inserting a counter increasing logic at an entry position of each function traversed; collecting execution data of each function through the counter increasing logic, wherein the execution data includes execution times, function call paths and execution time stamps.

[0008] Optionally, after the inserting execution collection logic at preset positions of the target monitoring code to collect execution data of the target monitoring code during running, the method further comprises: writing the execution data into a local data buffer; persist the execution data in the local data buffer to the local storage medium when the local data buffer reaches a preset threshold or meets a preset triggering condition; monitoring states of the plurality of test terminals and dynamically triggering uploading of the execution data according to the states and a preset uploading strategy.

[0009] Optionally, before calculating the incremental coverage of the target monitoring code based on the execution data, the method further comprises: performing grouping on the execution data uploaded by the plurality of test terminals to merge execution data from different test terminals but corresponding to the same function; The merging processing comprises: execution times merging: accumulating execution times of the same function at different test terminals to generate total execution times after merging, call path merging: extracting context data of function calls and retaining differentiated call paths of the same function under different test scenarios through a deduplication algorithm, time dimension merging: recording first execution time and last execution time of the function based on execution timestamps and calculating execution frequency per unit time, and the calculating the incremental coverage of the target monitoring code based on the execution data comprises: calculating the incremental coverage of the target monitoring code according to the execution data obtained through the merging processing.

[0010] Optionally, the calculating the incremental coverage of the target monitoring code based on the execution data comprises: defining an incremental coverage model, the incremental coverage model comprising execution intensity coverage, execution path coverage and execution frequency coverage; wherein: based on the merged execution times data, calculating a proportion of total execution times of the executed changed function and associated functions to total theoretical execution times of all functions in the target monitoring code to form the execution intensity coverage; statistically calculating a proportion of the number of executed differentiated call paths to the total number of call paths of all functions in the target monitoring code to form the execution path coverage; based on the first execution time and the last execution time, calculating execution frequency coverage of the target monitoring code in a preset time period.

[0011] The application further discloses an incremental code coverage testing system, comprising: a code analysis module configured to analyze current version code and benchmark version code of a target project to identify a changed function, and a changed function analysis module configured to perform influence range analysis on the changed function to determine associated code directly or indirectly affected by the changed function, and take the changed function and the associated code as target monitoring code. An execution data collection module is configured to insert an execution collection logic at a preset position of the target monitoring code by means of instrumentation to collect execution data of the target monitoring code during running. An incremental coverage calculation module is configured to calculate the incremental coverage of the target monitoring code based on the execution data.

[0012] The application further discloses a computer readable storage medium, which is characterized by storing a computer program.

[0013] The application further discloses an electronic device, which comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor.

[0014] According to the technical scheme of the application, the current version code and the benchmark version code of the target project are analyzed to identify the changed functions, and the influence range analysis is further performed on the changed functions to determine the associated codes, which are collectively used as the target monitoring code, and the execution collection logic is inserted at the preset position of the target monitoring code by means of instrumentation to collect the execution data, and finally the incremental coverage is calculated based on the execution data, so that the changed part in the code iteration is accurately locked and the range that needs to be tested is determined, which not only solves the problems of resource redundancy and low efficiency caused by the large coverage range of the existing full-amount code test, but also overcomes the defects of inaccurate change point positioning and insufficient test pertinence caused by the lack of influence range analysis, and the key associated codes are missed, and through the targeted execution data collection and incremental coverage calculation, the incremental code test coverage is accurately quantified, the test efficiency and pertinence are effectively improved, the reliable basis for the test quality evaluation of the iteration version is provided, and the software release risk is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0015] For the purpose of illustration but not limitation, the application will be described in conjunction with the embodiments of the application and the accompanying drawings, in which: Figure 1 is a flowchart of the incremental code coverage test method in the embodiments of the application; Figure 2 is a structural schematic diagram of the incremental code coverage test system in the embodiments of the application; Figure 3 is a structural schematic diagram of the electronic device in the embodiments of the application. DETAILED DESCRIPTION

[0016] In order to make the person skilled in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by the person skilled in the art without creative labor should belong to the scope of protection of the present application.

[0017] It should be noted that the features in the embodiments and the embodiments of the present application can be combined with each other without conflict. The embodiments of the present application will be described in detail below in combination with the drawings.

[0018] Reference Figure 1 The present embodiment discloses a coverage test method of incremental code, which comprises the following steps: S100: analyzing the current version code and the benchmark version code of the target project to identify the changed functions.

[0019] First, the current version source code and the benchmark version source code of the target project are obtained respectively, and the two source codes are parsed into abstract syntax tree (AST) structure by using a syntax parser, wherein the nodes of the abstract syntax tree contain the structured information of code elements such as function definition, class definition, method call, variable declaration, etc. Then, the two abstract syntax trees are traversed layer by layer by using an AST comparison algorithm, and the differences of the function definition nodes are compared, which specifically include the function name, the parameter list, the return value type, the statement block structure inside the function body and other characteristics. In the comparison process, the same function is determined by matching the combination of the function name and the parameter list, and the AST node differences inside the function body are further analyzed to distinguish semantic changes and structural changes. Specifically, if the function name or the parameter list changes (such as adding parameters, deleting parameters or modifying parameter types), it is determined as a structural change, including: function addition, i.e. the function that exists in the current version but does not exist in the benchmark version; function deletion, i.e. the function that exists in the benchmark version but does not exist in the current version; function renaming, i.e. the function name is changed but the function body logic is not changed. If the function name and the parameter list do not change but the statement blocks (such as conditional judgment, loop logic, operation expression, etc.) inside the function body exist node addition, deletion or modification, it is determined as a semantic change, i.e. the function logic changes. Finally, a structured function change result is generated according to the comparison result, which contains the unique identifier of the changed function, the change type and the location information in the source code, so as to complete the accurate identification of the changed function.

[0020] S200: performing influence range analysis on the changed function to determine the associated code directly or indirectly affected by the changed function, and taking the changed function and the associated code as the target monitoring code.

[0021] In the influence range analysis of the change function, firstly, the full code of the target project is scanned by a static code analysis tool to build a function call graph, which takes functions as nodes and function call relationships as edges, and completely presents the call dependency relationship between functions in the code library. Subsequently, the identified change function is marked as a starting node, and from the starting node, bidirectional traversal is performed along the function call graph: All caller links that directly or indirectly call the change function are traversed upwards, for example, if function A calls function B, and function B calls change function C, then functions A and B are identified as callers of change function C; The callee links directly or indirectly called by the change function are traversed downwards, for example, if change function C calls function D, and function D calls function E, then functions D and E are identified as callees of change function C.

[0022] During the traversal process, a depth-first search algorithm is used in combination with call context information (such as function parameter types and return value types) to ensure the accuracy of the traversal and avoid false positives due to function overloading or conditional calls. Finally, the code corresponding to all functions involved in the above caller links and callee links is determined as associated code, and together with the change function, it forms a target monitoring code set, which completely covers all code ranges that may be affected by the change function, providing accurate target objects for subsequent instrumentation and execution data collection.

[0023] S300: Insert execution collection logic at a preset position of the target monitoring code through instrumentation to collect execution data of the target monitoring code during running.

[0024] Firstly, based on the abstract syntax tree (AST) structure of the target monitoring code constructed in step S100, a custom AST traverser is used to perform deep traversal on each function node to locate the function entry position, i.e., the starting line of the function body. During the traversal process, for each change function and associated function identified, counter increment logic is inserted at the function entry of the AST node, which includes a unique function identifier and a counter variable to record the execution frequency of the function. At the same time, call path collection code is inserted at the function entry to capture the call stack information of the current thread, extract the upper function chain that calls the function, and generate complete call path data in combination with function parameter values and execution context. In addition, timestamp recording code is inserted at the function entry to use a high-precision clock to obtain the precise time point of function execution, and to record the first execution time and the timestamp of each execution, providing a data basis for subsequent execution frequency calculation.

[0025] After the completion of the insertion, the modified AST is converted back to the source code and recompiled to ensure that the implanted execution collection logic does not affect the normal operation of the original code. During the operation of the application, whenever a function in the target monitoring code is called, the insertion logic is automatically triggered to increment the execution frequency counter, record the current call path and timestamp information, and temporarily store these execution data in the memory buffer. When the preset condition is met, the execution data is batch written to the local storage, thereby completing the accurate collection of the execution data of the target monitoring code.

[0026] After the collection of the execution data is completed, the collected execution data, including the function execution frequency, call path and timestamp, is written to the memory-based local data buffer. The buffer is implemented in a ring queue structure, and a fixed-size memory block and read-write pointers are used to efficiently manage data writing. When the amount of data in the local data buffer reaches a preset threshold or meets a preset trigger condition, the data persistence process is started: through the file lock mechanism, the atomicity of data writing is ensured, the data in the buffer is appended to the local storage medium in binary format, and a compression algorithm is used to compress the data in real time to reduce the storage space occupation. At the same time, in order to avoid data loss, after each write operation is completed, the data integrity is verified by checksum and the write position index is recorded.

[0027] In the data upload phase, a system broadcast receiver is registered to listen to the state changes of multiple test terminals, including network connection state, power state, device idle state, etc. Based on these state information, the upload of the execution data is dynamically triggered according to the preset upload strategy. For example, when the network connection is switched to WiFi and the power is sufficient, batch upload is immediately started; if it is in a mobile network environment, small batch of key data is uploaded first; if the device is in an idle state, full data upload is started. During the upload process, the HTTPS protocol is used to send the execution data stored in the local storage to the server side, and after the upload is successful, the uploaded data block is deleted through the file index, and the upload timestamp is recorded for subsequent breakpoint resume. If the upload fails, the number of failures is automatically recorded, and when the number of consecutive failures exceeds the preset number, the exponential backoff strategy is triggered to gradually increase the retry interval time, ensuring reliable data transmission while minimizing the impact on terminal performance.

[0028] Further, when performing grouping and merging processing on the execution data uploaded by multiple test terminals, a distributed data processing engine is first constructed on the server side, and all uploaded execution data is hashed partitioned according to the function unique identifier, ensuring that the execution data from different test terminals but corresponding to the same function is allocated to the same processing node. For the data in each partition, the following merging operations are performed in turn: In the execution times merging stage, the distributed accumulation algorithm is adopted to accumulate the execution times counter values of the same function at different test terminals to generate the total execution times after merging. In the specific implementation, in order to avoid data skew, local accumulation is first performed locally at each computing node, and then the results are aggregated to the master node for global accumulation, and finally the total execution times are stored in the distributed key-value storage, with the function unique identifier as the key and the accumulated execution times as the value.

[0029] In the call path merging stage, the context data of function calls (including call stack information, parameter values, global variable states, etc.) are extracted from the execution data, which are converted into fixed-length feature vectors, and the Bloom filter is used to quickly determine whether there is a duplicate path. For the newly discovered call path, the consistent hashing algorithm is used to map it to the corresponding storage bucket, and the version number mechanism is used to retain the differentiated call paths of the same function under different test scenarios. Finally, the deduplicated call path set is stored in the distributed file system, and the index relationship between the function and the call path is established.

[0030] In the time dimension merging stage, for the execution timestamp set of each function, the earliest timestamp is determined as the first execution time and the latest timestamp is determined as the last execution time through the distributed sorting algorithm. At the same time, the timestamp sequence is divided according to the preset time window, the execution times in each window are counted, and the sliding average algorithm is used to calculate the execution frequency per unit time. In order to support real-time query, the time dimension merging result is stored in the time series database, and the composite index based on the function identifier and the time window is established.

[0031] After the merging processing is completed, the structured merged execution data is generated, including the function unique identifier, the total execution times, the deduplicated call path set, the first execution time, the last execution time, and the execution frequency distribution, which provides a unified and complete data source for subsequent incremental coverage calculation.

[0032] S400: Calculate the incremental coverage of the target monitoring code based on the execution data. Specifically, first, accurately map the merged execution data with the changed functions identified in step S100 and the associated code determined in step S200, and establish the correspondence between the function signature and the change type and the line number range. For each changed function and associated function, the coverage is calculated from three dimensions of execution intensity, execution path and execution frequency, including: In the execution intensity dimension, based on the merged execution times data, the total execution times of the executed changed functions and associated functions account for the total theoretical executable times of all functions in the target monitoring code, and the proportion is the execution intensity coverage, wherein the theoretical executable times are calculated in advance by analyzing the control flow structure of the function. In the execution path dimension, the number of executed differentiated call paths accounts for the total number of call paths in the target monitoring code, and the total number of call paths is obtained by combining the conditional judgment and loop structure inside the function through static analysis. The ratio is the execution path coverage rate; In the execution frequency dimension, the preset time period is divided into several time windows based on the first execution time and the last execution time, the execution times of the target monitoring code in each window are calculated, the execution frequency distribution curve is generated through time series analysis algorithm, and then the execution frequency coverage rate is obtained.

[0033] The three-dimensional coverage rate data is aggregated to generate a comprehensive incremental coverage rate index. At the same time, the changed functions, code lines and call paths not recorded in the execution data are marked as uncovered items, and their change types and line number ranges in the structured change results are associated. Finally, the incremental coverage rate report containing the coverage rate values of each dimension and the details of the uncovered items is output, providing data support for the test team to evaluate the sufficiency of the incremental code test.

[0034] After obtaining the comprehensive incremental coverage rate index, the background management system displays the test coverage rate data report through multi-dimensional visualization technology. The system adopts a hierarchical design principle, builds an interactive dashboard on the front-end interface, and displays the comprehensive incremental coverage rate index in the form of a ring chart. The execution intensity, execution path and execution frequency dimensions are presented in different color sectors, and the weight of each dimension is intuitively reflected through dynamic proportion animation. For the uncovered items, the system generates an expandable tree structure list, which is classified by change type (add, modify, delete) and code path. Clicking on a specific item can view the context information (such as line number, function signature, change time) of the uncovered code, and the code difference before and after the change is displayed through code highlighting technology.

[0035] To support trend analysis, the system generates a coverage rate change curve based on time series data, with the horizontal axis representing test batches or time windows and the vertical axis representing coverage rate percentage. The curve color distinguishes the coverage rate change trend of different dimensions. At the same time, the system provides a version comparison function, allowing testers to select any two historical versions and visually display the incremental coverage rate changes through a heat map. The color depth represents the degree of coverage rate improvement or decline. For execution path coverage rate, the system builds an interactive call path graph with changed functions as central nodes, connecting all callers and callees through directed edges. The edge thickness represents the call frequency, and clicking on a node can view the detailed execution data of the function (such as execution times, first / last execution time).

[0036] In summary, the embodiment accurately identifies the change function and analyzes its influence range, realizes the focus on the target monitoring code, avoids the resource redundancy and low efficiency of full code testing; through the targeted insertion, collection, local buffering and dynamic uploading strategy, the complete, efficient collection and reliable transmission of the execution data are ensured, and the multi-terminal data fragmentation problem is solved; with the aid of the multi-dimensional data merging algorithm based on the unique identification of the function, the execution data of different terminals and batches is effectively integrated, providing a unified and accurate basis for coverage calculation; the multi-dimensional incremental coverage calculation and visual report display realize the comprehensive, accurate quantification and intuitive presentation of the incremental code test coverage, which not only clearly reflects the execution intensity, path coverage and frequency characteristics, but also accurately locates the uncovered items, significantly improves the test pertinence and effectiveness, reduces the test cost, provides a reliable basis for the test team to directly evaluate the iteration quality and optimize the test strategy, and finally helps to improve the quality and confidence of software release.

[0037] Reference Figure 2 The embodiment also discloses an incremental code coverage testing system, which comprises a code analysis module 21, a change function analysis module 22, an execution data collection module 23 and an incremental coverage calculation module 24, and the following details are described: the code analysis module 21 is used for analyzing the current version code and the benchmark version code of a target project to identify a change function, and comprises the following steps: the source codes of the current version code and the benchmark version code are parsed into abstract syntax tree structures respectively; the addition, deletion and modification of nodes in the abstract syntax tree structures corresponding to the current version code and the benchmark version code are compared to distinguish semantic changes and structural changes, wherein the semantic changes include function logic changes, and the structural changes include function addition, function deletion and function renaming; and a structured function change result is output based on the semantic changes and the structural changes.

[0038] The change function analysis module 22 is used for analyzing the influence range of the change function to determine the associated code directly or indirectly affected by the change function, and the change function and the associated code are taken as target monitoring code, and comprises the following steps: the full code of the target project is statically scanned to construct a function call graph; the change function is marked as a starting node, and all caller links calling the change function are traversed upwards from the starting node along the function call graph to determine direct callers and indirect callers, and all callee links called by the change function are traversed downwards to determine direct callees and indirect callees; the code corresponding to the functions involved in the above caller links and callee links is taken as the associated code, and the change function and the associated code are jointly determined as the target monitoring code.

[0039] The execution data collection module 23 is configured to collect execution data of the target monitoring code in a running process by inserting a collection logic at a preset position of the target monitoring code, including: traversing an abstract syntax tree structure of the target monitoring code, and inserting a counter increasing logic at an entry position of each function traversed; collecting execution data of each function by the counter increasing logic, the execution data including execution times, function call paths and execution time stamps.

[0040] The incremental coverage calculation module 24 is configured to calculate an incremental coverage of the target monitoring code based on the execution data, including: defining an incremental coverage model, the incremental coverage model including execution intensity coverage, execution path coverage and execution frequency coverage; wherein: based on the merged execution times data, a proportion of a total execution times of the executed changed functions and associated functions to a total theoretical execution times of all functions in the target monitoring code is calculated to form the execution intensity coverage; a proportion of a number of executed differentiated call paths to a total number of all function call paths in the target monitoring code is calculated to form the execution path coverage; and based on a first execution time and a last execution time, an execution frequency coverage of the target monitoring code in a preset time period is calculated.

[0041] Figure 3 An electronic device entity structure schematic diagram provided by the embodiment of the present application is shown in FIG. 1. Figure 3 As shown in FIG. 1, the electronic device 50 includes a processor 501, a memory 502 and a bus 503. The processor 501 and the memory 502 communicate with each other through the bus 503; the processor 501 is configured to invoke program instructions in the memory 502 to execute the method provided by each method embodiment.

[0042] The embodiment provides a non-transitory computer readable storage medium, which stores computer instructions, and the computer instructions make the computer execute the method provided by each method embodiment.

[0043] Those skilled in the art can understand that all or part of the steps of the above method embodiments can be completed by program instruction related hardware, and the foregoing program can be stored in a computer readable storage medium, and the program executes the steps of the above method embodiments when executed; and the foregoing storage medium includes ROM, RAM, magnetic disc or optical disc and various storage media that can store program codes.

[0044] The apparatus embodiments described above are merely illustrative, units illustrated as separate components can or can not be physically separate, components illustrated as units can or can not be physical units, i.e. can be located in one place or can be distributed to multiple network units. Part or all of the modules can be selected to achieve the purposes of the embodiments according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0045] Through the description of the above embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software and necessary universal hardware platforms, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of software products, and the computer software products can be stored in a computer readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and include a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods of the embodiments or some parts of the embodiments.

[0046] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can occur depending on design requirements and other factors. Any modification, equivalent replacement and improvement within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A method for incremental code coverage testing, characterized in that, The method includes: Analyze the current version and baseline version of the target project's code to identify the changed functions; An impact range analysis is performed on the changed function to determine the associated codes that are directly or indirectly affected by the changed function, and the changed function and associated codes are used as target monitoring codes. Execution data acquisition logic is inserted by instrumentation at a preset position of the target monitoring code to collect execution data of the target monitoring code during its operation; The incremental coverage of the target monitoring code is calculated based on the execution data.

2. The incremental code coverage testing method according to claim 1, characterized in that, Analyze the current and baseline versions of the target project's code to identify the changed functions, including: The source code of the current version and the base version is parsed into abstract syntax tree structures respectively; Compare the addition, deletion and modification of nodes in the abstract syntax tree structure corresponding to the current version code and the base version code to distinguish between semantic changes and structural changes. Semantic changes include changes in function logic, while structural changes include adding, deleting and renaming functions. The function modification results are structured based on semantic and structural changes.

3. The incremental code coverage testing method according to claim 1, characterized in that, An impact scope analysis is performed on the changed code to identify related codes that are directly or indirectly affected by the changed code, and the changed code and related codes are included as target monitoring codes: Perform static scanning on the entire codebase of the target project and construct a function call graph; Mark the modified function as the starting node. Starting from the starting node, traverse all caller links that call the modified function upwards along the function call graph to determine the direct caller and indirect caller. At the same time, traverse the callee links called by the modified function downwards to determine the direct callee and indirect callee. The code corresponding to the functions involved in the caller chain and the callee chain mentioned above is used as associated code, and the changed function and associated code are jointly identified as the target monitoring code.

4. The incremental code coverage testing method according to claim 1, characterized in that, The execution logic for data acquisition is implanted by instrumentation at a preset location in the target monitoring code to collect execution data of the target monitoring code during its operation, including: The abstract syntax tree structure of the target monitoring code is traversed, and instrumentation is performed at the entry point of each function to inject counters and add logic. The counter increments logic to collect execution data for each function, including the number of executions, function call path, and execution timestamp.

5. The incremental code coverage testing method according to claim 1, characterized in that, After instrumenting execution acquisition logic at a preset location in the target monitoring code to collect execution data during the operation of the target monitoring code, the method further includes: Write the execution data into the local data buffer; When the local data buffer reaches a preset threshold or meets a preset trigger condition, the execution data in the local data buffer will be persisted to the local storage medium. Monitor the status of multiple test terminals and dynamically trigger the upload of execution data according to the preset upload strategy based on the status.

6. The incremental code coverage testing method according to claim 5, characterized in that, Before calculating the incremental coverage of the target monitoring code based on the execution data, the method further includes: The execution data uploaded from multiple test terminals is grouped to merge execution data from different test terminals that correspond to the same function. The merging process includes: Execution count merging: The execution counts of the same function on different test terminals are accumulated to generate a merged total execution count. Call path merging: The context data of function calls is extracted, and a deduplication algorithm is used to retain the differentiated call paths of the same function in different test scenarios. Time dimension merging: Record the first and last execution times of a function based on its execution timestamp, and calculate the execution frequency per unit time. Furthermore, the step of calculating the incremental coverage of the target monitoring code based on the execution data includes: calculating the incremental coverage of the target monitoring code based on the execution data obtained from the merging process.

7. The incremental code coverage testing method according to claim 6, characterized in that, The calculation of the incremental coverage of the target monitoring code based on the execution data includes: Define an incremental coverage model, which includes execution intensity coverage, execution path coverage, and execution frequency coverage; wherein: Based on the merged execution count data, the proportion of the total number of executions of the modified functions and related functions to the total number of theoretically executable functions in the target monitoring code is calculated to form the execution intensity coverage rate; The execution path coverage is calculated by determining the proportion of the number of differentiated call paths executed relative to the total number of call paths for all functions in the target monitored code. Based on the first execution time and the last execution time, calculate the execution frequency coverage of the target monitoring code within a preset time period.

8. An incremental code coverage testing system, characterized in that, include: The code analysis module is used to analyze the current version and baseline version of the target project's code to identify changed functions; The change function analysis module is used to analyze the scope of influence of the change function to determine the associated code that is directly or indirectly affected by the change function, and to use the change function and associated code as target monitoring code. The execution data acquisition module is used to insert execution acquisition logic into a preset position of the target monitoring code by instrumentation, so as to collect the execution data of the target monitoring code during its operation; The incremental coverage calculation module is used to calculate the incremental coverage of the target monitoring code based on the execution data.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method of any one of claims 1-7.

Images