Incremental code coverage rate calculation method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computer testing, in particular to an incremental code coverage rate calculation method which comprises the following steps: executing a test case on a current version code, and collecting code test coverage information; comparing the baseline version code with the current version code to obtain a change code; based on a baseline version code, performing semantic equivalence analysis on the change code to obtain a logic change code, the semantic equivalence analysis being used for filtering change codes of non-logic factors; and calculating an incremental code coverage rate according to the logic change code and the code test coverage information, wherein the incremental code coverage rate comprises a change line coverage rate and a change link coverage rate. According to the multi-dimensional analysis method, coverage rate evaluation is more scientific and comprehensive, developers can better find test blind spots and potential defects, and therefore the software quality is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer testing technology, and in particular to a method, device, electronic device and storage medium for calculating incremental code coverage. Background Art

[0002] In the software development process, code coverage is an important indicator to measure the quality of software testing. Code coverage refers to the proportion of source code covered by test cases during the statistical test execution process. High code coverage usually means that test cases can fully check various parts of the code, thereby reducing the risk of potential defects.

[0003] However, with the continuous increase and modification of code during the development process, existing code coverage tools, especially those for measuring incremental code coverage, still have certain limitations. First, when developers make certain non-semantic code changes, these changes usually do not affect the functionality, but existing tools often find it difficult to identify the nature of these changes, resulting in distortion of incremental code coverage and failure to truly reflect the test coverage of the newly modified parts. Second, existing incremental code coverage analysis mostly focuses on coarse coverage granularity and lacks precise analysis of code change details, resulting in limited information reflected in incremental coverage reports, making it difficult to provide developers with sufficient reference, which in turn affects the improvement of their code quality. Summary of the invention

[0004] In view of this, an embodiment of the present application provides a method, device, electronic device and storage medium for calculating incremental code coverage, which are used to solve at least one technical problem.

[0005] An embodiment of the present application provides a method for calculating incremental code coverage, including: executing test cases on a current version of code, collecting code test coverage information, and the code test coverage information is used to indicate the execution status of the code; comparing a baseline version of code with a current version of code to obtain a change code; based on the baseline version of code, performing a semantic equivalence analysis on the change code to obtain a logical change code, and the semantic equivalence analysis is used to filter the change code of non-logical factors; calculating an incremental code coverage rate based on the logical change code and the code test coverage information, and the incremental code coverage rate includes: a change line coverage rate and a change link coverage rate, and the change line coverage rate is used to indicate the execution status of the test case of the logical change code, and the change link coverage rate is used to indicate the execution status of the test case of the context link code affected by the logical change code.

[0006] According to the method described above, the steps for calculating the change link coverage include: collecting the context link code affected by the logic change code in the current version code and counting the total number of context link code lines; calculating the number of coverage link lines based on the context link code and code test coverage information, wherein the number of coverage link lines represents the number of code lines in the context link where the test cases have been executed; and calculating the change link coverage based on the total number of context link code lines and the number of coverage link lines.

[0007] In the above method, the calculation formula of the changed link coverage is:

[0008] Change link coverage rate = number of covered link rows / total number of context link rows × 100%.

[0009] As described above, the steps for calculating the change line coverage include: counting the total number of changed lines of the logic change code; calculating the number of covered change lines based on the logic change code and the code test coverage information, wherein the number of covered change lines represents the number of code lines in the logic change code on which the test cases have been executed; and calculating the change line coverage based on the number of covered change lines and the total number of changed lines.

[0010] The semantic equivalence analysis described in the method described above includes: comparing the changed code with the baseline version code, identifying and filtering out formatted difference codes, wherein the formatted difference includes one or more of spaces, comments, and line breaks; and / or comparing the changed code after normalization with the baseline version code, identifying and filtering out equivalent difference codes in the changed code; and / or comparing the changed code after logical segmentation with the baseline version code, identifying and filtering out equivalent difference codes in the changed code.

[0011] As described above, the semantic equivalence analysis also includes: parsing both the changed code and the baseline version code into abstract syntax trees and extracting the syntax structure; comparing the abstract syntax trees of the changed code and the baseline version code, identifying and filtering out equivalent difference codes in the changed code; comparing the syntax structures of the changed code and the baseline version code, identifying and filtering out equivalent difference codes in the changed code.

[0012] The method as described above further includes: parsing code test coverage information to obtain the number of covered code lines and the total number of lines of the current version of the code; calculating the full code coverage rate based on the number of covered code lines and the total number of lines of the current version of the code; and writing the full code coverage rate and the incremental code coverage rate into the same coverage report.

[0013] According to another aspect of the present application, a device for calculating incremental code coverage is proposed, including: a test module, used to execute test cases on the current version code and collect code test coverage information, wherein the code test coverage information is used to represent the execution status of the code; a comparison module, used to compare the baseline version code and the current version code to obtain the changed code; an equivalence analysis module, used to perform semantic equivalence analysis on the changed code based on the baseline version code to obtain the logical change code, wherein the semantic equivalence analysis is used to filter the changed code of non-logical factors; a calculation module, used to calculate the incremental code coverage based on the logical change code and the code test coverage information, wherein the incremental code coverage includes: change line coverage and change link coverage, wherein the change line coverage is used to represent the execution status of the tested case of the logical change code, and the change link coverage is used to represent the execution status of the tested case of the context link code affected by the logical change code.

[0014] According to another aspect of the present application, an electronic device is provided, which includes a processor and a memory, wherein a computer program instruction set is stored in the memory, and when the processor executes the computer program instruction set in the memory, the incremental code coverage calculation method as described above is implemented.

[0015] According to another aspect of the present application, a computer-readable storage medium is provided, wherein a computer program instruction set is stored on the computer-readable storage medium, and when the computer program instruction set is executed by a processor, the incremental code coverage calculation method as described above is implemented.

[0016] In the method of the present application, by introducing semantic equivalence analysis, the logical properties of code changes can be effectively identified, and code changes caused by non-logical factors such as format adjustment, comment modification or space change can be filtered out. This process reduces the interference of irrelevant changes on the calculation of incremental code coverage, so that the calculation results more truly reflect the test coverage of actual logic changes, thereby improving the reliability of coverage indicators. Furthermore, this method measures test coverage from different granularities by calculating the change line coverage and change link coverage separately. The change line coverage directly reflects the test coverage of the logic change code and provides basic coverage information; the change link coverage further analyzes the potential impact of the logic change on the context link, supplementing the problem of insufficient attention to the indirect impact part in the traditional coverage calculation. This multi-dimensional analysis method makes coverage evaluation more scientific and comprehensive, which helps developers better discover test blind spots and potential defects, thereby improving software quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The preferred embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0018] Figure 1 It is a flow chart of a method for calculating incremental code coverage according to an embodiment of the present application.

[0019] Figure 2 It is a flow chart of a method for calculating a change link coverage rate according to an embodiment of the present application.

[0020] Figure 3 It is a flow chart of a method for calculating changed row coverage according to an embodiment of the present application.

[0021] Figure 4 It is a structural diagram of using the JaCoCo tool to perform code coverage according to an embodiment of the present application.

[0022] Figure 5 It is a schematic diagram of a coverage comprehensive report interface according to an embodiment of the present application.

[0023] Figure 6 A schematic diagram of the structure of an incremental code coverage calculation device according to an embodiment of the present application.

[0024] Figure 7 It is a schematic diagram of the hardware structure principle of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] In the following detailed description, reference may be made to the various specification drawings that are part of the present application and are used to illustrate specific embodiments of the present application. In the accompanying drawings, similar reference numerals describe substantially similar components in different figures. The various specific embodiments of the present application are described below in sufficient detail so that a person of ordinary skill in the art with relevant knowledge and skills in the art can implement the technical solutions of the present application. It should be understood that other embodiments may also be used or structural, logical or electrical changes may be made to the embodiments of the present application.

[0027] The code coverage of this application includes full code coverage and incremental code coverage. Full code coverage is the ratio of the amount of code covered by the test to the total amount of code after testing the entire code base. Full code coverage is usually used to measure the comprehensiveness of the entire project test, helping developers identify untested code parts in order to improve test cases.

[0028] Incremental code coverage focuses on newly added or modified code parts, and refers to the proportion of these codes covered in tests. It aims to reflect the test coverage of the code changes and is usually used to evaluate the test quality of new or changed code in development iterations. Incremental code coverage is particularly important for continuous integration and continuous delivery scenarios, helping to ensure that each change has a high test coverage rate, thereby reducing the risk of introducing defects.

[0029] The test case of this application is a set of conditions, input data and expected results designed to verify whether the software system or application meets the requirements and design expectations. It is the basic unit of software testing, which is used to describe the functions or scenarios that need to be tested, and the behavior that the program should exhibit under specific conditions. Among them, test cases include unit test cases and integration test cases.

[0030] Figure 1 FIG. 1 is a flow chart of a method for calculating incremental code coverage according to an embodiment of the present application. Figure 1 As shown, the method includes:

[0031] Step S110, executing test cases on the current version of the code, and collecting code test coverage information, wherein the code test coverage information is used to indicate the execution status of the code;

[0032] Step S120, comparing the baseline version code with the current version code to obtain a change code;

[0033] Step S130, based on the baseline version code, performing semantic equivalence analysis on the change code to obtain a logical change code, wherein the semantic equivalence analysis is used to filter the change code of non-logical factors;

[0034] Step S140, calculate the incremental code coverage based on the logic change code and code test coverage information, the incremental code coverage includes: change line coverage and change link coverage, the change line coverage is used to indicate the execution status of the test case of the logic change code, and the change link coverage is used to indicate the execution status of the test case of the context link code affected by the logic change code.

[0035] In step S110, based on the current version of the code, the pre-designed test cases are executed, and the code test coverage information is collected through a code coverage tool (such as JaCoCo). The code test coverage information is used to indicate the execution status of the current version of the code during the test case execution process, including the executed code lines, branches, and conditions. This information provides basic data support for the subsequent calculation of incremental code coverage.

[0036] In step S120, the current version code is compared with the baseline version code to identify the newly added or modified code parts in the current version. These codes are collectively referred to as changed codes. Version comparison can be achieved through a difference analysis tool (such as Gitdiff), and the output of the changed code includes information such as the changed code lines and their locations.

[0037] In step S130, semantic equivalence analysis is performed on the changed code based on the baseline version code and the current version code. This analysis identifies the actual logical meaning of the changed code and filters out the changed code caused by non-logical factors, such as format adjustment, comment modification, or space addition and deletion, so that the output logic change code more accurately reflects the changed part of the code logic.

[0038] In step S140, the incremental code coverage is calculated based on the logic change code and the code test coverage information collected in step S110. In this embodiment, the incremental code coverage includes the following two dimensions:

[0039] Change Line Coverage: used to indicate the execution of logic change code by test cases. Change Trace Coverage: used to indicate the execution of context trace code affected by logic change code by test cases. Context trace refers to the code path that is directly or indirectly affected by logic change code.

[0040] In the method of the present application, by introducing semantic equivalence analysis, the logical attributes of code changes can be effectively identified, and code changes caused by non-logical factors such as format adjustment, comment modification, or space change can be filtered out. This process reduces the interference of irrelevant changes on the calculation of incremental code coverage, so that the calculation results more truly reflect the test coverage of actual logical changes, thereby improving the reliability of the coverage index.

[0041] Furthermore, this method measures test coverage at different granularities by calculating the change line coverage and change link coverage respectively. The change line coverage directly reflects the test coverage of the logic change code and provides basic coverage information; the change link coverage further analyzes the potential impact of the logic change on the context link, supplementing the problem of insufficient attention to the indirect impact part in traditional coverage calculation. This multi-dimensional analysis method makes coverage evaluation more scientific and comprehensive, helping developers to better discover test blind spots and potential defects, thereby improving software quality.

[0042] Figure 2 FIG. 1 is a flow chart of a method for calculating a change link coverage rate according to an embodiment of the present application. Figure 2 As shown, the method includes:

[0043] Step S210, collecting the context link codes affected by the logic change code in the current version code and counting the total number of lines of the context link codes;

[0044] Step S220, calculating the number of coverage link lines according to the context link code and the code test coverage information, wherein the number of coverage link lines represents the number of code lines in which the test case has been executed in the context link;

[0045] Step S230: Calculate the changed link coverage rate according to the total number of context link rows and the number of covered link rows.

[0046] The calculation formula for changing the link coverage is:

[0047] Change link coverage rate = number of covered link rows / total number of context link rows × 100%.

[0048] In step S210, based on the logic change code, analyze its impact on the relevant context links in the current version code. The context link includes: dependent function call chains, conditional branches or other associated modules. Through static analysis tools or code dependency analysis methods, collect all context link codes affected by the logic change, and count the number of code lines contained in the context link, which is recorded as the total number of context link code lines.

[0049] In step S220, the code test coverage information collected in step S110 is used to determine the number of code lines in the context link that have executed the test case, which is recorded as the number of coverage link lines. The number of coverage link lines reflects the part of the context link code that is affected by the logic change and is covered by the test, providing key data support for subsequent coverage calculations.

[0050] In step S230, the change link coverage is used to quantify the test coverage of the context link code by the logic change code, reflecting whether the links directly or indirectly affected by the code caused by the logic change have been fully tested.

[0051] Through the above method, this application can further evaluate the potential impact of logic changes on code context and its coverage based on the calculation of change line coverage. This more comprehensive analysis method provides strong support for developers to identify potential test blind spots and optimize test case design, which helps to improve the quality and stability of software code.

[0052] When calculating code coverage, path coverage may be calculated. Path coverage is a measure of code coverage that measures the degree of coverage of program execution paths by test cases. It focuses on all possible execution paths in the program, including paths under complex control flows such as conditional branches and loops. The goal of path coverage is to verify whether the test cases cover all possible paths in the program to detect logical errors or abnormalities hidden in specific paths.

[0053] In contrast, change link coverage is a coverage metric designed for logic change code, and is mainly used to measure the execution of context links (related code affected by logic changes) caused by logic change code by test cases. Its core goal is to evaluate whether the indirect impact of the change code on the context has been fully tested. The scope of the context link is determined by the direct impact of the logic change code (such as function calls, dependencies, etc.), rather than covering all execution paths of the program. Therefore, the change link coverage of this application is completely different from the path coverage.

[0054] Figure 3 FIG. 1 is a flow chart of a method for calculating the changed row coverage rate according to an embodiment of the present application. Figure 3 As shown, the method includes:

[0055] Step S310, counting the total number of changed lines of the logic change code;

[0056] Step S320, calculating the number of coverage change lines according to the logic change code and the code test coverage information, where the number of coverage change lines represents the number of code lines in the logic change code on which the test cases have been executed;

[0057] Step S330, calculating the changed row coverage rate according to the number of covered changed rows and the total number of changed rows.

[0058] The calculation formula for the changed row coverage rate is:

[0059] Change row coverage rate = number of covered change rows / total number of changed rows × 100%.

[0060] In step S310, based on the logic change code extracted in step S130, the number of code lines contained therein is counted and recorded as the total number of changed lines. The total number of changed lines is a quantitative indicator of the scale of the logic change code, reflecting the amount of code added or modified in the current version relative to the baseline version.

[0061] In step S320, based on the code test coverage information collected in step S110, the number of code lines executed by the test case in the logic change code is determined, which is recorded as the number of covered change lines. The number of covered change lines is a key indicator for measuring the degree of test coverage of the logic change code, which can be achieved by comparing the line number of the logic change code with the coverage information.

[0062] In step S330, the change line coverage is used to quantify the proportion of logic change code executed by test cases, which is an important indicator for evaluating incremental code coverage. Through the above steps, this method can clearly reflect the test coverage of logic change code. Compared with the full coverage, the change line coverage focuses more on the newly added or modified code parts, providing targeted support for code quality assessment in development iterations. This refined coverage analysis method helps the development team optimize test cases and improve testing efficiency and code quality during the software development process.

[0063] According to one embodiment of the present application, semantic equivalence analysis includes:

[0064] Comparing the changed code with the baseline version code, identifying and filtering out code with formatting differences, wherein the formatting differences include one or more of spaces, comments, and line breaks; and / or

[0065] Compare the normalized changed code with the baseline version code, identify and filter out equivalent difference codes in the changed code; and / or

[0066] Compare the changed code after logical segmentation with the baseline version code, identify and filter out equivalent difference codes in the changed code.

[0067] Formatting differences include spaces, such as extra or missing spaces at the beginning or end of a line, or in the code; comments, such as new, modified, or deleted comments; and line breaks, such as changes in the number of lines caused by code line splitting or merging. If these formatting differences are identified, they are considered non-logically changed code and filtered out to avoid interfering with the incremental code coverage calculation due to these changes.

[0068] When normalizing, the variables and functions in the code are unified as placeholders, and non-logical change codes are identified, such as differences in the case of variable or function names, and differences in code structure rearranged according to the standard format. These differences may be non-substantial changes caused by different code writing styles. Non-logical change codes are treated as equivalent difference codes and filtered out. For example, all variables are replaced with general tags such as VAR1 and VAR2, and function names are replaced with FUNC1 and FUNC2, etc.

[0069] The changed code is segmented according to the logical structure, for example, by statements, conditional expressions or functions. Then these logical units are compared with the corresponding parts of the baseline version code to further identify equivalent difference codes. These differences may be, for example, functionally equivalent codes but with different expressions (for example, if(a == true) and if(a)). Through logical segmentation analysis, logically equivalent changed codes can be identified more deeply, thereby further filtering out non-logical changed codes.

[0070] According to another embodiment of the present application, the semantic equivalence analysis further includes:

[0071] Parse both the changed code and the baseline version code into abstract syntax trees and extract the syntax structure;

[0072] Compare the abstract syntax trees of the changed code and the baseline version code, identify and filter out equivalent difference codes in the changed code;

[0073] Compare the syntax structure of the changed code and the baseline version code, identify and filter out equivalent difference codes in the changed code.

[0074] An abstract syntax tree (AST) is a tree model that represents the structure of code and can capture the syntax structure of the code and the relationship between its parts. By using a programming language parser (such as Eclipse JDT for Java or the ast module or javaparser tool for Python), the changed code and the baseline version code are subjected to lexical analysis and syntax analysis to generate their own abstract syntax trees.

[0075] Extract the grammatical structure corresponding to each node from the generated abstract syntax tree, including but not limited to:

[0076] Statement nodes: such as variable declarations, function calls, conditional statements, etc.

[0077] Expression nodes: such as arithmetic expressions, logical expressions, conditional operators, etc.;

[0078] Control flow nodes: such as if, for, while and other control structures;

[0079] Function and method nodes: including function definition, return value, parameter list, etc. After extracting these grammatical structures, they can be used as the basis for comparison and analysis.

[0080] Compare the abstract syntax trees generated by the changed code and the baseline version code, focusing on the differences between the nodes. By comparing the nodes of the tree, you can identify the differences in syntax between the changed code and the baseline version code. These differences include but are not limited to: changes in variable or function names; changes in whitespace characters; minor adjustments to the order of statements, etc.

[0081] By comparing the grammatical structure of the changed code and the baseline version code, we filter out those parts that have differences in grammatical structure but no semantic changes. These differences do not affect the program functionality and therefore need to be removed from the changed code to ensure that the calculated incremental code coverage reflects the functional changes.

[0082] The above method not only compares the nodes of the abstract syntax tree, but also conducts in-depth analysis of specific syntax units. For syntax structures that may have multiple equivalent writing methods, standardized comparisons are performed to filter out equivalent difference codes caused by format or style differences. This method effectively avoids the interference of non-logical differences in the code on the calculation of incremental code coverage, ensuring that the incremental code coverage reflects only actual logical changes. This semantic equivalence analysis method not only improves the accuracy of incremental code coverage calculations, but also provides developers with a more reliable test coverage assessment.

[0083] Optionally, after step S140, the method further includes:

[0084] Parse the code test coverage information to obtain the number of covered code lines and the total number of lines of the current version of the code;

[0085] Calculate the full code coverage rate based on the number of covered code lines and the total number of lines of the current version code;

[0086] Write full code coverage and incremental code coverage into the same coverage report.

[0087] In order to further calculate the full code coverage, you first need to parse the code test coverage information, extract the number of code lines actually executed in the current version of the code from the test coverage information, and count the total number of lines in the current version of the code, including all valid code lines. Then, calculate the full code coverage based on the number of covered code lines and the total number of lines in the current version of the code. The full code coverage is used to measure whether all code lines in the current version of the code are covered by test cases. The calculation formula is as follows:

[0088] Full code coverage = number of covered code lines / total number of lines of code in the current version × 100%.

[0089] Finally, the full code coverage is written into the coverage report together with the previously calculated incremental code coverage. The formats of the coverage report include but are not limited to HTML and XML.

[0090] This solution combines full code coverage and incremental code coverage into one report, which only requires generating two types of coverage data in one analysis, thus avoiding repeated test execution and greatly saving time. In addition, generating full code coverage reports and incremental code coverage reports separately will take up more disk space, especially for large projects, whose test coverage data volume may be large. This solution significantly reduces the storage requirements of the report and saves storage resources by combining the two types of coverage data into the same report.

[0091] The above describes the implementation method and advantages of the embodiments of the present application through multiple embodiments. The following describes the specific processing process of the embodiments of the present application in detail with specific examples. This application uses JaCoCo as a tool for measuring Java code coverage to introduce the method of calculating code coverage in this application.

[0092] As a tool for measuring Java code coverage, JaCoCo has been widely used in the Java development community due to its high accuracy, support for multiple testing frameworks (such as JUnit, TestNG, etc.), and integration with common build tools (such as Maven, Gradle).

[0093] Figure 4 1 is a schematic diagram of a structure for performing code coverage using the JaCoCo tool according to an embodiment of the present application. Figure 4 As shown, the JaCoCo tool is deployed in the server to collect code coverage data at runtime. The following are the detailed calculation steps:

[0094] (1) Execute test cases

[0095] After the software is deployed, the full set of test cases for the project is first executed. This includes unit tests, integration tests, etc. to ensure that all functions work as expected. Testing is performed to verify the correctness of the code and provide necessary execution data for subsequent steps.

[0096] (2) Obtaining full code coverage

[0097] Use the Jacoco tool to process the current version of the code through the instrumentation technology and insert probes to collect the execution trace of the program. Based on this data, Jacoco can generate a coverage report containing full code execution information, supporting multiple formats such as HTML and XML, and showing the execution status of all codes in detail.

[0098] (3) Code comparison and incremental analysis

[0099] Select two code versions to be compared: usually the baseline version of the code for production operation and the current version of the code (the version under test). Compare the two versions and identify the incremental code parts, which usually include new package names, classes, methods, and new or modified lines of code. Then, perform in-depth semantic analysis based on the baseline version code and these incremental code lines to determine whether the code changes are functionally equivalent. If it is judged to be equivalent, this part of the code will be marked in the report to indicate that it can be ignored; otherwise, it will be highlighted. Finally, these marks are then re-rendered into the coverage report.

[0100] Based on the analysis in step (3), the coverage of the incremental code is calculated and merged with the coverage of the full code. By using the merging algorithm, a comprehensive report is finally formed, which shows the coverage of both the incremental code and the full code. The coverage of the incremental code includes the coverage of the changed lines and the coverage of the changed links.

[0101] Figure 5 Schematic diagram of the coverage comprehensive report interface according to an embodiment of the present application. Figure 5 As shown, the comprehensive coverage report includes information related to the full code coverage 510 and information related to the incremental code coverage 520. The relevant information of the full code coverage 510 includes: full code coverage, missed instructions, missed branches and other data. The incremental code coverage 520 includes: change line coverage (Change LineCov.) and change trace line coverage (Change Trace Cov.). Figure 5 It can be seen that the full code coverage and incremental code coverage are aggregated into the same report, which improves the user's reading efficiency.

[0102] From the above method, it can be seen that this technical solution can combine the full code coverage report and the incremental code coverage report into one, which not only saves about half of the reporting time and the disk space occupied by the report, but also reduces the cost of reading the report for users. Furthermore, this technical solution uses semantic equivalence analysis when analyzing incremental code, which can filter out some interference noise and improve the accuracy of the analysis.

[0103] Corresponding to the method embodiment of the present application, the present application also provides a device for calculating incremental code coverage, such as Figure 6 As shown, the incremental code computing device 100 includes:

[0104] The test module 110 is used to obtain test cases from the test case library, obtain the current version of the code from the code library, execute the test cases on the current version of the code, and collect code test coverage information, where the code test coverage information is used to indicate the execution status of the code;

[0105] A comparison module 120 is used to obtain a baseline version code and a current version code in a code library, compare the baseline version code and the current version code, and obtain a change code;

[0106] An equivalence analysis module 130 is used to perform semantic equivalence analysis on the change code based on the baseline version code to obtain a logical change code, wherein the semantic equivalence analysis is used to filter the change code of non-logical factors;

[0107] The calculation module 140 is used to calculate the incremental code coverage based on the logic change code and the code test coverage information. The incremental code coverage includes: change line coverage and change link coverage. The change line coverage is used to indicate the execution status of the test cases of the logic change code, and the change link coverage is used to indicate the execution status of the test cases of the context link code affected by the logic change code.

[0108] Figure 7 It is a schematic diagram of the hardware structure principle of an electronic device according to an embodiment of the present application. The electronic device can be implemented as a server or other various terminal devices, such as a desktop personal computer, a tablet computer, a laptop computer, a mobile phone, etc., including a processor 601 and a memory 602. The memory 602 stores a program instruction set. When the processor 601 executes the program instruction set on the memory 602, any of the aforementioned recommendation information generation methods is implemented.

[0109] Specifically, the processor 601 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiment of the present invention.

[0110] The memory 602 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 602 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 602 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 602 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 602 is a non-volatile solid-state memory.

[0111] The memory may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Therefore, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the recommendation information generation method provided by the present invention.

[0112] In one example, the electronic device may further include a communication interface 603 and a bus 604. The processor 601, the memory 602, and the communication interface 603 are connected through the bus 604 and complete the communication between each other. The communication interface 603 is mainly used to realize the communication between the modules, devices, units and / or devices in the embodiment of the present invention. The bus 604 includes hardware, software or both, and couples the components of the online data traffic billing device to each other. For example, but not limitation, the bus may include an accelerated graphics port (AGP) or other graphics bus, an enhanced industrial standard architecture (EISA) bus, a front-end bus (FSB), a hypertransport (HT) interconnect, an industrial standard architecture (ISA) bus, an infinite bandwidth interconnect, a low pin count (LPC) bus, a memory bus, a micro channel architecture (MCA) bus, a peripheral component interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a serial advanced technology attachment (SATA) bus, a video electronics standard association local (VLB) bus or other suitable buses or a combination of two or more of these. Where appropriate, the bus 604 may include one or more buses. Although embodiments of the present invention describe and illustrate a particular bus, the present invention contemplates any suitable bus or interconnect.

[0113] The present invention also provides a computer-readable storage medium having computer program instructions stored thereon, and the computer program instructions can be executed by a processor to implement any of the incremental code coverage calculation methods in the aforementioned embodiments. The computer-readable storage medium can be any medium that can tangibly contain or store computer-executable instructions for use by or in combination with an instruction execution system, device, and apparatus. The storage medium can be a transient computer-readable storage medium or a non-transient computer-readable storage medium. Non-transient computer-readable storage media may include, but are not limited to, magnetic storage devices, optical storage devices, and / or semiconductor storage devices. Examples of such storage devices include, for example, magnetic disks, optical disks based on CD, DVD, or Blu-ray technology, and persistent solid-state memories such as flash memory, solid-state drives, and the like.

[0114] The present invention also provides a computer program product, which includes a set of computer program instructions, and when the computer program instruction set is executed by a processor, it implements any one of the methods for calculating incremental code coverage in the aforementioned embodiments. The computer program product includes but is not limited to application installation packages published on websites and application stores, application plug-ins, and small programs that can be run in certain applications.

[0115] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0116] The above embodiments are only used to illustrate the present invention, but not to limit the present invention. Ordinary technicians in the relevant technical field can make various changes and modifications without departing from the scope of the present invention. Therefore, all equivalent technical solutions should also fall within the scope of the present invention.

Claims

1. A method for calculating incremental code coverage, characterized in that: include: Execute test cases on the current version of the code and collect code test coverage information, where the code test coverage information is used to indicate the execution status of the code; Compare the baseline version code with the current version code to obtain the changed code; Based on the baseline version code, a semantic equivalence analysis is performed on the change code to obtain a logical change code, wherein the semantic equivalence analysis is used to filter the change code of non-logical factors; The incremental code coverage is calculated based on the logic change code and code test coverage information. The incremental code coverage includes: change line coverage and change link coverage. The change line coverage is used to indicate the execution status of the test cases of the logic change code, and the change link coverage is used to indicate the execution status of the test cases of the context link code affected by the logic change code.

2. The method according to claim 1, characterized in that The calculation step of changing the link coverage includes: Collect the context link codes affected by the logic change code in the current version code and count the total number of context link code lines; Calculate the number of coverage link lines according to the context link code and code test coverage information, where the number of coverage link lines represents the number of code lines in which the test case has been executed in the context link; The change link coverage is calculated based on the total number of context link code lines and the number of covered link lines.

3. The method according to claim 2, characterized in that The calculation formula of the changed link coverage is: Change link coverage rate = number of covered link rows / total number of context link rows × 100%.

4. The method according to claim 1, characterized in that: The calculation steps of the changed row coverage ratio include: Count the total number of changed lines of logic change code; Calculate the number of coverage change lines according to the logic change code and the code test coverage information, where the number of coverage change lines represents the number of code lines in the logic change code on which the test cases have been executed; The changed line coverage rate is calculated based on the number of covered changed lines and the total number of changed lines.

5. The method according to claim 1, characterized in that The semantic equivalence analysis includes: Comparing the changed code with the baseline version code, identifying and filtering out code with formatting differences, wherein the formatting differences include one or more of spaces, comments, and line breaks; and / or Compare the normalized changed code with the baseline version code, identify and filter out equivalent difference codes in the changed code; and / or Compare the changed code after logical segmentation with the baseline version code, identify and filter out equivalent difference codes in the changed code.

6. The method according to claim 1, characterized in that The semantic equivalence analysis also includes: Parse both the changed code and the baseline version code into abstract syntax trees and extract the syntax structure; Compare the abstract syntax trees of the changed code and the baseline version code, identify and filter out equivalent difference codes in the changed code; Compare the syntax structure of the changed code and the baseline version code, identify and filter out equivalent difference codes in the changed code.

7. The method according to claim 1, characterized in that Further including: Parse the code test coverage information to obtain the number of covered code lines and the total number of lines of the current version of the code; Calculate the full code coverage rate based on the number of covered code lines and the total number of lines of the current version code; Write full code coverage and incremental code coverage into the same coverage report.

8. A device for calculating incremental code coverage, characterized in that: include: A test module is used to execute test cases on the current version of the code and collect code test coverage information, where the code test coverage information is used to indicate the execution status of the code; The comparison module is used to compare the baseline version code with the current version code to obtain the changed code; An equivalence analysis module, used to perform semantic equivalence analysis on the change code based on the baseline version code to obtain a logical change code, wherein the semantic equivalence analysis is used to filter the change code of non-logical factors; A calculation module is used to calculate the incremental code coverage based on the logic change code and code test coverage information. The incremental code coverage includes: change line coverage and change link coverage. The change line coverage is used to represent the execution status of the test cases of the logic change code, and the change link coverage is used to represent the execution status of the test cases of the context link code affected by the logic change code.

9. An electronic device, characterized in that: It includes a processor and a memory, wherein a computer program instruction set is stored in the memory, and when the processor executes the computer program instruction set in the memory, the method for calculating the incremental code coverage described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: in, The computer-readable storage medium stores a computer program instruction set, and when the computer program instruction set is executed by a processor, the method for calculating the incremental code coverage described in any one of claims 1-7 is implemented.

Images