A method and apparatus for detecting code coverage

Abstract

The embodiment of the application provides a kind of detection code coverage method and device, it is related to the field of financial technology (Fintech), the method comprises: obtaining the code file to be measured and the index file corresponding to the code file to be measured, in the process of running the code file to be measured, for each test probe inserted in the code file to be measured, if test probe is triggered, determine the target element associated in the index file of test probe, and update target element.In the end when the code file to be measured runs, according to the elements in each probe counting array in the index file, determine the code coverage of the code file to be measured.When test probe is triggered, the elements in the probe counting array associated with test probe are quickly determined through the index file, which improves the search speed.Each test probe in the subfile corresponds to the element in the probe counting array one by one, which improves the accuracy of detecting code coverage.

Description

Technical Field

[0001] This application relates to the field of financial technology (Fintech), and more particularly to a method and apparatus for detecting code coverage. Background Technology

[0002] With the development of computer technology, more and more technologies are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology (Fintech). However, due to the security and real-time requirements of the financial industry, higher demands are being placed on technology.

[0003] To improve the quality of software development, it is often necessary to perform code coverage statistics. Currently, there are two main industry solutions: runtime analysis and injection analysis. Runtime analysis mainly uses the Java Virtual Machine Monitoring Interface (JVMPI) and the Java Virtual Machine Tool Interface (JVMTI) to perform statistics, while injection analysis is further divided into source code injection and bytecode injection methods.

[0004] Because source code injection can intrude into and disrupt the original code structure, the industry generally prefers bytecode injection. Bytecode injection analysis typically employs JaCoCo technology, which uses instrumentation to insert probes for coverage statistics to achieve test coverage analysis. However, the use cases for JaCoCo code coverage detection are limited, as it is prone to conflicts with other testing tasks, thus affecting the efficiency and accuracy of code coverage detection. Summary of the Invention

[0005] This application provides a method and apparatus for detecting code coverage, which improves the efficiency and accuracy of code coverage detection.

[0006] On one hand, embodiments of this application provide a method for detecting code coverage, the method comprising:

[0007] Obtain the code file to be tested and the index file corresponding to the code file to be tested. The code file to be tested includes at least one sub-file. The index file includes the association relationship between the root file identifier corresponding to the code file to be tested and the sub-file identifiers corresponding to each of the at least one sub-files, and a probe count array corresponding to each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file.

[0008] During the execution of the code file under test, for each test probe inserted in the code file under test, if the test probe is triggered, the target element associated with the test probe in the index file is determined and the target element is updated;

[0009] When the code file under test finishes running, the code coverage of the code file under test is determined based on the elements in the probe count arrays of the index file.

[0010] On one hand, embodiments of this application provide a code coverage detection device, the device comprising:

[0011] The acquisition module is used to acquire the code file to be tested and the index file corresponding to the code file to be tested. The code file to be tested includes at least one sub-file. The index file includes the association relationship between the root file identifier corresponding to the code file to be tested and the sub-file identifiers corresponding to each of the at least one sub-file, and a probe count array corresponding to each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file.

[0012] An update module is used to, during the execution of the code file under test, determine the target element associated with each test probe inserted in the code file under test if the test probe is triggered, and update the target element.

[0013] The statistics module determines the code coverage of the code file under test based on the elements in the probe count arrays in the index file when the test code file finishes running.

[0014] Optionally, the acquisition module is specifically used for:

[0015] Based on the association between the code file to be tested and the at least one sub-file, and the code logic branches contained in each of the at least one sub-file, an index file corresponding to the code file to be tested is constructed.

[0016] Optionally, the acquisition module is further configured to:

[0017] It is determined that the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, and that the sub-file identifier corresponding to each of the at least one sub-file is different from the sub-file identifier corresponding to the historical sub-file in the historical index file.

[0018] Optionally, the acquisition module is specifically used for:

[0019] If the root file identifier of the code file to be tested is the same as the root file identifier in the historical index file, then the probe count arrays in the historical index file are initialized.

[0020] The historical index file after initialization is used as the index file for the code file to be tested.

[0021] Optionally, the acquisition module is further configured to:

[0022] If the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, then the sub-file identifiers corresponding to each of the at least one sub-files are compared with the sub-file identifiers corresponding to the historical sub-files in the historical index file.

[0023] The probe count arrays corresponding to the historical subfiles that have the same subfile identifier are initialized, and the initialized probe count arrays are used as the probe count arrays corresponding to the subfiles in the code file to be tested.

[0024] Generate probe count arrays corresponding to other subfiles in the code file to be tested;

[0025] Based on the root file identifier corresponding to the code file under test, the sub-file identifiers corresponding to each of the at least one sub-file, and the probe count array, the index file of the code file under test is obtained.

[0026] Optionally, the types of code logic branches include: sequential execution logic branches, unconditional jump logic branches, conditional jump logic branches, exception handling logic branches, and return logic branches.

[0027] Optionally, the update module is specifically used for:

[0028] If the test probe is triggered, the position information of the test probe in the code file under test is obtained, wherein the position information includes the root file identifier, the target sub-file identifier, and the target logic branch;

[0029] Based on the root file identifier, the target sub-file identifier, and the target logical branch, the index file is queried to determine the target probe count array associated with the test probe in the index file, as well as the target element corresponding to the target probe count array, and the target element is incremented by a preset value.

[0030] Optionally, the statistics module is specifically used for:

[0031] The total length of each probe count array in the index file is taken as the total number of test probes;

[0032] The number of elements greater than zero in each probe count array is taken as the number of triggered probes;

[0033] The ratio of the number of triggered probes to the total number of test probes is used as the code coverage of the code file under test.

[0034] Optionally, the code file to be tested is the original code file or a copied code file.

[0035] On one hand, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the above-described code coverage detection method.

[0036] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described code coverage detection method.

[0037] In this embodiment, the code file to be tested and its corresponding index file are obtained. During the execution of the code file, for each test probe inserted into the code file, if the test probe is triggered, the target element associated with the test probe in the index file is determined and updated. At the end of the execution of the code file, the code coverage of the code file is determined based on the elements in the probe count arrays of each probe in the index file. When a test probe is triggered, the elements in the probe count arrays associated with the test probe are quickly determined using the index file, improving the search speed. Each test probe in the sub-file corresponds one-to-one with the elements in the probe count arrays, improving the accuracy of code coverage detection. Attached Figure Description

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

[0039] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0040] Figure 2 A flowchart illustrating a method for detecting code coverage provided in an embodiment of this application;

[0041] Figure 3 This application provides a schematic diagram of the structure for constructing an index file corresponding to a code file to be tested, as shown in an embodiment of the present application.

[0042] Figure 4 This application provides a schematic diagram of the structure for constructing an index file corresponding to a code file to be tested, as shown in an embodiment of the present application.

[0043] Figure 5 This application provides a schematic diagram of the structure of a sequential execution logic branch before inserting a test probe, as shown in the embodiments of this application.

[0044] Figure 6 This application provides a schematic diagram of the structure of a sequential execution logic branch after inserting a test probe, as shown in the embodiments of this application.

[0045] Figure 7 This application provides a schematic diagram of the structure of a sequential execution logic branch after inserting a test probe, as shown in the embodiments of this application.

[0046] Figure 8 This application provides a schematic diagram of the structure of an unconditional jump logic branch before inserting a test probe, as shown in the embodiments of this application.

[0047] Figure 9 This application provides a schematic diagram of the structure of an unconditional jump logic branch after inserting a test probe, as shown in the embodiments of this application.

[0048] Figure 10 This application provides a schematic diagram of a conditional jump logic branch before inserting a test probe, as shown in an embodiment of the present application.

[0049] Figure 11 This application provides a schematic diagram of a conditional jump logic branch structure after inserting a test probe;

[0050] Figure 12 This application provides a schematic diagram of the structure of an exception handling logic branch before inserting a test probe, as shown in an embodiment of the present application.

[0051] Figure 13 This application provides a schematic diagram of the structure of an exception handling logic branch after inserting a test probe, as shown in an embodiment of the present application.

[0052] Figure 14 This application provides a schematic diagram of the return logic branch before inserting a test probe, as shown in an embodiment of the present application.

[0053] Figure 15 This application provides a schematic diagram of the return logic branch structure after inserting a test probe, as shown in an embodiment of the present application.

[0054] Figure 16 This application provides a schematic diagram of the structure of a historical index file.

[0055] Figure 17 This application provides a schematic diagram of the structure of a code file to be tested.

[0056] Figure 18 This is a schematic diagram of the structure of an index file provided in an embodiment of this application;

[0057] Figure 19 This application provides a schematic diagram of the structure of a code file to be tested.

[0058] Figure 20 This is a schematic diagram of the structure of an index file provided in an embodiment of this application;

[0059] Figure 21 This application provides a schematic diagram of the structure of a historical index file.

[0060] Figure 22 This application provides a schematic diagram of the structure of a code file to be tested.

[0061] Figure 23 This is a schematic diagram of the structure of an index file provided in an embodiment of this application;

[0062] Figure 24 This application provides a schematic diagram of the structure of a code file to be tested.

[0063] Figure 25 This is a schematic diagram of the structure of an index file provided in an embodiment of this application;

[0064] Figure 26 This is a schematic diagram of the structure of an index file provided in an embodiment of this application;

[0065] Figure 27 This is a schematic diagram of the structure of a probe counting array provided in an embodiment of this application;

[0066] Figure 28 This is a schematic diagram of the structure of a probe counting array provided in an embodiment of this application;

[0067] Figure 29 This is a schematic diagram of the structure of a probe counting array provided in an embodiment of this application;

[0068] Figure 30 A flowchart illustrating a method for detecting code coverage provided in an embodiment of this application;

[0069] Figure 31 A schematic diagram of a code coverage detection device provided in an embodiment of this application;

[0070] Figure 32 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0071] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0072] For ease of understanding, the terms used in the embodiments of this invention are explained below.

[0073] Test Coverage: Coverage is a means of measuring test completeness, a standard for measuring test effectiveness, and a measure of the effectiveness of testing techniques. Coverage = (number of items that were executed at least once) / (total number of items).

[0074] Automated testing: Automated testing programs, written in a programming language, control the execution of the software under test, simulating manual testing steps to verify various software testing requirements and complete fully or semi-automated testing. It includes the management and implementation of testing activities, and the development and execution of test scripts.

[0075] Bytecode: A binary file containing an executable program, consisting of a sequence of op code / data pairs; in this article, it specifically refers to the compiled output of Java source files.

[0076] JVM: Short for Java Virtual Machine. The JVM is a specification for computing devices. The Java language uses the JVM to shield itself from platform-specific information, allowing Java compilers to generate only the target code (bytecode) that runs on the JVM, enabling it to run unmodified on various platforms.

[0077] JVMPI: short for Java Virtual Machine Profiler Interface, is a bidirectional function call interface between the Java Virtual Machine and the monitoring agent in the process.

[0078] JVMTI: Short for Java Virtual Machine Tool Interface, it's located at the lowest level of JPDA and is a native programming interface provided by the Java Virtual Machine. JVMTI can provide functions such as performance analysis, debugging, memory management, and thread analysis.

[0079] JaCoCo: short for JavaCodeCoverage, is an open-source tool for calculating Java code coverage.

[0080] Byte Buddy: A technology that enables dynamic modification of bytecode, providing an expressive domain-specific language that allows for the creation of custom runtime classes by writing simple code and using powerful types.

[0081] ASM: A Java bytecode manipulation framework used to dynamically generate classes or enhance the functionality of existing classes. It can directly generate binary class files or dynamically change class behavior before the class is loaded into the Java Virtual Machine.

[0082] refer to Figure 1 This is a system architecture diagram applicable to the embodiments of this application. The system architecture includes at least a terminal device 101 and a code coverage detection system 102.

[0083] The terminal device 101 has a target application installed for detecting code coverage. This application can be a pre-installed client, a web application, or a mini-program embedded in other applications. The terminal device 101 can be a smartphone, tablet, laptop, desktop computer, etc., but is not limited to these.

[0084] The code coverage detection system 102 serves as the backend server for the target application, providing services to it. The code coverage detection system 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal device 101 and the code coverage detection system 102 can be directly or indirectly connected via wired or wireless communication; this application does not impose any restrictions on this connection.

[0085] In response to a user submitting a code file to be tested, terminal device 101 sends the submitted code file to code coverage detection system 102. Code coverage detection system 102 receives the submitted code file and stores it in the system.

[0086] The code coverage detection system 102 acquires the code file to be tested and its corresponding index file. The code file to be tested includes at least one sub-file. The index file includes the association between the root file identifier of the code file to be tested and the sub-file identifiers of each of the at least one sub-file, as well as a probe count array for each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the sub-file. During the execution of the code file to be tested, for each test probe inserted in the code file, if the test probe is triggered, the target element associated with the test probe in the index file is determined and updated. At the end of the execution of the code file to be tested, the code coverage of the code file to be tested is determined based on the elements in each probe count array in the index file.

[0087] based on Figure 1 The system architecture diagram described above, and the embodiments of this application provide a flowchart for a method to detect code coverage, such as... Figure 2 As shown, the process of this method is executed by a computer device, which can be... Figure 1 The code coverage detection system 102 shown includes the following steps:

[0088] Step S201: Obtain the code file to be tested and the corresponding index file.

[0089] Specifically, the code file to be tested includes at least one sub-file, and the index file includes the association between the root file identifier corresponding to the code file to be tested and the sub-file identifiers corresponding to each of the at least one sub-file, as well as the probe count array corresponding to each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file, wherein a code logic branch may correspond to one or more test probes.

[0090] Different versions of the code file under test correspond to different root file identifiers and sub-file identifiers. By using the root file identifier and sub-file identifiers, different versions of the code file under test can be identified, thereby enabling code coverage comparison between different versions of the code file under test.

[0091] The MD5 algorithm is used to encrypt the attribute information (such as filename, file number, file summary, etc.) of the code file under test to obtain the root file identifier of the code file under test. The MD5 algorithm is then used to encrypt the attribute information (such as filename, file number, file summary, etc.) of each sub-file to obtain the sub-file identifier of each sub-file. MD5 algorithms include 16-bit MD5, 32-bit MD5, and 64-bit MD5 algorithms.

[0092] The code file to be tested is either the original code file or a copied code file. Inserting test probes into the copied code file for code coverage detection can effectively prevent code contamination. Furthermore, in this embodiment, test probes can be inserted into the copied code file for code coverage detection, while unit tests are performed in the original code file, effectively resolving the conflict between test probes and unit tests.

[0093] Step S202: During the execution of the code file to be tested, for each test probe inserted in the code file to be tested, if the test probe is triggered, the target element associated with the test probe in the index file is determined and the target element is updated.

[0094] In one possible implementation, if a test probe is triggered, the target element associated with that test probe in the index file is determined, and that target element is set to 1. The target element indicates whether the test probe has been triggered. If the target element is 1, it means that the test probe has been triggered; if it is 0, it means that the test probe has not been triggered.

[0095] Another possible implementation involves determining the target element associated with the test probe in the index file when it is triggered, and incrementing the target element by 1. The target element represents the number of times the test probe has been triggered. Since the probe count array records the number of times each test probe is triggered, not only can code coverage statistics be performed, but other business analyses can also be conducted based on the number of times each test probe is triggered.

[0096] Step S203: When the test code file finishes running, determine the code coverage of the test code file based on the elements in the probe count arrays in the index file.

[0097] Specifically, code coverage includes statement coverage, function coverage, interface coverage, etc.

[0098] In this embodiment, the code file to be tested and its corresponding index file are obtained. During the execution of the code file, for each test probe inserted into the code file, if the test probe is triggered, the target element associated with the test probe in the index file is determined and updated. At the end of the execution of the code file, the code coverage of the code file is determined based on the elements in the probe count arrays of each probe in the index file. When a test probe is triggered, the elements in the probe count arrays associated with the test probe are quickly determined using the index file, improving the search speed. Each test probe in the sub-file corresponds one-to-one with the elements in the probe count arrays, improving the accuracy of code coverage detection.

[0099] Optionally, in step S201 above, an index file corresponding to the code file under test is constructed based on the association between the code file under test and at least one sub-file, and the code logic branches contained in each of the at least one sub-file.

[0100] Specifically, each sub-file can also include second-level sub-files, third-level sub-files, and so on.

[0101] One possible implementation involves determining the root file identifier corresponding to the code file under test using the MD5 algorithm, and determining the sub-file identifiers corresponding to each sub-file using the MD5 algorithm. Based on the association between the code file under test and each sub-file, the association relationship between the root file identifier and each sub-file identifier is determined.

[0102] The system counts the number of code logic branches contained in each subfile and assigns a probe count array to each subfile, associating each subfile identifier with its corresponding probe count array. The size of the probe count array is equal to the number of code logic branches, and each element in the probe count array is associated with a test probe corresponding to one of the code logic branches contained in the subfile.

[0103] For example, such as Figure 3 As shown, the code file to be tested is file 0. This file contains three sub-files: sub-file 1.1, sub-file 1.2, and sub-file 1.3. Sub-file 1.1 contains two second-level sub-files: sub-file 1.1.1 and sub-file 1.1.2. Sub-file 1.3 contains one second-level sub-file, sub-file 1.3.1, which in turn contains one third-level sub-file, sub-file 1.3.1.2.

[0104] The filename of file 0 is encrypted using a 32-bit MD5 algorithm to obtain the root file identifier corresponding to the code file under test, namely root file identifier 0. The filenames of subfiles 1.1, 1.2, and 1.3 are then encrypted using the same 32-bit MD5 algorithm to obtain the subfile identifiers corresponding to the code file under test, namely subfile identifier 1, subfile identifier 2, and subfile identifier 3.

[0105] Based on the association between file 0 and subfiles 1.1, 1.2, and 1.3, determine the association between root file identifier 0, subfile identifier 1, subfile identifier 2, and subfile identifier 3.

[0106] Count the number of code logic branches contained in subfile 1.1, that is, count the number of code logic branches contained in subfile 1.1.1 and subfile 1.1.2 respectively.

[0107] Subfile 1.1.1 contains two code logic branches, namely code logic branch 1 and code logic branch 2. Subfile 1.1.2 contains one code logic branch, namely code logic branch 3.

[0108] Allocate a probe count array 1 of size 3 for subfile 1.1, and associate subfile identifier 1 with probe count array 1. The first element of probe count array 1 is associated with the test probe corresponding to code logic branch 1, the second element is associated with the test probe corresponding to code logic branch 2, and the third element is associated with the test probe corresponding to code logic branch 3.

[0109] Similarly, count the number of code logic branches contained in subfile 1.2. Assume subfile 1.2 contains one code logic branch, namely code logic branch 4. Allocate a probe count array 2 of size 1 for subfile 1.2, and associate the subfile identifier 2 with probe count array 2. Associate the first element in probe count array 2 with the test probe corresponding to code logic branch 4.

[0110] Count the number of code logic branches contained in subfile 1.3, which is equivalent to counting the number of code logic branches contained in subfile 1.3.1.2. Assume subfile 1.3.1.2 contains two code logic branches: code logic branch 5 and code logic branch 6. Allocate a probe count array 3 of size 2 for subfile 1.3 and associate the subfile identifier 3 with the probe count array 3. Associate the first element in the probe count array 3 with the test probe corresponding to code logic branch 5, and the second element with the test probe corresponding to code logic branch 6.

[0111] In this application, a probe count array is constructed for each subfile based on the number of code logic branches contained in each subfile. Simultaneously, each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the subfile. Then, an index file is constructed based on the association between the code file under test and each subfile, as well as the probe count array. This index file allows for the rapid identification of the element in the probe count array associated with each logic branch, significantly reducing search time.

[0112] Another possible implementation involves determining the root file identifier corresponding to the code file under test using the MD5 algorithm, and then determining the sub-file identifiers corresponding to each sub-file using the MD5 algorithm. Based on the association between the code file under test and each sub-file, the association between the root file identifier and each sub-file identifier is determined.

[0113] Identify the last-level subfile for each subfile, count the number of code logic branches contained in each last-level subfile, and assign a probe count array to each last-level subfile. Associate each subfile identifier with its corresponding probe count array. The size of the probe count array is equal to the number of code logic branches, and each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the last-level subfile.

[0114] For example, such as Figure 4As shown, the code file to be tested is file 0. This file contains three sub-files: sub-file 1.1, sub-file 1.2, and sub-file 1.3. Sub-file 1.1 contains two second-level sub-files: sub-file 1.1.1 and sub-file 1.1.2. Sub-file 1.3 contains one second-level sub-file, sub-file 1.3.1, which in turn contains one third-level sub-file, sub-file 1.3.1.2.

[0115] The filename of file 0 is encrypted using a 32-bit MD5 algorithm to obtain the root file identifier corresponding to the code file under test, namely root file identifier 0. The filenames of subfiles 1.1, 1.2, and 1.3 are then encrypted using the same 32-bit MD5 algorithm to obtain the subfile identifiers corresponding to the code file under test, namely subfile identifier 1, subfile identifier 2, and subfile identifier 3.

[0116] Based on the association between file 0 and subfiles 1.1, 1.2, and 1.3, determine the association between root file identifier 0, subfile identifier 1, subfile identifier 2, and subfile identifier 3.

[0117] The last-level subfiles of subfile 1.1 are defined as subfile 1.1.1 and subfile 1.1.2. Subfile 1.1.1 is defined as containing two code logic branches, namely code logic branch 1 and code logic branch 2. Subfile 1.1.2 contains one code logic branch, namely code logic branch 3.

[0118] Allocate a probe count array 1.1 of size 2 for subfile 1.1.1, and a probe count array 1.2 of size 1 for subfile 1.1.2. Associate subfile identifier 1 with probe count arrays 1.1 and 1.2. Associate the first element of probe count array 1.1 with the test probe corresponding to code logic branch 1, and the second element with the test probe corresponding to code logic branch 2. Associate the first element of probe count array 1.2 with the test probe corresponding to code logic branch 3.

[0119] Subfile 1.2 is the last-level subfile. Subfile 1.2 is defined to include one code logic branch, namely code logic branch 4. A probe count array 2 of size 1 is allocated to subfile 1.2, and the subfile identifier 2 is associated with probe count array 2. The first element in probe count array 2 is associated with the test probe corresponding to code logic branch 4.

[0120] The last-level subfile in subfile 1.3 is 1.3.1.2. Subfile 1.3.1.2 is defined to include two code logic branches: code logic branch 5 and code logic branch 6. A probe count array 3 of size 2 is allocated to subfile 1.3, and the subfile identifier 3 is associated with probe count array 3. The first element in probe count array 3 is associated with the test probe corresponding to code logic branch 5, and the second element in probe count array 3 is associated with the test probe corresponding to code logic branch 6.

[0121] In this application, a probe count array is constructed for each last-level sub-file based on the number of code logic branches contained in each last-level sub-file. Simultaneously, each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the last-level sub-file. An index file is constructed based on the association between the code file under test and each sub-file, as well as the probe count array. This index file allows for the rapid identification of the element in the probe count array associated with each logic branch, significantly reducing search time. Since a probe count array is constructed for each last-level sub-file, the problem of excessively large array allocation exceeding memory limits can be effectively avoided.

[0122] Optionally, in step S201 above, the types of code logic branches include: sequential execution logic branches, unconditional jump logic branches, conditional jump logic branches, exception handling logic branches, and return logic branches.

[0123] Specifically, sequential execution of logical branches means executing the logical sequence of code sequentially.

[0124] In one possible implementation, the sequential execution logic branches include multiple code logics, with a test probe inserted between every two code logics.

[0125] For example, the execution flow before inserting the test probe is as follows: Figure 5 As shown, the sequential execution sequence of code logic is code logic A, code logic B, code logic C, and code logic D.

[0126] Insert test probe P1 between code logic A and code logic B, test probe P2 between code logic B and code logic C, and test probe P3 between code logic C and code logic D. The execution flow after inserting the probes is as follows. Figure 6 As shown, the execution order is: code logic A, test probe P1, code logic B, test probe P2, code logic C, test probe P3, and code logic D.

[0127] In this application, test probes are inserted between every two pieces of code logic in the sequential execution logic branches, which can improve the accuracy of code coverage detection.

[0128] In another possible implementation, the sequential execution logic branch includes multiple code logics, with a test probe inserted between the first and second code logics, and a test probe inserted between the penultimate and last code logics.

[0129] Insert test probe P1 between code logic A and code logic B, and insert test probe P2 between code logic C and code logic D. The execution flow after inserting the probes is as follows. Figure 7 As shown, the execution order is: code logic A, test probe P1, code logic B, code logic C, test probe P2, and code logic D.

[0130] In this application, only two test probes are inserted in the sequential execution logic branches, namely, a test probe is inserted between the first and second code logics, and a test probe is inserted between the second-to-last and last code logics. This can effectively reduce the number of test probes inserted while ensuring the accuracy of the detected code coverage.

[0131] Specifically, an unconditional jump logic branch refers to a branch where, upon reaching a jump instruction, no conditional checks are required; the code logic pointed to by the jump instruction is executed directly. A test probe is inserted before the jump instruction in an unconditional jump logic branch.

[0132] For example, the execution flow before inserting the test probe is as follows: Figure 8 As shown, the execution sequence is code logic A, GOTO instruction, and code logic C. A test probe P is inserted before the GOTO instruction. The execution flow after inserting the test probe is as follows: Figure 9 As shown, the execution sequence is code logic A, test probe P, GOTO instruction, and code logic C.

[0133] Specifically, a conditional jump logic branch refers to executing one of several given sequences based on a decision condition. When inserting a test probe into an unconditional jump logic branch, a test probe needs to be inserted into each branch of the decision condition.

[0134] For example, the execution flow before inserting the test probe is as follows: Figure 10 As shown, based on the judgment result of the judgment condition, one of two sequences is executed. The first execution sequence is the GOTO instruction followed by code logic B. The second execution sequence is code logic A. A test probe is inserted into each of the two execution sequences. The execution flow after inserting the test probe is as follows. Figure 11 As shown, the first execution sequence is test probe P1, GOTO instruction, code logic B, and the second execution sequence is test probe P1, code logic A.

[0135] Specifically, the exception handling logic branch is used to handle exceptions that occur during runtime. A test probe is inserted before the exception handling instruction in the exception handling logic branch.

[0136] For example, the execution flow before inserting the test probe is as follows: Figure 12 As shown, the execution sequence is exception handling instruction followed by termination. A test probe P is inserted before the exception handling instruction. The execution flow after inserting the test probe is as follows: Figure 13 As shown, the execution sequence is test probe P, exception handling instruction, and end.

[0137] Specifically, the return logical branch is used to return the execution result. A test probe is inserted before the return instruction in the return logical branch.

[0138] For example, the execution flow before inserting the test probe is as follows: Figure 14 As shown, the execution sequence is return instruction followed by termination. A test probe P is inserted before the return instruction, and the execution flow after the test probe is inserted is as follows. Figure 15 As shown, the execution sequence is test probe P, return command, and end.

[0139] In this application, by inserting test probes into the above-mentioned code logic branches, not only can various situations in the code file under test be effectively covered, but the number of test probes inserted can also be effectively reduced.

[0140] Optionally, in step S201 above, when it is determined that the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, and that the sub-file identifiers corresponding to at least one sub-file are different from the sub-file identifiers corresponding to the historical sub-files in the historical index file, an index file corresponding to the code file to be tested is constructed based on the association relationship between the code file to be tested and at least one sub-file, and the code logic branches contained in each of the at least one sub-file.

[0141] One possible implementation involves determining the root file identifier of the code file under test using the MD5 algorithm, and then determining the sub-file identifiers for each sub-file using the same MD5 algorithm. If the root file identifier of the file under test differs from the root file identifier in the historical index file, and all sub-file identifiers of the file under test differ from those in the historical index file, then the number of code logic branches contained in each sub-file is counted. A probe count array is assigned to each sub-file, and each sub-file identifier is associated with its corresponding probe count array. The size of the probe count array is equal to the number of code logic branches. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file, and the elements in the probe count array are initialized to 0.

[0142] For example, historical index files such as Figure 16As shown, in the historical index file, root file identifier 0 corresponds to sub-file identifier 1 and sub-file identifier 2. Sub-file identifier 1 corresponds to probe count array 1, and sub-file identifier 2 corresponds to probe count array 2.

[0143] like Figure 17 As shown, the code file to be tested is file 1, which includes two sub-files, namely sub-file 3 and sub-file 4.

[0144] The filename of file 1 is encrypted using a 32-bit MD5 algorithm to obtain root file identifier 1; the filename of subfile 3 in the code under test is encrypted to obtain subfile identifier 3; the filename of subfile 4 in the code under test is encrypted to obtain subfile identifier 4.

[0145] By comparison, it can be seen that the root file identifier 1 of the code file under test is different from the root file identifier 0 in the historical index file; the sub-file identifier 3 of the code file under test is different from the sub-file identifier 1 and sub-file identifier 2 in the historical index file; and the sub-file identifier 4 of the code file under test is different from the sub-file identifier 1 and sub-file identifier 2 in the historical index file.

[0146] Count the number of code logic branches in subfile 3. Assuming subfile 3 has one code logic branch, allocate a probe count array 3 of size 1 for subfile 3 and set all elements in probe count array 3 to 0. Simultaneously, associate subfile identifier 3 with probe count array 3. Count the number of code logic branches in subfile 4. Assuming subfile 4 has two code logic branches, construct a probe count array 4 of size 2 for subfile 4 and set all elements in probe count array 4 to 0. Simultaneously, associate subfile identifier 4 with probe count array 4.

[0147] Based on the relationships between the root file identifier 1 and sub-file identifiers 3 and 4 of the file under test, as well as the relationships between sub-file identifier 3 and probe count array 3, and sub-file identifier 4 and probe count array 4, an index file corresponding to the code file under test is constructed, such as... Figure 18 As shown.

[0148] Another possible implementation involves determining the root file identifier of the code file under test using the MD5 algorithm, and then determining the sub-file identifiers of each sub-file using the same MD5 algorithm. If the root file identifier of the file under test differs from the root file identifier in the historical index file, and all sub-file identifiers of the file under test differ from those in the historical index file, then the last-level sub-file of each sub-file in the code file under test is determined. The number of code logic branches contained in each last-level sub-file is counted, and a probe count array is allocated to each last-level sub-file. Each sub-file identifier is associated with its corresponding probe count array. The size of the probe count array is equal to the number of code logic branches. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the last-level sub-file, and the elements in the probe count array are initialized to 0.

[0149] For example, historical index files such as Figure 16 As shown, in the historical index file, root file identifier 0 corresponds to sub-file identifier 1 and sub-file identifier 2. Sub-file identifier 1 corresponds to probe count array 1, and sub-file identifier 2 corresponds to probe count array 2.

[0150] like Figure 19 As shown, the code file to be tested is file 1, which includes two sub-files: sub-file 3 and sub-file 4. Sub-file 4 includes two second-level sub-files: sub-file 4.1 and sub-file 4.2.

[0151] The filename of file 1 is encrypted using a 32-bit MD5 algorithm to obtain root file identifier 1; the filename of subfile 3 in the code under test is encrypted to obtain subfile identifier 3; the filename of subfile 4 in the code under test is encrypted to obtain subfile identifier 4.

[0152] By comparison, it can be seen that the root file identifier 1 of the code file under test is different from the root file identifier 0 in the historical index file; the sub-file identifier 3 of the code file under test is different from the sub-file identifier 1 and sub-file identifier 2 in the historical index file; and the sub-file identifier 4 of the code file under test is different from the sub-file identifier 1 and sub-file identifier 2 in the historical index file.

[0153] Subfile 3 is determined to be the last-level subfile, and the last-level subfiles of subfile 4 are subfiles 4.1 and 4.2. The number of code logic branches contained in subfile 3 is counted. Assuming there is one code logic branch in subfile 3, a probe count array 3 of size 1 is allocated to subfile 3, and the elements in probe count array 3 are set to 0. Simultaneously, the subfile identifier 3 is associated with probe count array 3.

[0154] Count the number of code logic branches in subfiles 4.1 and 4.2 respectively. Assuming that subfile 4.1 and 4.2 each have one code logic branch, allocate a probe count array 4.1 of size 1 for subfile 4.1 and a probe count array 4.2 of size 1 for subfile 4.2. Set the elements in probe count arrays 4.1 and 4.2 to 0. Simultaneously, associate the subfile identifier 4 with probe count arrays 4.1 and 4.2.

[0155] Based on the relationships between the root file identifier 1 and sub-file identifiers 3 and 4 of the file under test, the relationships between sub-file identifier 3 and probe count array 3, and between sub-file identifier 4 and probe count arrays 4.1 and 4.2, an index file corresponding to the file under test is constructed, such as... Figure 20 As shown.

[0156] Optionally, in step S201 above, if the root file identifier of the code file to be tested is the same as the root file identifier in the historical index file, then the probe count arrays in the historical index file are initialized. The initialized historical index file is then used as the index file of the code file to be tested.

[0157] Specifically, if the root file identifier of the code file under test is the same as the root file identifier in the historical index file, it means that the code file under test has not been modified. Therefore, the elements in each probe count array in the historical index file are initialized to 0, and the initialized historical index file is used as the index file for the code file under test.

[0158] If the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, then the sub-file identifier corresponding to at least one sub-file is compared with the sub-file identifier corresponding to the historical sub-file in the historical index file.

[0159] The probe count arrays corresponding to historical subfiles with the same subfile identifier are initialized, and the initialized probe count arrays are used as the probe count arrays corresponding to the subfiles in the code file under test. Probe count arrays corresponding to other subfiles in the code file under test are generated. Then, based on the root file identifier of the code file under test, the subfile identifiers of at least one subfile, and the probe count arrays, the index file of the code file under test is obtained.

[0160] Specifically, if the root file identifier of the code file under test differs from the root file identifier in the historical index file, it indicates that the code file under test has been modified. Therefore, the sub-file identifiers of the code file under test are then compared with the sub-file identifiers in the historical index file.

[0161] For each subfile identifier in the code file under test, if the subfile identifier is the same as the subfile identifier in the historical index file, the probe count array corresponding to the historical subfile is initialized to 0, and this probe count array is used as the probe count array for the corresponding subfile in the code file under test. If the subfile identifier in the code file under test is different from the subfile identifier in the historical index file, a probe count array is constructed for that subfile in the code file under test. The size of the probe count array is equal to the number of code logic branches contained in the subfile, and the elements in the probe count array are initialized to 0.

[0162] For example, historical index files such as Figure 21 As shown, in the historical index file, root file identifier 0 is associated with sub-file identifier 1 and sub-file identifier 2. Sub-file identifier 1 is associated with probe count array 1, and sub-file identifier 2 is associated with probe count array 2. The size of probe count array 1 is 1, and the size of probe count array 2 is 2.

[0163] like Figure 22 As shown, the code file to be tested is file 0, which includes two sub-files, namely sub-file 1 and sub-file 3.

[0164] The filename of file 0 is encrypted using a 32-bit MD5 algorithm to obtain the root file identifier 0; the filename of subfile 1 in the code under test is encrypted to obtain the subfile identifier 1; and the filename of subfile 3 in the code under test is encrypted to obtain the subfile identifier 3.

[0165] Since the root file identifier 0 of the code file under test is the same as the root file identifier 0 in the historical index file, and the sub-file identifier 1 of the code file under test is the same as the sub-file identifier 1 in the historical index file, all elements in probe count array 1 are initialized to 0. Probe count array 1 is then used as the probe count array corresponding to sub-file 1 in the code file under test, and sub-file identifier 1 is associated with probe count array 1. Sub-file identifier 3 of the code file under test is different from sub-file identifier 1 and sub-file identifier 2 in the historical index file. It is assumed that there are 3 code logic branches in sub-file 3. A probe count array 3 of size 3 is allocated to sub-file 3, and the elements in the probe count array are initialized to 0. Simultaneously, sub-file identifier 3 is associated with probe count array 3.

[0166] Based on the relationships between the root file identifier 0 and sub-file identifiers 1 and 3 of the file under test, as well as the relationships between sub-file identifier 1 and probe count array 1, and sub-file identifier 3 and probe count array 3, an index file corresponding to the file under test is constructed, such as... Figure 23As shown.

[0167] Optionally, in step S202 above, if the test probe is triggered, the location information of the test probe in the code file to be tested is obtained, wherein the location information includes the root file identifier, the target sub-file identifier, and the target logic branch. Based on the root file identifier, the target sub-file identifier, and the target logic branch, the index file is queried to determine the target probe count array associated with the test probe in the index file, as well as the corresponding target element in the target probe count array, and the target element is incremented by a preset value.

[0168] Specifically, the preset value can be 1 or other numbers.

[0169] For example, such as Figure 24 As shown, the code file to be tested is file 0, which includes two sub-files: sub-file 1 and sub-file 2. Sub-file 1 contains a sequential execution logic branch after inserting a test probe, with the execution order being: code logic A, test probe P1, code logic B, test probe P2, and code logic C. Sub-file 2 contains an unconditional jump logic branch after inserting a test probe, with the execution order being: code logic A, test probe P3, GOTO instruction, and code logic C.

[0170] Figure 24 The index file corresponding to the code file to be tested shown is as follows: Figure 25 As shown, file 0 is identified by root file identifier 0, subfile 1 by subfile identifier 1, and subfile 2 by subfile identifier 2. The probe count array 1 corresponding to subfile 1 has a length of 2. The first position of probe count array 1 records the number of times test probe P1 is triggered, and the second position records the number of times test probe P2 is triggered. The probe count array 2 corresponding to subfile 2 has a length of 1. The first position of probe count array 2 records the number of times test probe P3 is triggered. Probe count array 1 and probe count array 2 are initialized to 0.

[0171] After the test probe is triggered, the updated index file is as follows: Figure 26 As shown. When test probe P1 is triggered, the target element at the first position in probe count array 1 is updated from 0 to 1. When test probe P2 is triggered, the target element at the second position in probe count array 1 is updated from 0 to 1. When test probe P3 is triggered, the target element at the first position in probe count array 2 is updated from 0 to 1.

[0172] Optionally, in step S203 above, this application embodiment provides at least the following implementation methods for determining the code coverage of the code file to be tested:

[0173] Implementation Method 1: When code coverage is statement coverage, the total length of each probe count array in the index file is taken as the total number of test probes. The number of elements greater than zero in each probe count array is taken as the number of triggered probes. Finally, the ratio of the number of triggered probes to the total number of test probes is taken as the code coverage of the code file under test.

[0174] Implementation Method 2: When code coverage is function coverage, the probe count array is divided into multiple sub-probe count arrays based on the functions contained in the code file under test. Each sub-probe count array corresponds to one function. The total number of sub-probe count arrays is taken as the total number of test probes, and the number of sub-probe count arrays with non-zero elements is taken as the number of triggered probes. Finally, the ratio of the number of triggered probes to the total number of test probes is taken as the function coverage of the code file under test.

[0175] Implementation Method 3: When code coverage is interface coverage, the probe count array is divided based on each interface contained in the code file under test, resulting in multiple sub-probe count arrays. Each sub-probe count array corresponds to one interface. The total number of sub-probe count arrays is counted as the total number of test probes, and the number of sub-probe count arrays with non-zero elements is counted as the number of triggered probes. Finally, the ratio of the number of triggered probes to the total number of test probes is used as the interface coverage of the code file under test.

[0176] For example, such as Figure 27 As shown, the index file includes probe count array 1 and probe count array 2. Probe count array 1 has a length of 4, probe count array 2 has a length of 3, and the total number of test probes is 7.

[0177] When the code coverage is equal to the statement coverage, the number of elements greater than zero in probe count array 1 is 3, the number of elements greater than zero in probe count array 2 is 2, and the number of triggered probes is 5. Therefore, the code coverage of the code file under test is 5 / 7.

[0178] When code coverage is function coverage, based on the functions contained in the code file under test, probe count array 1 is divided into 3 sub-probe count arrays. Probe count array 2 is divided into 2 sub-probe count arrays. The results after division are as follows: Figure 28 As shown, the number of sub-probe count arrays is 5, therefore the total number of test probes is 5. Three of the 5 sub-probe count arrays contain non-zero elements, triggering 3 probes. Therefore, the code coverage of the code file under test is 3 / 5.

[0179] When code coverage is equal to interface coverage, based on each interface contained in the code file under test, probe count array 1 is divided into two sub-probe count arrays. Probe count array 2 is also divided into two sub-probe count arrays, as shown below. Figure 29 As shown. The number of sub-probe count arrays is 4, so the total number of test probes is 4. Three of the 4 sub-probe count arrays contain non-zero elements, and the number of triggered probes is 3. Therefore, the code coverage of the code file under test is 3 / 4.

[0180] In this application, the probe count array can be divided based on different code coverage statistics requirements. Depending on the division results, statement coverage, function coverage, and interface coverage of the code file under test can be calculated separately, enhancing the diversity of code coverage statistics and facilitating subsequent analysis.

[0181] To better explain the embodiments of this application, the following uses a specific implementation scenario as an example to describe the flow of a code coverage detection method provided by the embodiments of this application, such as... Figure 30 As shown:

[0182] Step S3001: Generate the root file identifier corresponding to the code file to be tested.

[0183] Step S3002: Determine if a historical index file exists. If yes, proceed to step S3012; otherwise, proceed to step S3003.

[0184] Step S3003: Generate subfile identifiers corresponding to each subfile in the code file to be tested.

[0185] Step S3004: Determine the code logic branch in each sub-file.

[0186] Specifically, you can obtain the code logic branches in each sub-file through Byte Buddy, or you can obtain the code logic branches in each sub-file through ASM.

[0187] Step S3005: Assign a corresponding probe count array to each subfile.

[0188] Specifically, each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding subfile.

[0189] Step S3006: Insert test probes into the code logic branches.

[0190] Specifically, test probes can be inserted via Byte Buddy or via ASM.

[0191] Step S3007: Run the program example.

[0192] Step S3008: Update the probe count array.

[0193] If a test probe is triggered, the element in the probe count array corresponding to the test probe is incremented by 1.

[0194] Step S3009: Stop the program instance.

[0195] Step S3010: Record each element in the probe count array and persist the probe count array. At the same time, save the root file identifier of the code file to be tested, the identifiers of each sub-file, and the probe count array as a historical index file.

[0196] Step S3011: Calculate code coverage and generate a report.

[0197] Step S3012: Determine whether the root file identifier of the code file to be tested is the same as the root file identifier in the historical index file. If yes, proceed to step S3013; otherwise, proceed to step S3015.

[0198] Step S3013: Initialize each probe count array in the historical index file to 0.

[0199] Step S3014: Use the historical index file as the index file corresponding to the code file to be tested, and jump to step S3007.

[0200] Step S3015: Generate subfile identifiers corresponding to each subfile in the code file to be tested.

[0201] Step S3016: Set variable i = 1.

[0202] Step S3017: Obtain the identifier of the i-th sub-file.

[0203] Step S3018: Determine whether i is less than or equal to the total number of subfile identifiers in the code file to be tested. If yes, proceed to step S3019; otherwise, jump to step S3007.

[0204] Step S3019: Determine whether the sub-file identifier of the code file to be tested is the same as the sub-file identifier in the historical index file. If yes, proceed to step S3020; otherwise, proceed to step S3023.

[0205] Step S3020: Initialize the probe count array corresponding to the sub-file identifier in the historical index file to 0.

[0206] Step S3021: Use the probe count array as the probe count array corresponding to the subfile identifier in the code file to be tested.

[0207] Step S3022, update variable i, i = i + 1.

[0208] Step S3023: Determine the code logic branches in the sub-files of the code to be tested.

[0209] Step S3024: Assign a corresponding probe count array to the sub-file.

[0210] Step S3025: Insert test probes into the code logic branches.

[0211] In this embodiment, the code file to be tested and its corresponding index file are obtained. During the execution of the code file, for each test probe inserted into the code file, if the test probe is triggered, the target element associated with the test probe in the index file is determined and updated. At the end of the execution of the code file, the code coverage of the code file is determined based on the elements in the probe count arrays in the index file. When a test probe is triggered, the number of test probe triggers can be quickly counted using the index file. The probe count arrays not only accurately determine the code coverage of the test file but can also be used for other specific business analyses.

[0212] Based on the same technical concept, embodiments of this application provide a data comparison device, such as... Figure 31 As shown, the device 3100 includes:

[0213] The acquisition module 3101 is used to acquire the code file to be tested and the index file corresponding to the code file to be tested. The code file to be tested includes at least one sub-file. The index file includes the association relationship between the root file identifier corresponding to the code file to be tested and the sub-file identifiers corresponding to each of the at least one sub-file, and a probe count array corresponding to each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file.

[0214] The update module 3102 is used to, during the running of the code file under test, for each test probe inserted in the code file under test, if the test probe is triggered, determine the target element associated with the test probe in the index file and update the target element.

[0215] The statistics module 3103 determines the code coverage of the code file under test based on the elements in the probe count arrays in the index file when the test code file finishes running.

[0216] Optionally, the acquisition module 3101 is specifically used for:

[0217] Based on the association between the code file to be tested and the at least one sub-file, and the code logic branches contained in each of the at least one sub-file, an index file corresponding to the code file to be tested is constructed.

[0218] Optionally, the acquisition module 3101 is further configured to:

[0219] It is determined that the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, and that the sub-file identifier corresponding to each of the at least one sub-file is different from the sub-file identifier corresponding to the historical sub-file in the historical index file.

[0220] Optionally, the acquisition module 3101 is specifically used for:

[0221] If the root file identifier of the code file to be tested is the same as the root file identifier in the historical index file, then the probe count arrays in the historical index file are initialized.

[0222] The historical index file after initialization is used as the index file for the code file to be tested.

[0223] Optionally, the acquisition module 3101 is further configured to:

[0224] If the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, then the sub-file identifiers corresponding to each of the at least one sub-files are compared with the sub-file identifiers corresponding to the historical sub-files in the historical index file.

[0225] The probe count arrays corresponding to the historical subfiles that have the same subfile identifier are initialized, and the initialized probe count arrays are used as the probe count arrays corresponding to the subfiles in the code file to be tested.

[0226] Generate probe count arrays corresponding to other subfiles in the code file to be tested;

[0227] Based on the root file identifier corresponding to the code file under test, the sub-file identifiers corresponding to each of the at least one sub-file, and the probe count array, the index file of the code file under test is obtained.

[0228] Optionally, the types of code logic branches include: sequential execution logic branches, unconditional jump logic branches, conditional jump logic branches, exception handling logic branches, and return logic branches.

[0229] Optionally, the update module 3102 is specifically used for:

[0230] If the test probe is triggered, the position information of the test probe in the code file under test is obtained, wherein the position information includes the root file identifier, the target sub-file identifier, and the target logic branch;

[0231] Based on the root file identifier, the target sub-file identifier, and the target logical branch, the index file is queried to determine the target probe count array associated with the test probe in the index file, as well as the target element corresponding to the target probe count array, and the target element is incremented by a preset value.

[0232] Optionally, the statistics module 3103 is specifically used for:

[0233] The total length of each probe count array in the index file is taken as the total number of test probes;

[0234] The number of elements greater than zero in each probe count array is taken as the number of triggered probes;

[0235] The ratio of the number of triggered probes to the total number of test probes is used as the code coverage of the code file under test.

[0236] Optionally, the code file to be tested is the original code file or a copied code file.

[0237] Based on the same technical concept, embodiments of this application provide a computer device, which may be a terminal or a server, such as... Figure 32 As shown, it includes at least one processor 3201 and a memory 3202 connected to at least one processor. In this embodiment, the specific connection medium between the processor 3201 and the memory 3202 is not limited. Figure 32 Taking the connection between the processor 3201 and the memory 3202 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0238] In this embodiment of the application, the memory 3202 stores instructions that can be executed by at least one processor 3201. By executing the instructions stored in the memory 3202, at least one processor 3201 can perform the steps included in the above-described method for detecting code coverage.

[0239] The processor 3201 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It performs code coverage detection by running or executing instructions stored in the memory 3202 and accessing data stored in the memory 3202. Optionally, the processor 3201 may include one or more processing units. The processor 3201 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 3201. In some embodiments, the processor 3201 and the memory 3202 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0240] Processor 3201 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0241] Memory 3202, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 3202 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 3202 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 3202 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0242] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described code coverage detection method.

[0243] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0244] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0245] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0246] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0247] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for detecting code coverage, characterized in that, include: Obtain the code file to be tested and the index file corresponding to the code file to be tested. The code file to be tested includes at least one sub-file. The index file includes the association relationship between the root file identifier corresponding to the code file to be tested and the sub-file identifiers corresponding to each of the at least one sub-files, and a probe count array corresponding to each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file. During the execution of the code file under test, for each test probe inserted in the code file under test, if the test probe is triggered, the position information of the test probe in the code file under test is obtained, wherein the position information includes the root file identifier, the target sub-file identifier, and the target logical branch; Based on the root file identifier, the target sub-file identifier, and the target logical branch, the index file is queried to determine the target probe count array associated with the test probe in the index file, as well as the target element corresponding to the target probe count array, and the target element is incremented by a preset value. When the code file under test finishes running, the code coverage of the code file under test is determined based on the elements in the probe count arrays of the index file.

2. The method as described in claim 1, characterized in that, The step of obtaining the index file of the code file to be tested includes: Based on the association between the code file to be tested and the at least one sub-file, and the code logic branches contained in each of the at least one sub-file, an index file corresponding to the code file to be tested is constructed.

3. The method as described in claim 2, characterized in that, Before constructing the index file corresponding to the code file under test based on the association between the code file under test and the at least one sub-file, and the code logic branches contained in each of the at least one sub-file, the method further includes: It is determined that the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, and that the sub-file identifier corresponding to each of the at least one sub-file is different from the sub-file identifier corresponding to the historical sub-file in the historical index file.

4. The method as described in claim 1, characterized in that, The step of obtaining the index file of the code file to be tested includes: If the root file identifier of the code file to be tested is the same as the root file identifier in the historical index file, then the probe count arrays in the historical index file are initialized. The historical index file after initialization is used as the index file for the code file to be tested.

5. The method as described in claim 4, characterized in that, Also includes: If the root file identifier of the code file to be tested is different from the root file identifier in the historical index file, then the sub-file identifiers corresponding to each of the at least one sub-files are compared with the sub-file identifiers corresponding to the historical sub-files in the historical index file. The probe count arrays corresponding to the historical subfiles that have the same subfile identifier are initialized, and the initialized probe count arrays are used as the probe count arrays corresponding to the subfiles in the code file to be tested. Generate probe count arrays corresponding to other subfiles in the code file to be tested; Based on the root file identifier corresponding to the code file under test, the sub-file identifiers corresponding to each of the at least one sub-file, and the probe count array, the index file of the code file under test is obtained.

6. The method as described in claim 1, characterized in that, The types of code logic branches include: sequential execution logic branches, unconditional jump logic branches, conditional jump logic branches, exception handling logic branches, and return logic branches.

7. The method according to any one of claims 1 to 6, characterized in that, The step of determining the code coverage of the code file to be tested based on the elements in each probe count array of the index file includes: The total length of each probe count array in the index file is taken as the total number of test probes; The number of elements greater than zero in each probe count array is taken as the number of triggered probes; The ratio of the number of triggered probes to the total number of test probes is used as the code coverage of the code file under test.

8. The method as described in claim 7, characterized in that, The code file to be tested is the original code file or a copied code file.

9. A device for detecting code coverage, characterized in that, include: The acquisition module is used to acquire the code file to be tested and the index file corresponding to the code file to be tested. The code file to be tested includes at least one sub-file. The index file includes the association relationship between the root file identifier corresponding to the code file to be tested and the sub-file identifiers corresponding to each of the at least one sub-file, and a probe count array corresponding to each sub-file. Each element in the probe count array is associated with a test probe corresponding to a code logic branch contained in the corresponding sub-file. The update module is used to, during the execution of the code file under test, for each test probe inserted in the code file under test, if the test probe is triggered, obtain the position information of the test probe in the code file under test, wherein the position information includes the root file identifier, the target sub-file identifier, and the target logical branch; based on the root file identifier, the target sub-file identifier, and the target logical branch, query the index file to determine the target probe count array associated with the test probe in the index file, and the corresponding target element in the target probe count array, and increment the target element by a preset value; The statistics module determines the code coverage of the code file under test based on the elements in the probe count arrays in the index file when the test code file finishes running.

Images