Statistical method, device and computer equipment for code coverage

Abstract

The application relates to a code coverage statistical method, device and computer equipment, wherein the statistical method comprises the following steps: generating a difference file of source code according to a current version of the source code and a benchmark version of the source code; obtaining a target execution track file corresponding to the current version, and determining first code coverage data corresponding to the current version according to the current version and the target execution track file; wherein the first code coverage data is used for indicating whether each code in the current version is executed; determining code coverage corresponding to the difference file according to the difference file and the first code coverage data, so as to realize coverage rate statistics of changed codes in a version iteration process.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a statistical method, apparatus, and computer device for code coverage. Background Technology

[0002] Code testing has become a core component of the software development process, ensuring code quality and mitigating operational risks. Code coverage, as a key indicator for quantifying test adequacy, characterizes the degree to which test cases cover the execution of the code under test and is widely used in various testing scenarios such as unit testing, integration testing, and system testing.

[0003] However, existing code coverage statistics schemes typically use the entire source code as the statistical caliber. The output test results can only indicate whether the code under test has been executed at the overall level, and cannot perform coverage statistics for code changes during version iteration.

[0004] There is currently no effective solution to the problem that related technologies cannot perform coverage statistics for changed code during version iteration. Summary of the Invention

[0005] This embodiment provides a method, apparatus, and computer device for calculating code coverage, which is intended to perform coverage statistics on changed code during version iteration.

[0006] Firstly, this embodiment provides a method for calculating code coverage, the method comprising:

[0007] Generate a difference file for the source code based on the current version of the source code and the baseline version of the source code;

[0008] Obtain the target execution trajectory file corresponding to the current version, and determine the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file; wherein, the first code coverage data is used to indicate whether each piece of code in the current version is executed;

[0009] Based on the difference file and the first code coverage data, determine the code coverage corresponding to the difference file.

[0010] Secondly, this embodiment provides a code coverage statistics device, the statistics device comprising:

[0011] A generation module is used to generate a difference file for the source code based on the current version of the source code and a base version of the source code.

[0012] The processing module is used to obtain the target execution trajectory file corresponding to the current version, and determine the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file; wherein, the first code coverage data is used to indicate whether each piece of code in the current version is executed;

[0013] The statistics module is used to determine the code coverage rate corresponding to the difference file based on the difference file and the first code coverage data.

[0014] Thirdly, this embodiment provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the code coverage statistical method described in the first aspect above.

[0015] Compared with related technologies, this embodiment provides a method, apparatus, and computer device for calculating code coverage. The method specifically includes: generating a difference file for the source code based on the current version and a baseline version; obtaining a target execution trajectory file corresponding to the current version; and determining first code coverage data corresponding to the current version based on the current version and the target execution trajectory file. The first code coverage data indicates whether each piece of code in the current version has been executed. The method also involves determining the code coverage rate corresponding to the difference file based on the difference file and the first code coverage data. By generating a difference file between the current version and the baseline version of the source code, and combining it with the execution trajectory file to obtain code coverage data, a coverage statistical result specific to the changed code is obtained based on the code coverage data and the difference file. This precisely limits the analysis scope to the actually changed code, thereby achieving coverage statistics for changed code during version iteration.

[0016] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a flowchart of an embodiment of the statistical method for code coverage provided in this application;

[0019] Figure 2 This is a flowchart of Embodiment 2 of the statistical method for code coverage provided in this application;

[0020] Figure 3This is a flowchart of Embodiment 3 of the statistical method for code coverage provided in this application;

[0021] Figure 4 This is a flowchart of Embodiment 4 of the statistical method for code coverage provided in this application;

[0022] Figure 5 This is a flowchart of Embodiment 5 of the statistical method for code coverage provided in this application;

[0023] Figure 6 This is a flowchart of Embodiment Six of the statistical method for code coverage provided in this application;

[0024] Figure 7 This is a flowchart of Embodiment Seven of the statistical method for code coverage provided in this application;

[0025] Figure 8 This is a flowchart of Embodiment 8 of the statistical method for code coverage provided in this application;

[0026] Figure 9 This is a block diagram of the statistical device for code coverage provided in this application. Detailed Implementation

[0027] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0028] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0029] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0030] Figure 1 The flowchart for Embodiment 1 of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 1 The method provided in this embodiment may include the following steps:

[0031] Step S101: Generate a difference file for the source code based on the current version of the source code and the base version of the source code.

[0032] It should be noted that the current version of the source code refers to the software version for which coverage is to be calculated, usually corresponding to the latest development results or the version to be released. The baseline version of the source code, on the other hand, is a historical version used for comparison, which can be the previous release version, the baseline version, etc., and is used to define the scope of changes introduced in this iteration.

[0033] In this step, the difference comparison function provided by code version management tools (such as Git) or a structured comparison method based on abstract syntax trees can be used to perform difference analysis between the current version of the source code and the baseline version of the source code, thereby generating a difference file. The difference file records information including, but not limited to, the files, methods, lines of code, and branch ranges that have changed in the current version relative to the baseline version. The difference file is output in a standardized format (e.g., diffFile, diffMethod) so that subsequent coverage analysis processes can directly read and parse it.

[0034] Step S102: Obtain the target execution trajectory file corresponding to the current version, and determine the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file; wherein, the first code coverage data is used to indicate whether each piece of code in the current version is executed.

[0035] It should be noted that the execution trace file is a raw log file automatically generated by coverage collection tools (such as JaCoCo, Gcov, and lcov) during the test case execution. It records the location information of all code executed during the test execution. The coverage collection tool is usually attached to the running process of the business service under test in the form of an agent or instrumentation component, and records the code execution path in real time during the test execution to form the corresponding execution trace file.

[0036] In this step, target execution trajectory files are collected from the business service instances executing test cases, based on the deployment information corresponding to the current version. For example, in a single-instance scenario, the target execution trajectory file can be obtained based on the address and port of a single instance. Subsequently, the collected target execution trajectory files are parsed and matched in conjunction with the code structure information of the current version of the source code, mapping the execution positions recorded in the target execution trajectory files to the corresponding code units of the current version, thus obtaining the first code coverage data. This first code coverage data can accurately characterize the execution status of each code unit in the current version during this test run.

[0037] It should be understood that the above-described method for determining the first code coverage data corresponding to the current version can be flexibly selected by those skilled in the art based on the actual code coverage analysis method used, and this embodiment does not specifically limit it in this regard.

[0038] Step S103: Determine the code coverage rate corresponding to the difference file based on the difference file and the first code coverage data.

[0039] In this step, all the changed code involved in this iteration recorded in the difference file is traversed, and each changed code is matched item by item with the corresponding execution record in the first code coverage data to determine its coverage status. For each changed code (such as a line of code, branch, or method), it is determined whether it is in the executed set of the first code coverage data. If it is in the executed set of the first code coverage data, it indicates that the changed code has been covered; otherwise, it indicates that it has not been covered. Based on the above item-by-item matching results, the coverage of the changed code in the difference file can be statistically analyzed, and its code coverage rate can be calculated. In specific implementations, different granular statistical methods can be selected according to actual testing needs, such as line coverage rate, branch coverage rate, or method coverage rate. At the same time, based on the coverage of the changed code in the difference file, uncovered methods, uncovered lines, etc., can also be analyzed and output.

[0040] Furthermore, coverage reports focusing on the changed codes in the difference files can be generated based on their coverage status. The output format supports HTML, XML, or other equivalent formats. For example, coverage reports can also be presented in JSON, database records, object storage paths, quality platform pages, and machine-readable access control results.

[0041] The code coverage statistical method provided in this embodiment generates a difference file of the source code based on the current version and the baseline version of the source code; obtains the target execution trajectory file corresponding to the current version; and determines the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file. The first code coverage data indicates whether each piece of code in the current version has been executed. Based on the difference file and the first code coverage data, the code coverage corresponding to the difference file is determined. In this way, by generating a difference file between the current version and the baseline version of the source code, and combining it with the execution trajectory file to obtain code coverage data, and then obtaining coverage statistics results only for the changed code based on the code coverage data and the difference file, the analysis scope is precisely limited to the actually changed code. This achieves coverage statistics for changed code during version iteration, allowing testers to directly view the coverage of newly added or modified methods and lines of code without manual filtering in the full coverage report.

[0042] Figure 2 The flowchart for Embodiment 2 of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 2 Based on the above embodiments, the target execution trajectory file corresponding to the current version is obtained, including:

[0043] Step S201: Obtain the basic execution trajectory files for multiple service instances corresponding to the current version, thus obtaining multiple basic execution trajectory files corresponding to the current version.

[0044] Specifically, for the multiple service instances deployed in the current version, the original execution trajectory files recorded by each instance are collected as the base execution trajectory files. Each base execution trajectory file reflects the code location information covered by the corresponding instance during the test execution process.

[0045] Step S202: Merge multiple basic execution trajectory files corresponding to the current version to obtain the target execution trajectory file.

[0046] Specifically, the collected basic execution trajectory files are merged to obtain the target execution trajectory file. It should be understood that for the same code location, as long as any basic execution trajectory file records that the location has been executed, it will be marked as executed in the merged result.

[0047] The method provided in this embodiment collects basic execution trajectory files from multiple service instances corresponding to the current version and merges these files, enabling the formation of a complete trajectory reflecting the overall test execution status in a distributed deployment scenario. Furthermore, it eliminates the need for manual data retrieval and merging, improving processing efficiency and reducing costs.

[0048] Figure 3 The flowchart for Embodiment 3 of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 3 Based on the above embodiments, according to the current version and the target execution trajectory file, the first code coverage data corresponding to the current version is determined, including:

[0049] Step S301: Obtain the compilation artifacts corresponding to the current version, and extract from the compilation artifacts the first correspondence between each code in the current version and the bytecode instructions after compilation, as well as the second correspondence between the preset probes inserted in the bytecode file corresponding to the current version and the bytecode instructions.

[0050] It should be noted that the current version of the source code generates corresponding compilation artifacts after compilation, such as Java bytecode files (.class files). During the compilation phase, this embodiment pre-instruments the bytecode file, inserting preset probes at corresponding bytecode instruction locations to record whether the code at that location is executed during test execution. Based on the above compilation process, a first correspondence between each code unit in the current version and the compiled bytecode instructions can be established, as well as a second correspondence between each preset probe inserted in the bytecode file and the bytecode instructions.

[0051] Step S302: Obtain the hit status data corresponding to each preset probe from the target execution trajectory file, and determine the coverage status corresponding to each bytecode instruction based on the hit status data corresponding to each preset probe and the second correspondence.

[0052] The target execution trajectory file records the triggering status of all preset probes during the test run, i.e., the hit status data of each preset probe, to reflect whether the corresponding probe was triggered during the test.

[0053] Specifically, based on the second correspondence, the hit status data of each preset probe is mapped to its corresponding bytecode instruction. If a preset probe has a hit record, it is determined that its associated bytecode instruction was executed during the test; if the probe does not produce a hit record, the corresponding bytecode instruction is marked as not executed. In this way, the coverage status of all bytecode instructions under the current version can be accurately determined.

[0054] Step S303: Determine the first code overwrite data corresponding to the current version based on the overwrite status of each bytecode instruction and the first correspondence.

[0055] In this step, based on the first correspondence, the coverage status of each bytecode instruction is mapped to each code unit in the current version. By integrating the execution coverage status of each code unit, the first code coverage data corresponding to the current version is obtained. This first code coverage data can accurately characterize the execution status of each code unit in the current version during this test run.

[0056] The method provided in this embodiment can determine the coverage status of all bytecode instructions in the current version by mapping the hit status data of the preset probe to the bytecode instructions one by one. Then, by combining the correspondence between the source code and the bytecode instructions, the full code coverage data corresponding to the current version can be accurately obtained.

[0057] Figure 4 The flowchart for Embodiment 4 of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 4 Based on the above embodiments, after determining the first code coverage data corresponding to the current version according to the current version and the target execution trajectory file, the statistical method further includes:

[0058] Step S401: Generate the identity identifier corresponding to each current method in the current version.

[0059] In this step, a unique and cross-version stable identity is generated for each method in the current version, so as to accurately identify and match the same method across different versions in the future.

[0060] For example, in one embodiment, for each current method in the current version, the target attribute information corresponding to the current method is obtained; wherein, the target attribute information includes a combination of one or more of the following: source file path (identifying the source file location where the method is located), class name, method name, parameter signature, declaration location (e.g., the method start line number or end line number), and virtual machine descriptor (JVMdescriptor); based on the target attribute information, an identity identifier corresponding to each current method is generated.

[0061] In practice, based on the aforementioned target attribute information, the identity identifier of this method can be generated through preset encoding rules or hash algorithms.

[0062] Step S402: Obtain the historical code coverage data associated with the current version, and for each current method, determine whether there is a historical method in the historical code coverage data that matches the identity identifier based on the identity identifier corresponding to the current method.

[0063] Specifically, historical code coverage data associated with the current version is obtained in advance. This historical code coverage data consists of coverage records accumulated during testing of previous versions. Then, for each method in the current version, its identifier is used as the retrieval basis to search the historical code coverage data for a historical method with the same identifier. It should be understood that "current method" refers to a method included in the current version, while "historical method" refers to a method in a previous version. When both identifiers match, it indicates that the current method and a certain historical method can be identified as the same method across version dimensions.

[0064] Step S403: When there is a historical method matching the identity in the historical code coverage data, determine whether the first method body fingerprint corresponding to the current method is the same as the second method body fingerprint corresponding to the historical method. If the first method body fingerprint and the second method body fingerprint are the same, perform a union operation on the coverage data corresponding to the current method in the first code coverage data and the coverage data corresponding to the historical method in the historical code coverage data to obtain the cumulative coverage data corresponding to the current method.

[0065] When a historical method matching the identity is found in the historical code overlay data, the first method body fingerprint corresponding to the current method and the second method body fingerprint corresponding to the historical method are determined respectively. This embodiment does not specifically limit the calculation method of the method body fingerprint. For example, a hash operation can be performed on the method body source code segment after removing comments and whitespace characters to obtain the method body fingerprint. Another example is calculating the method body fingerprint based on normalized AST, bytecode instruction sequences, control flow graphs, etc.

[0066] Furthermore, the first method body fingerprint is compared with the second method body fingerprint. If the first method body fingerprint and the second method body fingerprint are the same, it indicates that the logic of the method has not changed substantially. Then, the coverage data corresponding to the current method in the first code coverage data is combined with the coverage data corresponding to the historical method in the historical code coverage data to obtain the cumulative coverage data corresponding to the method.

[0067] Step S404: When there is no historical method matching the identity identifier in the historical code coverage data, or when the first method body fingerprint and the second method body fingerprint are different, the coverage data corresponding to the current method is determined as the cumulative coverage data.

[0068] If no historical method matching the identity is found in the historical code coverage data, the coverage data corresponding to the current method is determined as the cumulative coverage data. Alternatively, if a historical method matching the identity exists in the historical code coverage data, and the first method body fingerprint and the second method body fingerprint are different, it indicates that the substantive logic of the method has changed. In this case, the coverage data corresponding to the current method is determined as the cumulative coverage data, meaning only the coverage data obtained in this test is retained, and no historical coverage records are introduced.

[0069] It should be noted that after performing the above cumulative coverage analysis, the method-level and row-level cumulative tables can be updated, and various report pages can be re-rendered, including but not limited to the cumulative report homepage, class list page, and source code coloring page.

[0070] Furthermore, for line-level data, line coverage metrics can be assigned to the corresponding method based on the start and end line numbers of the current method in the source code file, the relative line numbers within the method, statement fingerprints, or source code mapping relationships. It should also be understood that if line-level data is executed in any round of testing within either historical or current coverage data, its cumulative status is marked as covered. If a branch only covers a portion of the path, it is marked as partially covered in the final generated source code coloring page.

[0071] The method provided in this embodiment generates a stable identity for each method, enabling accurate identification of the same method across different versions. It then combines this with method body fingerprint comparison to determine whether the method logic has undergone substantial changes, thereby deciding whether to inherit historical coverage data. For methods that have not changed, a union operation is performed between historical accumulated coverage data and current coverage data. This ensures that covered code in multiple rounds of testing retains its coverage record without repeated execution, allowing testers to focus on continuously supplementing test cases for uncovered logic, effectively reducing the cost of repetitive testing. Simultaneously, for methods with mismatched identity identifiers or changes in substantial logic, their historical coverage data is automatically invalidated and reset to the current test results, preventing the reuse of invalid old coverage data from polluting new code.

[0072] Figure 5 The flowchart for Embodiment 5 of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 5 Based on the above embodiments, historical code coverage data associated with the current version is obtained, including:

[0073] Step S501: Obtain the target statistical logical range corresponding to the current version; wherein, the target statistical logical range includes a combination of one or more of the following: project identifier, code repository identifier, coverage data source, test deployment environment, and module identifier.

[0074] It should be noted that the statistical logical scope is used to distinguish coverage data under different dimensions, specifically including but not limited to the following information dimensions: project identifier (to distinguish different software projects), code repository identifier (to distinguish different code repositories under the same project), coverage data source, test deployment environment, and module identifier (e.g., to distinguish different sub-modules in a project, or to identify multi-module patterns, etc.). These dimensions can be flexibly combined according to actual business needs, aiming to ensure that multiple rounds of test results under the same statistical caliber can be accumulated into the same logical space, and that coverage data between different environments, different modules, or different projects do not contaminate each other.

[0075] Step S502: Perform a hash operation on the target statistical dimension information to obtain the statistical range identifier corresponding to the current version.

[0076] Specifically, the information from each dimension of the target statistical dimension is combined according to preset rules, and then the combined result is hashed using a hash algorithm to obtain the statistical range identifier. The hash algorithms used include, but are not limited to, MD5 and SHA series hashes.

[0077] Step S503: Search for code coverage data associated with statistical range identifiers in the historical coverage database, and identify the code coverage data associated with statistical range identifiers as historical code coverage data.

[0078] In this step, using the aforementioned statistical range identifier as the retrieval key, the code coverage data associated with the statistical range identifier is searched in the pre-built historical coverage database. Subsequently, if code coverage data associated with the statistical range identifier is found, it is extracted from the historical coverage database and used as historical code coverage data. Furthermore, if no code coverage data associated with the statistical range identifier is found, it indicates that no historical coverage data has been accumulated within the current statistical logic range; in this case, a null value or a default value can be returned.

[0079] The method provided in this embodiment defines a multi-dimensional statistical logical range and combines it with hash operations to generate a unique statistical range identifier as a database retrieval index. This enables precise isolation and independent accumulation of historical coverage data across different projects, repositories, environments, and modules, thereby helping to improve the practicality and scalability of coverage statistics methods in complex scenarios such as multiple projects, multiple environments, and multiple rounds.

[0080] Figure 6 The flowchart for Embodiment Six of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 6 Based on the above embodiments, after determining the first code coverage data corresponding to the current version according to the current version and the target execution trajectory file, the statistical method further includes:

[0081] Step S601: Select the target module from the multiple modules in the current version that contains any changed code in the difference file.

[0082] For multi-module projects, it is possible to traverse all modules in the current version and select multiple target modules from them. Each target module contains any changed code in the difference file.

[0083] Step S602: Determine all change codes in each target module based on the difference file.

[0084] Specifically, for each target module selected, all changed code in that target module is extracted from the difference file to clarify the new and modified code in each target module during this iteration.

[0085] Step S603: Based on all the changed codes in each target module and the first code coverage data, determine the second code coverage data corresponding to each target module, and generate a coverage report corresponding to each target module based on the second code coverage data.

[0086] Specifically, for each target module, the modified code in the target module is matched item by item with the corresponding execution records in the first code coverage data to determine its coverage status. For each modified code, it is determined whether it is in the executed set of the first code coverage data. If it is in the executed set of the first code coverage data, it indicates that the modified code has been covered; otherwise, it indicates that it has not been covered. Based on the above item-by-item matching results, the coverage of the modified code in each target module is statistically analyzed, resulting in the second code coverage data for each target module. Then, a coverage report for each target module is generated based on the second code coverage data.

[0087] The method provided in this embodiment filters out target modules with modified codes from multiple modules in the current version, extracts all modified codes for each target module, and then matches the modified codes of each target module with the first code coverage data to obtain the second code coverage data corresponding to each target module. Therefore, when the global master report generation fails or multiple module data conflicts occur, a difference code coverage report can be generated and output by module, improving the stability of the coverage statistics process.

[0088] Figure 7 The flowchart for Embodiment Seven of the statistical method for code coverage provided in this application is shown below. Please refer to... Figure 7 Based on the above embodiments, the current version contains the source code for each preset requirement branch; a difference file is generated based on the current version and the base version, including:

[0089] Step S701: Compare the source code of each preset requirement branch with the base version to obtain the difference range of each preset requirement branch; wherein, the difference range includes the methods, lines of code and code branches that have changed in the branch source code relative to the base version.

[0090] For multi-branch deployment scenarios, each preset requirement branch is split according to the configured branch list, and the difference code coverage corresponding to each preset requirement branch is calculated separately.

[0091] Specifically, the source code of each preset requirement branch is compared with the base version to obtain the difference range of the preset requirement branch. The difference range includes, but is not limited to, the methods, lines of code and code branches that have changed in the source code of the branch relative to the base version.

[0092] Step S702: Generate a difference file corresponding to each preset requirement branch based on the difference range corresponding to each preset requirement branch.

[0093] In this step, after obtaining the difference range corresponding to each preset requirement branch, the changed code information of each preset requirement branch is structurally encapsulated to generate a difference file for each preset requirement branch. Thus, by splitting the statistical subtasks by branch dimension, difference code coverage analysis can be performed on each branch. Furthermore, the execution status information of each branch is recorded in the manifest, including but not limited to each branch's requestStatus, errMsg, reportUrl, log address, and rerun parameters, so that the coverage analysis results, failure diagnosis, and rerun recovery for each branch can be displayed on the front end.

[0094] The method provided in this embodiment compares the source code of each preset requirement branch with the baseline version in a multi-branch deployment scenario to obtain the difference range of each preset requirement branch. Based on the difference range of each preset requirement branch, a difference file is generated for each preset requirement branch. This enables the execution of difference code coverage analysis for each branch, allowing testers to quickly locate the coverage analysis results and execution status of each branch.

[0095] The present embodiment will now be described and illustrated through preferred embodiments.

[0096] Figure 8 The flowchart of Embodiment 8 of the statistical method for code coverage provided in this application is as follows: Figure 8 As shown, the statistical method for this code coverage includes the following steps:

[0097] Step S801: Generate a difference file for the source code based on the current version of the source code and the base version of the source code;

[0098] Step S802: Obtain the basic execution trajectory files for multiple service instances corresponding to the current version, thus obtaining multiple basic execution trajectory files corresponding to the current version;

[0099] Step S803: Merge multiple basic execution trajectory files corresponding to the current version to obtain the target execution trajectory file;

[0100] Step S804: Obtain the compilation artifacts corresponding to the current version, and extract from the compilation artifacts the first correspondence between each code in the current version and the bytecode instructions after compilation, as well as the second correspondence between the preset probes inserted in the bytecode file corresponding to the current version and the bytecode instructions;

[0101] Step S805: Obtain the hit status data corresponding to each preset probe from the target execution trajectory file, and determine the coverage status corresponding to each bytecode instruction based on the hit status data corresponding to each preset probe and the second correspondence.

[0102] Step S806: Determine the first code overwrite data corresponding to the current version based on the overwrite status of each bytecode instruction and the first correspondence.

[0103] Step S807: Determine the code coverage corresponding to the difference file based on the difference file and the first code coverage data.

[0104] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0105] This embodiment also provides a code coverage statistics device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. The terms "module," "unit," "subunit," etc., used below can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0106] Figure 9 This is a structural block diagram of the code coverage statistics device in this embodiment, as shown below. Figure 9 As shown, the device includes:

[0107] The generation module 10 is used to generate a difference file for the source code based on the current version of the source code and the base version of the source code.

[0108] Processing module 20 is used to obtain the target execution trajectory file corresponding to the current version, and determine the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file; wherein, the first code coverage data is used to indicate whether each piece of code in the current version is executed;

[0109] The statistics module 30 is used to determine the code coverage corresponding to the difference file based on the difference file and the first code coverage data.

[0110] Optionally, in one possible implementation, processing module 20 is specifically used for:

[0111] Obtain the basic execution trajectory files for multiple service instances corresponding to the current version, and thus obtain multiple basic execution trajectory files for the current version;

[0112] The target execution trajectory file is obtained by merging multiple basic execution trajectory files corresponding to the current version.

[0113] Optionally, in one possible implementation, processing module 20 is specifically used for:

[0114] Obtain the compilation artifacts corresponding to the current version, and extract from the compilation artifacts the first correspondence between each piece of code in the current version and the bytecode instructions after compilation, as well as the second correspondence between the preset probes inserted in the bytecode file corresponding to the current version and the bytecode instructions;

[0115] Obtain the hit status data corresponding to each preset probe from the target execution trajectory file, and determine the coverage status corresponding to each bytecode instruction based on the hit status data corresponding to each preset probe and the second correspondence.

[0116] Based on the coverage status of each bytecode instruction and the first correspondence, determine the first code coverage data corresponding to the current version.

[0117] Optionally, in one possible implementation, in Figure 9 In addition to this, the device also includes an accumulation module for:

[0118] Generate an identity identifier for each current method in the current version;

[0119] Obtain the historical code coverage data associated with the current version, and for each current method, determine whether there is a historical method in the historical code coverage data that matches the identity identifier based on the identity identifier corresponding to the current method;

[0120] When a historical method matching the identity exists in the historical code coverage data, determine whether the first method body fingerprint corresponding to the current method is the same as the second method body fingerprint corresponding to the historical method. If the first method body fingerprint and the second method body fingerprint are the same, perform a union operation on the coverage data corresponding to the current method in the first code coverage data and the coverage data corresponding to the historical method in the historical code coverage data to obtain the cumulative coverage data corresponding to the current method.

[0121] If no historical method matching the identity is found in the historical code coverage data, or if the fingerprints of the first method body and the second method body are different, the coverage data corresponding to the current method will be determined as the cumulative coverage data.

[0122] Optionally, in one possible implementation, the accumulation module is specifically used for:

[0123] Obtain the target statistical logical range corresponding to the current version; where the target statistical logical range includes a combination of one or more of the following: project identifier, code repository identifier, coverage data source, test deployment environment, and module identifier;

[0124] Perform a hash operation on the target statistical dimension information to obtain the statistical range identifier corresponding to the current version;

[0125] Search the historical coverage database for code coverage data associated with statistical range identifiers, and identify the found code coverage data associated with statistical range identifiers as historical code coverage data.

[0126] Optionally, in one possible implementation, the accumulation module is specifically used for:

[0127] For each current method, obtain the target attribute information corresponding to the current method; the target attribute information includes a combination of one or more of the following: source file path, class name, method name, parameter signature, declaration location, and virtual machine descriptor;

[0128] Based on the target attribute information, generate an identity identifier for each current method.

[0129] Optionally, in one possible implementation, in Figure 9 In addition, the device also includes a report generation module for:

[0130] Filter out the target module from multiple modules in the current version that contains any changed code in the difference files;

[0131] Identify all change codes in each target module based on the difference file;

[0132] Based on all the changed code in each target module and the first code coverage data, determine the second code coverage data for each target module, and generate a coverage report for each target module based on the second code coverage data.

[0133] Optionally, in one possible implementation, module 10 is specifically used for:

[0134] The source code of each preset requirement branch is compared with the base version to obtain the difference range of each preset requirement branch; the difference range includes the methods, lines of code and code branches that have changed in the branch source code compared with the base version;

[0135] Based on the difference range corresponding to each preset requirement branch, generate a difference file corresponding to each preset requirement branch.

[0136] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0137] This embodiment also provides a computer device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0138] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0139] Furthermore, in conjunction with the code coverage statistics methods provided in the above embodiments, this embodiment can also provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the code coverage statistics methods described in the above embodiments.

[0140] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0141] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0142] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0143] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A statistical method for code coverage, characterized in that, The statistical methods include: Generate a difference file for the source code based on the current version of the source code and the baseline version of the source code; Obtain the target execution trajectory file corresponding to the current version, and determine the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file; wherein, the first code coverage data is used to indicate whether each piece of code in the current version is executed; Based on the difference file and the first code coverage data, determine the code coverage corresponding to the difference file.

2. The statistical method for code coverage according to claim 1, characterized in that, The step of obtaining the target execution trajectory file corresponding to the current version includes: Obtain the basic execution trajectory files under multiple service instances corresponding to the current version to obtain multiple basic execution trajectory files corresponding to the current version; The target execution trajectory file is obtained by merging multiple basic execution trajectory files corresponding to the current version.

3. The statistical method for code coverage according to claim 1, characterized in that, The step of determining the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file includes: Obtain the compilation artifacts corresponding to the current version, and extract from the compilation artifacts the first correspondence between each code in the current version and the bytecode instructions after compilation of each code, and the second correspondence between the preset probe inserted in the bytecode file corresponding to the current version and the bytecode instructions; Obtain the hit status data corresponding to each preset probe from the target execution trajectory file, and determine the coverage status corresponding to each bytecode instruction based on the hit status data corresponding to each preset probe and the second correspondence. Based on the coverage status of each bytecode instruction and the first correspondence, the first code coverage data corresponding to the current version is determined.

4. The statistical method for code coverage according to claim 1, characterized in that, After determining the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file, the method further includes: Generate an identity identifier for each current method in the current version; Obtain the historical code coverage data associated with the current version, and for each current method, determine whether there is a historical method in the historical code coverage data that matches the identity identifier based on the identity identifier corresponding to the current method; When a historical method matching the identity is found in the historical code coverage data, it is determined whether the first method body fingerprint corresponding to the current method is the same as the second method body fingerprint corresponding to the historical method. If the first method body fingerprint and the second method body fingerprint are the same, the coverage data corresponding to the current method in the first code coverage data and the coverage data corresponding to the historical method in the historical code coverage data are combined to obtain the cumulative coverage data corresponding to the current method. When there is no historical method matching the identity in the historical code coverage data, or when the first method body fingerprint and the second method body fingerprint are different, the coverage data corresponding to the current method is determined as the cumulative coverage data.

5. The statistical method for code coverage according to claim 4, characterized in that, The step of obtaining the historical code coverage data associated with the current version includes: Obtain the target statistical logical range corresponding to the current version; wherein, the target statistical logical range includes a combination of one or more of the following: project identifier, code repository identifier, coverage data source, test deployment environment, and module identifier; Perform a hash operation on the target statistical dimension information to obtain the statistical range identifier corresponding to the current version; The code coverage data associated with the statistical range identifier is retrieved from the historical coverage database, and the retrieved code coverage data associated with the statistical range identifier is identified as the historical code coverage data.

6. The statistical method for code coverage according to claim 4, characterized in that, The generation of the identity identifier corresponding to each current method in the current version includes: For each current method, obtain the target attribute information corresponding to the current method; wherein, the target attribute information includes a combination of one or more of the following: source code file path, class name, method name, parameter signature, declaration location, and virtual machine descriptor; Based on the target attribute information, generate an identity identifier corresponding to each current method.

7. The statistical method for code coverage according to claim 1, characterized in that, After determining the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file, the method further includes: Select the target module containing any changed code in the difference file from among the multiple modules in the current version; Based on the difference file, determine all the change codes in each of the target modules; Based on all the changed code in each target module and the first code coverage data, determine the second code coverage data corresponding to each target module, and generate a coverage report corresponding to each target module based on the second code coverage data.

8. The statistical method for code coverage according to claim 1, characterized in that, The current version is the source code of the branch corresponding to each preset requirement branch; The step of generating a difference file based on the current version and the baseline version includes: The source code of each preset requirement branch is compared with the base version to obtain the difference range of each preset requirement branch; wherein, the difference range includes the methods, lines of code and code branches in the source code of the branch that have changed relative to the base version; Based on the difference range corresponding to each preset requirement branch, generate a difference file corresponding to each preset requirement branch.

9. A statistical device for code coverage, characterized in that, The statistical device includes: A generation module is used to generate a difference file for the source code based on the current version of the source code and a base version of the source code. The processing module is used to obtain the target execution trajectory file corresponding to the current version, and determine the first code coverage data corresponding to the current version based on the current version and the target execution trajectory file; wherein, the first code coverage data is used to indicate whether each piece of code in the current version is executed; The statistics module is used to determine the code coverage rate corresponding to the difference file based on the difference file and the first code coverage data.

10. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the steps of the statistical method for code coverage as described in any one of claims 1 to 8.

Images