Code coverage statistics method and apparatus

Abstract

The embodiment of the present application discloses a code coverage statistical method and device, after running a target system program, if a calling request for any target program class is received, an identification of a sender of the calling request is obtained; the identification of the sender is bound to a thread processing the calling request, so that when the thread executes a statistical code, an execution result of the statistical code is associated with the identification of the sender; when execution of any target program class ends, the execution result of the statistical code and the associated identification of the sender are written into a coverage data file corresponding to the target program class; coverage data files corresponding to each target program class generated in a preset period are merged into a comprehensive coverage data file; and the code coverage is calculated according to the comprehensive coverage file. Based on the present application, the target system program can be tested, and testers can be distinguished.

Description

Code coverage statistics method and apparatus Technical Field

[0001] This application relates to the field of testing technology, and more specifically, to a code coverage statistics method and apparatus. Background Technology

[0002] Code coverage is one of the metrics for measuring the adequacy of software testing. It refers to the proportion of source code executed by the testers in response to the test actions of the software under test to the total amount of source code. The closer this proportion is to 100%, the more adequacy the testing is considered.

[0003] The source code of the software under test typically contains several method files. Existing code coverage methods involve testing each method file individually and calculating code coverage before integrating them into the system program. After each method file passes testing, they are integrated into the system program, and no further testing of the system program is performed. However, the success of an individual method file test does not guarantee its proper functioning within the system program. Therefore, it is necessary to test the system program and calculate its code coverage. Currently, code coverage methods for method files cannot be applied to system program code coverage statistics because they cannot distinguish between testers. Summary of the Invention

[0004] The purpose of this application is to provide a code coverage statistics method and apparatus, including the following technical solutions:

[0005] A code coverage statistics method, the method comprising:

[0006] Run the target system program, in which each target program class contains statistical code for calculating coverage;

[0007] If a call request for any target program class is received, obtain the identification identifier of the sender of the call request;

[0008] The sender's identification identifier is bound to the thread that processes the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier;

[0009] When the target system program finishes execution, the execution results of the statistical code in each target program class and the identification identifier of the associated sender are written into the coverage data file;

[0010] Merge the various coverage data files generated within the preset time period into a comprehensive coverage data file;

[0011] Calculate code coverage based on the comprehensive coverage file.

[0012] In the above method, preferably, obtaining the identifier of the sender of the call request includes:

[0013] Extract the sender's identification identifier from the call request;

[0014] or,

[0015] Extract the sender's identification identifier from the header information of the call request;

[0016] or,

[0017] Extract the sender's identification identifier from the channel object of the distributed communication framework Dubbo.

[0018] The above method, preferably, includes the step of writing the execution results of the statistical code in each target program class and the identification identifier of its associated sender into the coverage data file, which includes:

[0019] The statistical code executed in the source code of any method in any target program class is determined based on the execution result of the statistical code of any method.

[0020] The table records the coverage data corresponding to any of the methods; the table records the sender's identification identifier, the identifier of any method, the coverage row in the source code of any method, and the line number table of the source code of any method.

[0021] The above method, preferably, also includes:

[0022] For any target method file in the development flow, the latest version of the target method file is compared with the previous version to determine the change block; the target method file belongs to the first requirement.

[0023] If there are changes for non-first requirements between the release time of the latest version and the previous version, delete the part of the change block that belongs to the non-first requirements to obtain the target change block;

[0024] Determining the target line number table includes: querying the version status of any target method file during test execution on the integration stream; for each version of any target method file on the integration stream, searching for the content of the target modification block one by one; keeping the content that can be found in each version; and deleting the part of the content of any version where the target modification block cannot be found. The target line number table is the line number table of the source code corresponding to the content of the target modification block found in the integration stream.

[0025] The line number table in the coverage data corresponding to each integration stream version of any target method file is intersected with the target line number table to obtain the list of line numbers that should be covered.

[0026] In the above method, preferably, the step of calculating code coverage based on the comprehensive coverage data file includes:

[0027] For any target method file, the union of the coverage lines belonging to the above list of line numbers to be covered in the coverage data of each version of the target method file during the test period is obtained to obtain the coverage lines of each target method file during the test period.

[0028] The union of the coverage lines of each target method file of the same class within the test time period is obtained to obtain the coverage lines of each class within the test time period.

[0029] The code coverage rate is obtained by calculating the ratio of the number of covered lines for each class during the test period to the number of line numbers in the list of line numbers to be covered.

[0030] A code coverage statistics device, comprising:

[0031] The runtime module is used to run the target system program, and each target program class of the target system program contains statistical code for calculating coverage.

[0032] The identifier acquisition module is used to obtain the identification identifier of the sender of the call request if a call request for any target program class is received.

[0033] A binding module is used to bind the sender's identification identifier to the thread that processes the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier;

[0034] The data writing module is used to write the execution results of the statistical code in each target program class and the identification identifier of the associated sender into the coverage data file when the target system program finishes execution;

[0035] The merging module is used to merge the various coverage data files generated within a preset time period into a comprehensive coverage data file.

[0036] The calculation module is used to calculate code coverage based on the comprehensive coverage file.

[0037] In the above-mentioned apparatus, preferably, the identifier acquisition module is specifically used for:

[0038] Extract the sender's identification identifier from the call request;

[0039] or,

[0040] Extract the sender's identification identifier from the header information of the call request;

[0041] or,

[0042] Extract the sender's identification identifier from the channel object of the distributed communication framework Dubbo.

[0043] In the above-mentioned apparatus, preferably, the data writing module is specifically used for:

[0044] The statistical code executed in any method is determined based on the execution result of the statistical code in any method of any target program class.

[0045] The table records the coverage data corresponding to any of the methods; the table records the sender's identification identifier, the identifier of any method, the coverage row in the source code of any method, and the line number table of the source code of any method.

[0046] Preferably, the above-described apparatus further includes a module for determining the row number list to be covered, used for:

[0047] For any target method file in the development flow, the latest version of the target method file is compared with the previous version to determine the change block; the target method file belongs to the first requirement.

[0048] If there are changes for non-first requirements between the release time of the latest version and the previous version, delete the part of the change block that belongs to the non-first requirements to obtain the target change block;

[0049] Determining the target line number table includes: querying the version status of any target method file during test execution on the integration stream; for each version of any target method file on the integration stream, searching for the content of the target modification block one by one; keeping the content that can be found in each version; and deleting the part of the content of any version where the target modification block cannot be found. The target line number table is the line number table of the source code corresponding to the content of the target modification block found in the integration stream.

[0050] The line number table in the coverage data corresponding to each integration stream version of any target method file is intersected with the target line number table to obtain the list of line numbers that should be covered.

[0051] In the above-mentioned apparatus, preferably, the computing module is specifically used for:

[0052] For any target method file, the union of the coverage lines belonging to the above list of line numbers to be covered in the coverage data of each version of the target method file during the test period is obtained to obtain the coverage lines of each target method file during the test period.

[0053] The union of the coverage lines of each target method file of the same class within the test time period is obtained to obtain the coverage lines of each class within the test time period.

[0054] The code coverage rate is obtained by calculating the ratio of the number of covered lines for each class during the test period to the number of line numbers in the list of line numbers to be covered.

[0055] As can be seen from the above scheme, the code coverage statistics method and apparatus provided in this application, after running the target system program, if a call request for any target program class is received, obtains the identification identifier of the sender of the call request; binds the sender's identification identifier to the thread handling the call request, so that when the thread executes the statistical code, the execution result of the statistical code is associated with the sender's identification identifier; when any target program class finishes execution, the execution result of the statistical code and its associated sender's identification identifier are written into the coverage data file corresponding to that target program class; the coverage data files corresponding to each target program class generated within a preset time period are merged into a comprehensive coverage data file; and the code coverage is calculated based on the comprehensive coverage file. Based on this application, the testing of the target system program is realized, and the tester (the sender of the call request) can be distinguished. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 is a flowchart of an implementation of the code coverage statistics method provided in an embodiment of this application;

[0058] Figure 2 is a flowchart of an implementation of this application embodiment, which writes the execution results of statistical code in each target program class and the identification identifier of the associated sender into a coverage data file;

[0059] Figure 3 is another implementation flowchart of obtaining the list of row numbers to be covered provided in the embodiments of this application;

[0060] Figure 4 is a flowchart of an implementation of calculating code coverage based on a comprehensive coverage data file according to an embodiment of this application;

[0061] Figure 5 is a schematic diagram of a code coverage statistics device provided in an embodiment of this application;

[0062] Figure 6 is a schematic diagram of an electronic device provided in an embodiment of this application.

[0063] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar parts and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that illustrated herein. Detailed Implementation

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

[0065] Figure 1 shows a flowchart of one implementation of the code coverage statistics method provided in this application, which may include:

[0066] Step S101: Run the target system program. Each target program class in the target system program contains statistical code for calculating coverage.

[0067] The target system program refers to the system program being tested. The source code of the target system program (for ease of description and distinction, it is referred to as the target source code) consists of several method files. Each method file constitutes a minimum testable unit of the target source code, which can be a function, an interface, or a button, etc.

[0068] Optionally, the target system program can be a complete application or a subroutine within a complete application.

[0069] The target system program can be run through the Java Virtual Machine (JVM).

[0070] The statistical code used to calculate coverage can be written into the target program class (i.e., the program class of interest) by the Java agent, which is added to the javaagent parameter of the Java startup command.

[0071] Step S102: If a call request for any target program class is received, obtain the identification identifier of the sender of the call request.

[0072] The sender's identifier can be the sender's IP address. Of course, it can also be other information that can uniquely identify the sender, such as a unique code generated according to preset rules.

[0073] Step S103: Bind the sender's identification identifier to the thread that processes the above-mentioned call request, so that when the above-mentioned thread executes the statistics code, it associates the execution result of the statistics code with the sender's identification identifier.

[0074] Steps S102-S103 can be implemented through program logic injected into the network application development framework (referred to as a marker tool for ease of description and distinction).

[0075] This research finds that in the integration testing of web applications, the programs that testers are concerned with are mostly triggered by human operation. Fundamentally, whether a person clicks a button or fills out a form, any program invocation begins with the sending of a request; for the application under test, it begins with the receiving of a request. This request inevitably carries, to some extent, the caller's identity information (such as an IP address). Therefore, a tagging tool can find a suitable node within the entire process of a request—from sending to processing to sending back a response—extract the caller's identifier from that node, and then bind this information to the current thread (i.e., the thread processing the aforementioned request). Subsequently, when the current thread executes the statistical code used for coverage calculation, it can save the executor's identifier. This application calls this mechanism thread isolation.

[0076] When the current thread executes the statistics code, it means that the source code of the line containing the statistics code has also been executed.

[0077] Step S104: When the target system program finishes execution, write the execution results of the statistical code in each target program class and the identification identifier of the associated sender into the coverage data file.

[0078] In this application, for any target program class, before the target system program terminates, the execution result of the statistical code in that target program class and its associated sender identification are stored in memory in the form of a log. When the target system program terminates, the execution result of the statistical code in that target program class and its associated sender identification are written to a coverage data file.

[0079] The termination of target system program execution includes: the target system program exiting the run, which may be due to the target system program being manually closed, or the target system program terminating execution due to the shutdown or restart of the server running the target system program.

[0080] Step S105: Merge the various coverage data files generated within the preset time period into a comprehensive coverage data file.

[0081] Only one coverage data file may be generated within a preset time period. In this case, the single coverage data file is the comprehensive coverage data file.

[0082] At least two coverage data files may have been generated within the preset time period. At this time, the two coverage data files will be merged into a comprehensive coverage data file.

[0083] The preset time period can be a test time period specified by the developer, which means that the coverage data files generated within the test time period specified by the developer will be merged into a comprehensive coverage data file.

[0084] Step S106: Calculate code coverage based on the above comprehensive coverage file.

[0085] The code coverage statistics method provided in this application, after running the target system program, if a call request for any target program class is received, obtains the identifier of the sender of the call request; binds the sender's identifier to the thread handling the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identifier; when any target program class finishes execution, the execution result of the statistics code and its associated sender's identifier are written to the coverage data file corresponding to that target program class; the coverage data files corresponding to each target program class generated within a preset time period are merged into a comprehensive coverage data file; and code coverage is calculated based on the comprehensive coverage file. Based on this application, testing of the target system program is achieved, and the tester (i.e., the sender of the call request) can be distinguished.

[0086] The key to obtaining the identifier of the sender of the call request is to find the "essential path" of the target system program before it reaches the business code, so that logic can be injected in the correct place. Typically, the work between receiving the request and invoking the business program is handled by middleware and network frameworks, and different network frameworks have different "essential paths." Therefore, the method for obtaining the identifier of the sender of the call request in this application is related to the specific network application architecture.

[0087] Optionally, this application supports two network frameworks: the HttpServlet framework and the Dubbo framework.

[0088] Java also has different versions of the HttpServlet framework. One version, called Java EE, is specifically designed to support enterprise applications. It defines the Servlet architecture, the most widely used architecture for web server programs in Java. This architecture also provides a component that integrates with the Hypertext Transfer Protocol (HTTP), namely HttpServlet.

[0089] Dubbo is an open-source Java remote service invocation framework.

[0090] Within the HttpServlet framework, the identifier of the requester can be obtained through injection into the service method of the HttpServlet class and at least some of its subclasses, or through a marker utility in the service method of a class that inherits from HttpServlet. Specific implementation methods may include:

[0091] Extract the sender's identifier from the call request. The tagging tool can extract the client's IP address from the HTTP request object, a parameter of the service method, at the beginning of the method, and bind it as the caller's identity (i.e., the sender's identifier) ​​to the thread handling the call request.

[0092] or,

[0093] Extracting the sender's identifier from the request header is crucial. In practice, two scenarios exist: Scenario 1: The client accesses the server from the internet. In this case, the client's IP address may be variable, meaning a single IP address may not be sufficient to identify a tester. Scenario 2: Client C accesses system A, and A, while executing its own code, needs to call system B. For system B, the client's IP address is simply A's IP, failing to distinguish the caller. Therefore, in these situations, header information can replace IP address binding to the thread. For example, before calling B, system A can include the client's IP address in the target header of the request. Upon receiving the request, B can identify the caller as client C based on this header value. Similarly, before accessing system A, client C can include its IP address in the target header of the request. Upon receiving the request, A can also identify the caller as client C based on this header value. In this application, in order to adapt to different network environments, the tagging tool can check the header information of the call request. If target header information exists (for example, header information named "test-coverage-sip"), the value of the target header information is used as the identifier of the sender and bound to the thread that processes the call request.

[0094] Within the Dubbo framework, the sender's identifier for the call request can be obtained by injecting a marker into the `received` method of the `HeaderExchangeHandler` class. Specific implementation methods include:

[0095] Extract the sender's identifier from the channel object of the Dubbo distributed communication framework. Optionally, the tagging tool can extract the client's IP address from the method's parameter, the Dubbo channel object, at the beginning of the method and use it as the caller's identity identifier, binding it to the current thread.

[0096] Of course, when the above-mentioned injection marking tool exits, the sender's identification identifier will be unbound from the thread that ran the call request.

[0097] In an optional embodiment, the flowchart of one implementation of writing the execution results of the statistical code in each target program class and the identification identifier of its associated sender into the coverage data file is shown in Figure 2, and may include:

[0098] Step S201: Determine the statistical code that was executed in the source code of any of the above-mentioned methods based on the execution result of the statistical code of any method in any of the above-mentioned target program classes.

[0099] The thread handling the call request can determine which lines of the source code of any of the above methods were executed by using the variables in the statistical code in the execution result of the statistical code. In other words, the lines containing the variables in the execution result of the statistical code were executed.

[0100] Step S202: Record the coverage data corresponding to any of the above methods in a table. The table records the sender's identification identifier, the identifier of any of the above methods, the coverage rows in the source code of any of the above methods, and the line number table of the source code of any of the above methods.

[0101] Table 1 is an example diagram of recording coverage data in a table according to an embodiment of this application.

[0102] Table 1

[0103] Caller identity, method name, overriding line number table 10.51.4.4 com.foo.Class1.method1() 0,1,1,0,13,4,5,7,9 surface

[0104] The example shown in Table 1 indicates that the caller with IP address 10.51.4.4 executed the method com.foo.Class1.method1(), which has 5 lines of source code, numbered 3, 4, 5, 7, and 9. The overridden line “0,1,1,0,1” indicates that lines 4, 5, and 9 were executed, while lines 3 and 7 were not executed.

[0105] At this point, we can obtain the information about the code executed by a particular tester.

[0106] To calculate code coverage, you first need to determine the lines of code that should be covered and the lines of code that are already covered. The ratio of the number of covered lines to the number of lines of code that should be covered is the code coverage rate. In unit testing (i.e., testing a single method file), because code version changes during the testing process are not considered, the code that should be covered and the code that are already covered are static data. However, in integration testing, an algorithm is needed to aggregate the code that should be covered and the code that is already covered over time, turning them into two static values, which are then used to calculate code coverage. For example, in code coverage statistics using Jacoco (a free and open-source Java code coverage tool library that includes a Java agent that works in the same JVM as the software under test), tester A's requirements were deployed to the integration environment today, and they tested for one day, with plans to continue testing the next day. However, the next morning, tester B's requirements were also deployed to the integration environment. Because the release caused a server restart, JaCoco generated coverage files. This means that the coverage records for test requirement A might be stored in multiple coverage files, and JaCoco doesn't provide a solution for integrating these files. Furthermore, the release of test requirement B might change the location of the code in test requirement A's release. The new location of the code in A's release needs to be considered as covered lines; otherwise, the numerator will also be incorrect. For example, if someone tests a requirement for two days, and the code versions for day 1 and day 2 are different, then we need to select a suitable version or merge the two versions into one as the denominator.

[0107] Furthermore, software development is mostly incremental. In incremental development, only the code coverage of the incrementally modified parts needs to be focused on. Therefore, this application focuses on the code coverage of incremental development. The following describes the process of determining the list of line numbers to be covered in the incremental development scenario.

[0108] The code coverage statistics method provided in this application embodiment may further include:

[0109] For any target method file in the development flow, compare the latest version of the target method file with the previous version to determine the change blocks; any target method file belongs to the first requirement. That is to say, any target method file was developed based on the first requirement.

[0110] Optionally, based on the requirement number of the first requirement, the development workflow can be searched for method files modified according to the first requirement, and the found method files modified according to the first requirement can be used as target method files.

[0111] The development workflow, also known as development branching, involves developers submitting code to a development branch. Before releasing the code to testing or other environments, a merge process is required, which packages the code from the development branch into a runnable program for distribution. Because multiple developers or multiple versions may be under development simultaneously, transferring code from a development branch to an integration branch is not a simple assignment and paste; it's possible that the code on both sides may not be entirely identical.

[0112] Software system development is typically based on requirements (adding new features or fixing defects). For example, if a business department needs to add a page to the system and implement several functions, developers can submit a task order (referred to as a type 1 task order for ease of description and distinction) in a comprehensive management system (such as an IT service platform, or ITSM). Each task order carries a development task number, and each task order has a unique number assigned by the management system; this number is the requirement number. The requirement then flows through the management system according to the processing flow. When it reaches the testing phase, the test manager will split it into a test task (again, a task order; referred to as a type 2 task order for ease of description and distinction). The test task's processing flow records the start and end times of the test; this time period is the test time period for the test task.

[0113] In addition, to better understand the version information of the requirements, developers will also submit code to SVN (short for Subversion, an open-source version control system). When submitting code to SVN, developers must use the development task number as a log. Each change point in the source code is marked with a development task number. Therefore, this application can be combined with a Java SVN client to find out which Java files have been modified in a requirement based on the development task number.

[0114] The management system stores various task orders and their relationships in a relational database. Based on this, SQL statements can be used to query task orders from the database according to the relationship between the requirement number and the task order, and then query the development task number.

[0115] If there are changes to non-primary requirements between the release dates of the latest version and the version prior to the above modifications, delete the non-primary requirements parts from the identified change blocks to obtain the target change block.

[0116] As mentioned earlier, each change point in the source code is marked with a development task number, so all changes between two versions can be checked one by one. If its log is a development task number associated with other requirements, then it is considered to be a change of other requirements (i.e., not the first requirement).

[0117] Each change point is actually a block of change (i.e. several consecutive lines of code). For a file, assuming the block of change corresponding to the first requirement between two versions is [a, b, c], and the block of change corresponding to the non-first requirement is [d, e], then we can try to match a, b, and c with d and e respectively.

[0118] Let k be any modified block in [d,e]. If k is completely equal to any block among a, b, and c, then that block is completely removed. If k partially matches a block, then taking a as an example, three cases are handled:

[0119] 1. If d matches the first to the nth line of a, then a will be adjusted to the (n+1)th line to the end, which means removing the first to the nth line of a.

[0120] 2. If d matches the nth line to the end of a, then a is adjusted to the 1st line to the (n-1)th line, which means the nth line to the end of a is removed;

[0121] 3. If d matches the nth to mth lines of a, then a is split into two parts, a1 and a2. a1 is the first to the (n-1)th lines, and a2 is the (m+1)th to the end. In other words, the nth to mth lines of a are removed.

[0122] No action will be taken for any other cases.

[0123] Locate the content corresponding to the target modification block in the integration flow, including: querying the version status of any of the target method files mentioned above during test execution on the integration flow; for each version of any of the target method files mentioned above on the integration flow, searching for the content of the target modification block one by one; keeping the content that can be found in each version; and deleting the part of the content of any version where the target modification block cannot be found.

[0124] The version information of a method file may include, but is not limited to, the content of the method file, the version number, the modification time, etc.

[0125] Suppose that the functionality of any test comes from the source code file A.java, and the testing period is from January 1st to January 3rd. As mentioned above, the code in the test environment is packaged from the integration branch. Therefore, we need to see what the A.java file looked like on the integration branch during these three days. For example, if A.java on the integration stream was modified at noon on January 2nd, then the result we need to query is what the A.java file looked like from January 1st to the morning of January 2nd, and what it looked like from the afternoon of January 2nd to January 3rd.

[0126] In this application, for any version of any of the aforementioned target method documents, if the content of any version does not belong to the content of any target modification block, then any version of the aforementioned target method document is deleted; if only part of the content of any version of the aforementioned target method document belongs to at least one target modification block, and another part of the content of any version of the aforementioned target method document does not belong to the content of any target modification block, then the other part of the content of any version of the aforementioned target method document is deleted, and only the content belonging to at least one target modification block is retained.

[0127] The intersection of the line number table in the coverage data for each integration stream version of any of the aforementioned target method files at the corresponding time and the target line number table yields a list of line numbers that should be covered. The target line number table is the line number table of the source code corresponding to the content of the target change block found in the integration stream.

[0128] As mentioned earlier, the coverage data records the line number table for each method in the program class. Therefore, by intersecting the line number table in the coverage data corresponding to each integration stream version of any of the above target method files with the target line number table, the resulting list of line numbers to be covered belongs to the list of line numbers of the changed source code. Thus, based on this application, code coverage for incremental development needs can be achieved.

[0129] The following example, using Java code to illustrate the method for obtaining the list of line numbers to be covered, demonstrates how to do so. Figure 3 shows another implementation flowchart for obtaining the list of line numbers to be covered provided in this embodiment, which may include:

[0130] Step S301: Use the target requirement number to query the development task number and test time. The requirement number is entered by the user into the management system on the client according to the requirements.

[0131] Step S302: Query the list of modified Java files in the development workflow: Based on the development task number, query the list of Java files modified according to the requirements corresponding to the target requirement number in the development workflow. Each Java file in the Java file list is a method file, i.e., the target method file mentioned above.

[0132] Step S303: Process each target method file in a loop: For any target method file, perform the following process:

[0133] Step S30301: Calculate the change block on the development flow. Specifically, this may include: comparing the latest version of any of the target method files with the previous version based on SVN diff to determine the change block; any of the target method files belongs to the first requirement. Determine if there are any other requirement commit records between the two versions; if so, subtract the content of other requirement commits from the determined change block (which may cause the previously determined change block to be split into smaller chunks) to obtain the target change block.

[0134] Step S30302: Locate the file path on the integration stream.

[0135] Step S30303: Query the version list of any of the above target files on the integration stream during the test period.

[0136] Step S30304: Traverse each version of any of the above target method files on the integration stream and remove content that does not belong to any target modification block.

[0137] Step S30305: Loop through each version of any of the above target files in the integration stream, including: for any version, obtain the file content of that version; traverse the remaining target change blocks in the development stream, add the line numbers that match the target change blocks to the list of line numbers to be concerned (i.e., the target line number table), which is the difference on SVN, i.e., the difference from the source code perspective.

[0138] Step S30306: Download the coverage data for the last day of each version of any of the above target files from the server.

[0139] Step S30307: Extract the row number table from the last day's coverage data of all versions of any of the above target files and form a set.

[0140] Step S30308: Find the intersection of the set obtained in step S30307 and the target row number table to obtain the final list of row numbers to be covered.

[0141] Figure 4 shows a flowchart of an implementation of calculating code coverage based on a comprehensive coverage data file according to an embodiment of this application, which may include:

[0142] Step S401: For any target method file, find the union of the coverage lines in the coverage data of each version of the target method file that belong to the above list of line numbers to be covered in the test period, and obtain the coverage lines of each target method file in the test period.

[0143] For target method files, this application only focuses on the covered lines that belong to the list of line numbers to be covered; other covered lines that do not belong to the list of line numbers to be covered are not used for code coverage statistics.

[0144] For any version of any target method file, the union of the coverage lines belonging to the above list of line numbers to be covered in the daily coverage data of any version during the test period is obtained to get the coverage lines of any version during the test period; the union of the coverage lines of each version of any target method file during the test period is obtained to get the coverage lines of any target method during the test period.

[0145] Optionally, if it is necessary to calculate coverage based on the sender's identifier, then for any version of any target method file, target coverage data can be extracted from the daily coverage data of any version within the test period. The target coverage data is the coverage data of any version containing the same sender's identifier within the test period. The union of the coverage rows in the target coverage data that belong to the above list of lines to be covered is obtained to obtain the coverage rows of any version corresponding to the same sender's identifier within the test period.

[0146] The union of the coverage lines of each version of the target method file corresponding to the same sender's identifier within the test period is obtained to obtain the coverage line of the target method corresponding to the same sender's identifier within the test period.

[0147] Step S402: Find the union of the coverage lines of each target method file of the same class within the test period to obtain the coverage lines of each class within the test period.

[0148] If it is necessary to distinguish between different senders, the union of the coverage lines of each target method file corresponding to the identification identifier of the same class and the same sender within the test period can be obtained to obtain the coverage lines of each class within the test period corresponding to the identification identifier of the same sender.

[0149] Step S403: Calculate the ratio of the number of covered lines for each class during the above test period to the number of line numbers in the above list of line numbers to be covered, and obtain the code coverage rate.

[0150] The code coverage obtained here is the code coverage for incremental development.

[0151] Corresponding to the method embodiments, this application also provides a code coverage statistics device, as shown in FIG5, which is a schematic diagram of a structure of the code coverage statistics device provided in the embodiments of this application, which may include:

[0152] The system comprises a running module 501, an identifier acquisition module 502, a binding module 503, a data writing module 504, a merging module 505, and a calculation module 506; among which,

[0153] The running module 501 is used to run the target system program, and each target program class of the target system program contains statistical code for calculating coverage.

[0154] The identifier acquisition module 502 is used to obtain the identification identifier of the sender of the call request if a call request for any target program class is received;

[0155] The binding module 503 is used to bind the sender's identification identifier to the thread that processes the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier;

[0156] The data writing module 504 is used to write the execution results of the statistical code in each target program class and the identification identifier of the associated sender into the coverage data file when the target system program finishes execution;

[0157] The merging module 505 is used to merge the various coverage data files generated within a preset time period into a comprehensive coverage data file;

[0158] The calculation module 506 is used to calculate code coverage based on the comprehensive coverage file.

[0159] The code coverage statistics device provided in this application, after running the target system program, if a call request for any target program class is received, obtains the identification identifier of the sender of the call request; binds the sender's identification identifier to the thread handling the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier; when any target program class finishes execution, the execution result of the statistics code and its associated sender's identification identifier are written into the coverage data file corresponding to that target program class; the coverage data files corresponding to each target program class generated within a preset time period are merged into a comprehensive coverage data file; and code coverage is calculated based on the comprehensive coverage file. Based on this application, testing of the target system program is achieved, and the tester (i.e., the sender of the call request) can be distinguished.

[0160] In an optional embodiment, the identifier acquisition module 502 is specifically used for:

[0161] Extract the sender's identification identifier from the call request;

[0162] or,

[0163] Extract the sender's identification identifier from the header information of the call request;

[0164] or,

[0165] Extract the sender's identification identifier from the channel object of the distributed communication framework Dubbo.

[0166] In an optional embodiment, the data writing module 504 is specifically used for:

[0167] The statistical code executed in any method is determined based on the execution result of the statistical code in any method of any target program class.

[0168] The table records the coverage data corresponding to any of the methods; the table records the sender's identification identifier, the identifier of any method, the coverage row in the source code of any method, and the line number table of the source code of any method.

[0169] In an optional embodiment, the apparatus further includes a module for determining the row number list to be covered, for:

[0170] For any target method file in the development flow, the latest version of the target method file is compared with the previous version to determine the change block; the target method file belongs to the first requirement.

[0171] If there are changes for non-first requirements between the release time of the latest version and the previous version, delete the part of the change block that belongs to the non-first requirements to obtain the target change block;

[0172] Determining the target line number table includes: querying the version status of any target method file during test execution on the integration stream; for each version of any target method file on the integration stream, searching for the content of the target modification block one by one; keeping the content that can be found in each version; and deleting the part of the content of any version where the target modification block cannot be found. The target line number table is the line number table of the source code corresponding to the content of the target modification block found in the integration stream.

[0173] The line number table in the coverage data corresponding to each integration stream version of any target method file is intersected with the target line number table to obtain the list of line numbers that should be covered.

[0174] In an optional embodiment, the computing module 506 is specifically used for:

[0175] For any target method file, the union of the coverage lines belonging to the above list of line numbers to be covered in the coverage data of each version of the target method file during the test period is obtained to obtain the coverage lines of each target method file during the test period.

[0176] The union of the coverage lines of each target method file of the same class within the test time period is obtained to obtain the coverage lines of each class within the test time period.

[0177] The code coverage rate is obtained by calculating the ratio of the number of covered lines for each class during the test period to the number of line numbers in the list of line numbers to be covered.

[0178] Corresponding to the method embodiments, this application also provides an electronic device, a schematic diagram of which is shown in FIG6, and may include: at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4.

[0179] In this embodiment, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4.

[0180] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0181] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0182] The memory 3 stores a program, and the processor 1 can call the program stored in the memory 3. The program is used for:

[0183] Run the target system program, in which each target program class contains statistical code for calculating coverage;

[0184] If a call request for any target program class is received, obtain the identification identifier of the sender of the call request;

[0185] The sender's identification identifier is bound to the thread that processes the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier;

[0186] When the target system program finishes execution, the execution results of the statistical code in each target program class and the identification identifier of the associated sender are written into the coverage data file;

[0187] Merge the various coverage data files generated within the preset time period into a comprehensive coverage data file;

[0188] Calculate code coverage based on the comprehensive coverage file.

[0189] Optionally, the refined and extended functions of the program can be found in the description above.

[0190] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor, the program being used for:

[0191] Run the target system program, in which each target program class contains statistical code for calculating coverage;

[0192] If a call request for any target program class is received, obtain the identification identifier of the sender of the call request;

[0193] The sender's identification identifier is bound to the thread that processes the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier;

[0194] When the target system program finishes execution, the execution results of the statistical code in each target program class and the identification identifier of the associated sender are written into the coverage data file;

[0195] Merge the various coverage data files generated within the preset time period into a comprehensive coverage data file;

[0196] Calculate code coverage based on the comprehensive coverage file.

[0197] Optionally, the refined and extended functions of the program can be found in the description above.

[0198] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0199] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0200] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0201] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0202] It should be understood that in the embodiments of this application, the claims, various embodiments, and features can be combined with each other to solve the aforementioned technical problems.

[0203] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0204] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A code coverage statistics method, characterized in that, The method includes: running a target system program, wherein each target program class of the target system program contains statistical code for calculating coverage; if a call request for any target program class is received, obtaining the identifier of the sender of the call request; wherein obtaining the identifier of the sender of the call request includes: in the HttpServlet framework, extracting the identifier of the sender from the call request, or checking the header information of the call request, and if target header information exists, using the value of the target header information as the identifier of the sender, wherein the value of the target header information is the IP address of the caller; or in the Dubbo framework, extracting the client's IP address from the channel object of the distributed communication framework Dubbo, and using the client's IP address as the identifier of the sender; binding the identifier of the sender to the thread processing the call request, so that through the thread isolation mechanism, when the thread executes the statistical code, the execution result of the statistical code is associated with the identifier of the sender; when the target system program finishes execution, writing the execution result of the statistical code in each target program class and its associated identifier of the sender into a coverage data file; The various coverage data files generated within a preset time period are merged into a comprehensive coverage data file; code coverage is calculated based on the comprehensive coverage data file; for any target method file in the development flow, the latest version of the target method file is compared with the previous version to determine the change block; the target method file belongs to the first requirement; if there are changes for non-first requirements between the release time of the latest version and the previous version, the part of the change block belonging to the non-first requirement is deleted to obtain the target change block; the target line number table is determined, including: querying the version status of the target method file during test execution in the integration flow; for each version of the target method file in the integration flow, the content of the target change block is searched one by one, and the content that can be found in each version is kept; for any version, the part of the content in the content of any version where the target change block cannot be found is deleted; the target line number table is the line number table of the source code corresponding to the content of the target change block found in the integration flow; the line number table in the coverage data corresponding to the time of each integration flow version of the target method file is intersected with the target line number table to obtain the list of line numbers to be covered.

2. The method according to claim 1, characterized in that, The step of writing the execution results of the statistical code in each target program class and the identification identifier of the associated sender into the coverage data file includes: determining the executed statistical code in the source code of any method based on the execution result of the statistical code of any method in any target program class; recording the coverage data corresponding to any method in a table; the table records the identification identifier of the sender, the identifier of any method, the coverage line in the source code of any method, and the line number table of the source code of any method.

3. The method according to claim 1, characterized in that, The step of calculating code coverage based on the comprehensive coverage data file includes: for any target method file, finding the union of the coverage lines belonging to the aforementioned list of lines to be covered in the coverage data of each version of the target method file within the test period, to obtain the coverage lines of each target method file within the test period; finding the union of the coverage lines of each target method file of the same class within the test period, to obtain the coverage lines of each class within the test period; and calculating the ratio of the number of coverage lines of each class within the test period to the number of line numbers in the list of lines to be covered, to obtain the code coverage rate.

4. A code coverage statistics device, characterized in that, include: The runtime module is used to run the target system program, and each target program class of the target system program contains statistical code for calculating coverage. The identifier acquisition module is used to obtain the identification identifier of the sender of the call request if a call request for any target program class is received. A binding module is used to bind the sender's identification identifier to the thread that processes the call request, so that when the thread executes the statistics code, the execution result of the statistics code is associated with the sender's identification identifier through a thread isolation mechanism. The data writing module is used to write the execution results of the statistical code in each target program class and the identification identifier of the associated sender into the coverage data file when the target system program finishes execution; The merging module is used to merge the various coverage data files generated within a preset time period into a comprehensive coverage data file. The calculation module is used to calculate code coverage based on the comprehensive coverage data file; the identifier acquisition module is specifically used to: extract the sender's identifier from the call request in the HttpServlet framework, or check the header information of the call request, and if target header information exists, use the value of the target header information as the sender's identifier, where the value of the target header information is the caller's IP address; or, in the Dubbo framework, extract the client's IP address from the channel object of the distributed communication framework Dubbo, and use the client's IP address as the sender's identifier; the device also includes a line number list determination module, used to: for any target method file in the development flow, compare the latest version of the target method file with the previous version to determine the change block; the target method file belongs to the first requirement; if there are changes for non-first requirements between the release time of the latest version and the previous version, delete the part of the change block that belongs to the non-first requirement to obtain the target change block; Determining the target line number table includes: querying the version status of any target method file during test execution on the integration stream; for each version of any target method file on the integration stream, searching for the content of the target modification block one by one; keeping the content that can be found in each version; and deleting the part of the content of any version where the target modification block cannot be found. The target line number table is the line number table of the source code corresponding to the content of the target modification block found in the integration stream. The intersection of the line number table in the coverage data corresponding to each integration stream version of the target method file at that time and the target line number table is obtained to obtain the list of lines that should be covered.

5. The apparatus according to claim 4, characterized in that, The data writing module is specifically used for: determining the executed statistical code in any method based on the execution result of the statistical code in any method of any target program class; recording the coverage data corresponding to any method in a table; the table records the sender's identification identifier, the identifier of any method, the coverage line in the source code of any method, and the line number table of the source code of any method.

6. The apparatus according to claim 4, characterized in that, The calculation module is specifically used for: for any target method file, finding the union of the coverage lines belonging to the above-mentioned list of lines to be covered in the coverage data of each version of the target method file within the test time period, to obtain the coverage lines of each target method file within the test time period; finding the union of the coverage lines of each target method file of the same class within the test time period, to obtain the coverage lines of each class within the test time period; and calculating the ratio of the number of coverage lines of each class within the test time period to the number of line numbers in the list of lines to be covered, to obtain the code coverage rate.

Images