Code coverage test processing method and device, equipment and storage medium

Abstract

The application provides a code coverage test processing method and device, electronic equipment, computer readable storage medium and computer program product. The method comprises the following steps: obtaining multiple code coverage data files, wherein each code coverage data file comprises a data file generated based on a use case test code and a symbol file generated by compiling the code; matching the multiple code coverage data files according to file names to obtain multiple data sets, wherein each data set comprises a corresponding data file and a symbol file; processing the multiple data sets in parallel based on multiple processes included in a process pool for running the code to obtain a code coverage information sub-file corresponding to each data set; and merging the multiple code coverage information sub-files into a code coverage information file based on a task identifier, and storing the multiple code coverage information files in the form of key-value pairs. Through the application, the test efficiency of the code coverage can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for testing code coverage. Background Technology

[0002] During software development, developers need to test the developed code. This testing process typically involves calculating code coverage. Code coverage is a metric in software testing that describes the proportion and extent to which the source code of a program is tested. The resulting proportion is called code coverage. Code coverage is an important indicator reflecting the degree to which test cases cover the software under test and serves as a reference value for measuring test completeness. Code coverage data can be used to assess the adequacy of testing and determine whether software tests need to be repeated.

[0003] However, the code coverage testing methods provided by related technologies usually involve first obtaining all Gcda and Gcno files in the current directory, then processing the obtained Gcda and Gcno files into intermediate Gcov files, and finally traversing all intermediate Gcov files to generate an Info file. Moreover, the above calculation process is executed in a single thread and leaves many useless intermediate files, resulting in low code coverage testing efficiency, which in turn greatly reduces the work efficiency of developers / testers. Summary of the Invention

[0004] This application provides a code coverage testing method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can effectively improve the testing efficiency of code coverage.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a code coverage testing method, including: Obtain multiple code coverage data files, wherein each code coverage data file includes: a data file generated when testing the code based on test cases and a symbol file generated by compiling the code; The multiple code coverage data files are matched according to their filenames to obtain multiple datasets, wherein each dataset includes a corresponding data file and a symbol file; Based on the process pool, which includes multiple processes for running the code, the multiple datasets are processed in parallel to obtain a code coverage information sub-file corresponding to each dataset; Based on the task identifier, multiple code coverage information sub-files are merged into a single code coverage information file, and these multiple code coverage information files are stored in key-value pair format.

[0006] This application provides a code coverage testing processing apparatus, including: The acquisition module is used to acquire multiple code coverage data files, wherein each code coverage data file includes: a data file generated when testing the test code based on test cases and a symbol file generated by compiling the code; The matching module is used to match the multiple code coverage data files according to the file name to obtain multiple datasets, wherein each dataset includes a corresponding data file and a symbol file; The processing module is used to process the multiple datasets in parallel based on the multiple processes included in the process pool for running the code, and to obtain a code coverage information sub-file corresponding to each dataset; The merging module is used to merge multiple code coverage information sub-files into a single code coverage information file based on the task identifier. The storage module is used to store multiple copies of the code coverage information file in the form of key-value pairs.

[0007] In the above scheme, the storage module is further configured to store the multiple datasets into a processing queue; the processing module is further configured to obtain multiple datasets of the same number as the multiple processes from the processing queue, and distribute the multiple datasets to the multiple processes respectively, with each process processing one of the distributed datasets; when any of the multiple processes finishes processing, the remaining dataset is obtained from the processing queue, and the remaining dataset is processed by the process, until all datasets stored in the processing queue have been processed.

[0008] In the above scheme, the processing module is further configured to perform the following processing through each process: obtain the parameters carried by the dataset, wherein the parameters include an input path, an output path, and format parameters; obtain the data files and symbol files included in the dataset according to the input path; process the data files and symbol files included in the dataset based on the format parameters to obtain a code coverage information sub-file that meets the format requirements; and store the code coverage information sub-file that meets the format requirements in the database at the location corresponding to the output path.

[0009] In the above scheme, the processing module is further configured to obtain code coverage information from the data files and symbol files included in the dataset, wherein the code coverage information is characterized based on basic blocks and arcs; perform format conversion on the code coverage information according to the format parameters; and generate a code coverage information sub-file that meets the format requirements based on the format-converted code coverage information.

[0010] In the above scheme, the processing module is further configured to: obtain program flow graph information from the symbol files included in the dataset; establish a program flow graph for each function in the code based on the program flow graph information; obtain the known execution counts of arcs from the data files included in the dataset and write the known execution counts of arcs into the program flow graph; determine the execution counts of other arcs and basic blocks based on the program flow graph and the known execution counts of arcs; and determine the code coverage information corresponding to the code based on the execution counts of all arcs and basic blocks, wherein the code coverage information includes at least one of the following: function information and line number information.

[0011] In the above scheme, the processing module is further configured to perform the following processing for each of the multiple code coverage information sub-files corresponding to the use case: obtain the task identifier corresponding to the use case; use the task identifier as the prefix of the multiple code coverage information sub-files; wherein, the task identifiers corresponding to different use cases are different.

[0012] In the above scheme, the processing module is further configured to perform the following processing for each code coverage information sub-file: setting a first suffix and a second suffix for the code coverage information sub-file, wherein the first suffix is ​​used to identify all the code lines corresponding to the code coverage information sub-file, and the second suffix is ​​used to identify the executed code lines among all the code lines corresponding to the code coverage information sub-file.

[0013] In the above scheme, the device further includes a creation module for creating the process pool; the device further includes a determination module for determining the number of processes included in the process pool based on the number of datasets to be processed and the performance conditions for running the process pool.

[0014] In the above scheme, the creation module is further configured to create a connection pool, wherein the connection pool includes multiple connections; the processing module is further configured to, when receiving multiple write requests corresponding to multiple code coverage information files respectively, process the multiple write requests in parallel based on the multiple connections included in the connection pool, so as to store the multiple code coverage information files into the database.

[0015] In the above scheme, the storage module is further configured to perform the following processing for each task identifier: storing the task identifier as the key and the code coverage information file corresponding to the task identifier as the value.

[0016] In the above scheme, the code is the updated code; the device further includes a comparison module, used to compare the code coverage information file corresponding to the updated code with the code coverage information file corresponding to the unupdated code to obtain an incremental code coverage information file; the device further includes a generation module, used to generate a code coverage report based on the incremental code coverage information file; the determination module is further used to determine the code coverage test result corresponding to the updated code based on the code coverage report.

[0017] This application provides an electronic device, including: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the code coverage testing method provided in the embodiments of this application.

[0018] This application provides a computer-readable storage medium storing executable instructions for implementing the code coverage testing method provided in this application when executed by a processor.

[0019] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the code coverage testing method provided in this application.

[0020] The embodiments of this application have the following beneficial effects: First, multiple code coverage data files to be processed are matched according to their filenames to obtain multiple datasets. Then, multiple processes in a process pool are used to process multiple datasets in parallel to obtain a code coverage information sub-file for each dataset. Subsequently, the multiple code coverage information sub-files are merged based on task identifiers. Finally, the merged multiple code coverage information files are stored in key-value pairs. In this way, the datasets to be processed are parallelized, which greatly improves the testing efficiency of code coverage. Furthermore, the multiple code coverage information files are stored in key-value pairs, which reduces subsequent search time and thus greatly improves the work efficiency of developers and testers. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the architecture of the code coverage test processing system 100 provided in this application embodiment; Figure 2This is a schematic diagram of the structure of the server 200 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the code coverage testing method provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the code coverage testing method provided in the embodiments of this application; Figure 5 This is a flowchart illustrating the code coverage testing method provided in the embodiments of this application; Figure 6 This is a flowchart illustrating the code coverage testing methods provided by related technologies; Figure 7 This is a schematic diagram of the processing flow of a single Gcov4 provided in an embodiment of this application; Figure 8 This is a schematic diagram of the output of the Info file provided in the embodiments of this application; Figure 9 This is a flowchart illustrating the concurrent processing of multiple Gcov4 processes provided in an embodiment of this application; Figure 10 This is a schematic diagram of the Redis key-value design provided in the embodiments of this application; Figure 11 This is a schematic diagram of the Redis connection pool provided in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0024] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0026] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0027] 1) Code coverage: A metric in software testing that describes the proportion and extent to which source code in a program is tested. The resulting proportion is called code coverage. The significance of code coverage lies in analyzing uncovered code, thereby inferring whether the initial code design was adequate. It can also detect useless code, identify areas of confusion in code design, and remind developers to pay attention to related logical relationships, thus improving code quality. Therefore, code coverage testing is a valuable tool for developers and testers to identify problems early and ensure code quality.

[0028] 2) Data file: also known as Gcda file. When a compiled program is run, a Gcda file is generated. It contains the specific number of times each piece of code is executed, such as the number of jumps.

[0029] 3) Symbol file: also known as Gcno file. Gcno file is generated during code compilation. It contains the mapping relationship between code counter and source code, such as information on the line numbers of the source code of the reconstructed basic block diagram and the corresponding blocks.

[0030] 4) Basic Block (BB): This refers to a sequence of statements executed sequentially in a program. For example, if the first statement of a program is executed once, every statement in that program must be executed once. In other words, all statements within a BB must be executed the same number of times. It typically consists of multiple sequentially executed statements followed by a jump statement. Therefore, the last statement of a BB is usually a jump statement, with the jump destination being the first statement of another BB. If the jump is conditional, a branch is created, and the BB will have two BBs as destinations.

[0031] 5) Arc (ARC): A jump from one BB to another is called an ARC. Therefore, if you want to know the number of times each statement and branch in the program is executed, you must know the number of times each BB and ARC is executed.

[0032] 6) Program Flow Graph: Also known as a program flowchart or program block diagram, it is a graphical representation of the specific steps of program execution using standardized symbols. For example, if we consider BB as a node, then all BBs in such a function constitute a directed graph. To know the number of times each statement and branch in the program is executed, we must know the number of times each BB and ARC are executed. According to graph theory, the in-degree and out-degree of BBs in a directed graph are the same; therefore, if we know the size of some BBs or ARCs, we can deduce the size of all BBs and ARCs.

[0033] 7) Process pool: This is an application of technology consisting of resource processes and management processes. The management process is responsible for creating resource processes, assigning work to idle resource processes for processing, and reclaiming resource processes that have finished processing. Resource processes are pre-created idle processes, and the management process will distribute work to idle processes for processing.

[0034] 8) Connection Pool: This is a technique for creating and managing a buffer pool of connections, ready to be used by any thread that needs them. The main operations of a database connection pool are as follows: Establish the database connection pool (server startup); create an initial number of database connections (i.e., the number of idle connections) according to pre-specified parameters; for a database access request, obtain a connection directly from the connection pool. If there are no idle connections in the database connection pool and the number of connections has not reached the maximum number of active connections, a new database connection can be created; access the database; close the database and release all database connections (this closing of the database connection does not mean truly closing it, but rather placing it in the idle queue; for example, when the actual number of idle connections is greater than the initial number of idle connections, the connection is released); release the database connection pool (i.e., during server shutdown or maintenance, release the database connection pool and release all connections).

[0035] 9) Test Case: Also known as a test case, it describes a test task for a specific software product, reflecting the test plan, methods, techniques, and strategies. Its content includes test objectives, test environment, input data, test steps, expected results, test scripts, etc., ultimately forming a document. In other words, a test case is a set of test inputs, execution conditions, and expected results compiled for a specific goal to verify whether a particular software requirement is met.

[0036] This application provides a code coverage testing method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can effectively improve the testing efficiency of code coverage. The following describes exemplary applications of the electronic device provided in this application. The electronic device provided in this application can be implemented as various types of terminal devices such as laptops, tablets, desktop computers, set-top boxes, mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), and in-vehicle terminals. It can also be implemented as a server, or implemented in coordination between terminal devices and a server.

[0037] The following description uses an example of a code coverage testing method provided in this application, implemented collaboratively by a terminal device and a server. For an example, see [link to example]. Figure 1 , Figure 1 This is a schematic diagram of the architecture of the code coverage test processing system 100 provided in the embodiments of this application. In order to support an application that effectively improves the testing efficiency of code coverage, the terminal device 400 connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0038] like Figure 1As shown, server 200 first retrieves multiple code coverage data files from database 500. Each code coverage data file includes: a data file generated when testing code based on test cases (i.e., the code to be tested, such as the source code of an updated application) and a symbol file generated by compiling the code (for example, in a test, testers / developers can write multiple test cases for the code to be tested at once, test the code based on the written test cases, thereby obtaining multiple code coverage data files, and storing the obtained multiple code coverage data files in database 500). Next, server 200 matches the retrieved multiple code coverage data files according to the file name to obtain multiple datasets, where each dataset includes a corresponding data file and a symbol file. Subsequently, server 200 creates a process pool and, based on the multiple processes included in the process pool for running code, processes multiple datasets in parallel to obtain a code coverage information sub-file corresponding to each dataset. Finally, server 200 can, based on task identifiers (each test case corresponds to a unique task identifier),... The server merges multiple code coverage information subfiles into a single code coverage information file, storing the merged files as key-value pairs (i.e., using the task identifier as the key and the corresponding code coverage information file as the value). When testers / developers need to view the code coverage information file for a specific test case, they can send a request to the server 200 via the terminal device 400, carrying the task identifier for the test case. Upon receiving the request from the terminal device 400 via the network 300, the server 200 extracts the task identifier and searches for the corresponding code coverage information file. The server then returns the obtained code coverage information file to the terminal device 400. After receiving the returned code coverage information file from the server 200, the terminal device 400 can perform format conversion processing, such as converting the returned code coverage information file into Hypertext Markup Language (HTML). The code is presented in Text Markup Language (TML) format and displayed through the client's 410 human-computer interaction interface. This allows testers and developers to intuitively obtain code coverage information for the code under test through visualization.

[0039] In other embodiments, the code coverage testing method provided in the embodiments of this application can also be implemented independently by the terminal device, for example, using... Figure 1Taking the terminal device 400 shown as an example, the terminal device 400 first obtains multiple code coverage data files from the database 500. Then, it matches the multiple code coverage data files according to the file names to obtain multiple datasets. Subsequently, the terminal device 400 can create a process pool and, based on the multiple processes included in the process pool for running code, process the multiple datasets in parallel to obtain a code coverage information sub-file corresponding to each dataset. Finally, the terminal device 400 can merge the multiple code coverage information sub-files into a code coverage information file based on the task identifier and store the merged multiple code coverage information files in the form of key-value pairs. In this way, by using multiple processes included in the process pool to process multiple datasets in parallel, the testing efficiency of code coverage is greatly improved.

[0040] In some embodiments, the present application embodiments can also be implemented with the aid of cloud technology, which refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize the computation, storage, processing, and sharing of data.

[0041] Cloud technology is a general term encompassing network technology, information technology, integration technology, management platform technology, and application technology based on the cloud computing business model. It can form resource pools, allowing for on-demand use with flexibility and convenience. Cloud computing technology will become a crucial support. The backend services of cloud computing systems require substantial computing and storage resources.

[0042] Example, Figure 1 The server 200 shown 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, CDN, and big data and artificial intelligence platforms. The terminal device 400 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal device 400 and the server 200 can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0043] In other embodiments, the code coverage testing method provided in this application can also be implemented in conjunction with blockchain technology, for example... Figure 1The terminal device 400 and server 200 shown can join the blockchain network and become nodes within it. Different nodes in the blockchain network can have information connections, and nodes can also transmit information through these information connections. For example, data related to the code coverage test processing method provided in this application embodiment (such as multiple code coverage data files obtained based on multiple test cases, and multiple code coverage information files obtained after merging based on task identifiers) can be stored in the blockchain network, thereby ensuring the traceability and security of the data.

[0044] In some embodiments, the terminal device or server may also implement the code coverage testing method provided in this application by running a computer program. For example, the computer program may be a native program in the operating system (e.g., a dedicated code coverage testing program) or a software module, such as a code coverage testing module that can be embedded in any program; it may also be a native application (APP), i.e., a program that needs to be installed in the operating system to run, such as... Figure 1 The client 410 is shown in the figure. In summary, the above-described computer program can be any form of application, module, or plug-in.

[0045] The following continues... Figure 1 The structure of server 200 shown in the diagram will be explained. See also... Figure 2 , Figure 2 This is a schematic diagram of the structure of the server 200 provided in the embodiments of this application. Figure 2 The server 200 shown includes at least one processor 210, memory 240, and at least one network interface 220. The various components of server 200 are coupled together via a bus system 230. Understandably, the bus system 230 is used to implement communication between these components. In addition to a data bus, the bus system 230 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 230.

[0046] Processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0047] The memory 240 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 240 may optionally include one or more storage devices physically located away from the processor 210.

[0048] The memory 240 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 240 described in this application embodiment is intended to include any suitable type of memory.

[0049] In some embodiments, memory 240 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0050] Operating system 241 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 242 is used to reach other computing devices via one or more (wired or wireless) network interfaces 220, such as Bluetooth, WiFi, and Universal Serial Bus (USB). In some embodiments, the AI-based text processing apparatus provided in this application can be implemented in software. Figure 2 An AI-based text processing device 243, stored in memory 240, is shown. This device can be software in the form of programs and plugins, and includes the following software modules: an acquisition module 2431, a matching module 2432, a processing module 2433, a merging module 2434, a storage module 2435, a creation module 2436, a determination module 2437, a comparison module 2438, and a generation module 2439. These modules are logically connected and can therefore be arbitrarily combined or further split according to the functions implemented. It should be noted that... Figure 2 For ease of explanation, all the above modules are shown at once, but this should not be considered as an exclusion of the implementation of the code coverage test processing device 243, which may only include the acquisition module 2431, matching module 2432, processing module 2433, merging module 2434 and storage module 2435. The functions of each module will be described below.

[0051] In other embodiments, the code coverage testing processing device provided in this application can be implemented in hardware. As an example, the code coverage testing processing device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the code coverage testing processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0052] The following will describe the code coverage testing method provided in this application embodiment, using exemplary applications and implementations of the server provided in the embodiments of this application. For example, see [link to example]. Figure 3 , Figure 3 This is a flowchart illustrating the code coverage testing method provided in this application embodiment, which will be combined with... Figure 3 The steps shown are explained.

[0053] In step 101, multiple code coverage data files are obtained.

[0054] Here, each code coverage data file includes: a data file generated when testing the code based on test cases (i.e., a Gcda file) and a symbol file generated when compiling the code (i.e., a Gcno file).

[0055] In some embodiments, when code coverage testing of the source code of an application is required, in order to test the source code of the application completely and comprehensively, testers / developers can write multiple test cases for the application at one time, and perform code coverage testing on the application based on the multiple test cases they have written, thereby obtaining multiple code coverage data files, wherein each code coverage data file includes a Gcda file and a Gcno file.

[0056] For example, taking the source code of application A as the code to be tested, assuming the tester has written 10 test cases for application A, a code coverage testing tool (such as Gcov, Lcov, etc.) can be used to call these 10 test cases to perform code coverage testing on the source code of application A, resulting in 10 code coverage data files. Each code coverage data file includes a corresponding Gcda file and a Gcon file. For example, taking Gcov as the code coverage testing tool, the Gcno file can be generated by the -ftest-coverage command, which contains information about reconstructing the basic block diagram and the line numbers of the corresponding blocks in the source code. The Gcda file can be generated by running a compiled file with the -fprofile-arcs compilation parameter, which contains the number of arc transitions and other summary information.

[0057] In step 102, multiple code coverage data files are matched according to their filenames to obtain multiple datasets.

[0058] Here, each dataset includes a corresponding data file (i.e., the Gcda file) and a symbol file (i.e., the Gcno file).

[0059] In some embodiments, after obtaining multiple code coverage data files, the multiple code coverage data files can be matched according to their filenames to obtain multiple datasets. That is, data files and symbol files with the same filenames included in the multiple code coverage data files can be merged into the same dataset. In other words, the data files and symbol files included in the same dataset have the same filenames, that is, they are data files and symbol files generated for the same use case.

[0060] In other embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating the code coverage testing method provided in this application embodiment, as shown below. Figure 4 As shown, after execution Figure 3 After step 102 shown, you can also execute... Figure 4 The illustrated step 106 will combine Figure 4 The steps shown are explained.

[0061] In step 106, multiple datasets are stored in a queue to be processed.

[0062] Here, a processing queue can be created in advance, and multiple datasets obtained in step 102 can be stored in the processing queue. After the process pool is created, the multiple datasets stored in the processing queue can be distributed to multiple processes in the process pool, thereby processing multiple datasets concurrently.

[0063] See also Figure 3 In step 103, based on the multiple processes included in the process pool for running code, multiple datasets are processed in parallel to obtain a code coverage information subfile corresponding to each dataset.

[0064] In some embodiments, during execution Figure 3 Before step 103 shown, the following processes may also be performed: creating a process pool; determining the number of processes included in the process pool based on the number of datasets to be processed and the performance conditions for running the process pool.

[0065] For example, to improve the efficiency of code coverage testing, the server can pre-create a process pool to concurrently process multiple datasets based on the multiple processes included in the pool. The number of processes in the pool can be determined by a combination of the number of datasets to be processed and the server's performance. For instance, when there are many datasets to be processed and the server's performance is good, more processes can be created and placed in the pool to speed up the processing efficiency. Conversely, when there are few datasets to be processed or the server's performance is poor, fewer processes can be created to avoid wasting server system resources or negatively impacting server efficiency due to an excessive number of processes.

[0066] It should be noted that when the code coverage test processing method provided in this application embodiment is executed through a terminal device, the number of processes included in the process pool can be determined according to the number of datasets to be processed and the performance conditions of the terminal device. In this way, the testing efficiency of code coverage can be accelerated without wasting the system resources of the terminal device, thereby achieving the best concurrency effect.

[0067] In other embodiments, Figure 3 Step 103 shown can also be achieved through Figure 4 The implementation of steps 1031 and 1032 shown will be combined with Figure 4 The steps shown are explained.

[0068] In step 1031, multiple datasets of the same number as multiple processes are obtained from the queue to be processed, and the multiple datasets are distributed to the multiple processes respectively, with each process processing one of the distributed datasets.

[0069] In some embodiments, after creating the process pool, multiple datasets of the same number as the multiple processes included in the process pool can be obtained from the pending queue created in step 106 (the pending queue contains multiple datasets obtained in step 102), and the multiple datasets can be distributed to the multiple processes respectively, so that each process can process one of the distributed datasets.

[0070] For example, assuming the pool contains 5 processes, namely processes 1 to 5, we can first read 5 datasets from the processing queue, namely dataset 1 to dataset 5, and then distribute these 5 datasets to the 5 processes respectively, so that each process can process one of the distributed datasets. For example, dataset 1 is distributed to process 1, and processed by process 1; dataset 2 is distributed to process 2, and processed by process 2; dataset 3 is distributed to process 3, and processed by process 3; dataset 4 is distributed to process 4, and processed by process 4; and dataset 5 is distributed to process 5, and processed by process 5. In this way, by using multiple processes in the process pool to process in parallel, the processing efficiency of the datasets can be greatly improved, thereby improving the testing efficiency of code coverage.

[0071] In some embodiments, the above-mentioned processing of a distributed dataset by each process can be achieved by the following: each process performs the following processing: obtaining the parameters carried by the dataset, wherein the parameters include the input path, the output path, and the format parameters; obtaining the data files and symbol files included in the dataset according to the input path; processing the data files and symbol files included in the dataset based on the format parameters to obtain a code coverage information sub-file that meets the format requirements; and storing the code coverage information sub-file that meets the format requirements in the database at the location corresponding to the output path.

[0072] For example, the above-mentioned processing of the data files and symbol files included in the dataset based on format parameters to obtain a code coverage information sub-file that meets the format requirements can be achieved in the following way: Obtain code coverage information from the data files and symbol files included in the dataset, where the code coverage information is represented based on basic blocks and arcs; perform format conversion on the code coverage information according to the format parameters; and generate a code coverage information sub-file that meets the format requirements based on the format-converted code coverage information. Thus, by adding format parameters to the parameters, it can be ensured that the final generated code coverage information sub-file meets the format requirements expected by testers / developers.

[0073] In some embodiments, the above-mentioned acquisition of code coverage information from the data files and symbol files included in the dataset can also be achieved by: acquiring program flow graph information from the symbol files included in the dataset, and establishing a program flow graph for each function in the code based on the program flow graph information; acquiring the known execution counts of arcs from the data files included in the dataset, and writing the known execution counts of arcs into the program flow graph; determining the execution counts of other arcs and basic blocks based on the program flow graph and the known execution counts of arcs; and determining the code coverage information corresponding to the code based on the execution counts of all arcs and basic blocks, wherein the code coverage information includes at least one of the following: function information and line number information.

[0074] In step 1032, when any one of the multiple processes finishes processing, the remaining dataset is retrieved from the processing queue and processed by any one of the processes until all datasets stored in the processing queue have been processed.

[0075] In some embodiments, when any one of the multiple processes included in the process pool has finished processing the distributed dataset, it can continue to retrieve the remaining dataset from the processing queue and distribute the retrieved remaining dataset to any process that has finished processing, so that the retrieved remaining dataset can be processed by any process until all datasets stored in the processing queue have been processed.

[0076] For example, suppose the processing queue contains 10 datasets, numbered 1 to 10, and the process pool contains 4 processes, numbered 1 to 4. First, 4 datasets (1 to 4) are read from the processing queue and distributed to the 4 processes in the pool for parallel processing. When any of the 4 processes finishes processing its assigned dataset—for example, if process 3 finishes processing its assigned dataset first—it can retrieve dataset 5 from the processing queue and distribute it to process 3 for processing. Then, if process 4 finishes processing its assigned dataset 4, it can retrieve dataset 6 from the processing queue and distribute it to process 4 for processing. This process continues until all 10 datasets in the processing queue have been processed, resulting in code coverage information subfiles corresponding to each of the 10 datasets.

[0077] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating the code coverage testing method provided in this application embodiment, as shown below. Figure 5 As shown, after execution Figure 3 After step 103 shown, you can also execute... Figure 5Steps 107 and 108 shown will be combined Figure 5 The steps shown are explained.

[0078] In step 107, for each use case, the following processing is performed on the multiple code coverage information sub-files: obtain the task identifier corresponding to the use case; use the task identifier as the prefix of the multiple code coverage information sub-files.

[0079] Here, different use cases correspond to different task identifiers.

[0080] In some embodiments, after obtaining the code coverage information sub-files corresponding to each dataset, the following processing can be performed on the multiple code coverage information sub-files corresponding to each use case: obtain the unique task identifier corresponding to the use case, and use the obtained task identifier as the prefix of the file name of the multiple code coverage information sub-files. In this way, the multiple code coverage information sub-files corresponding to the same use case can be merged based on the task identifier to obtain a merged code coverage information file corresponding to the use case.

[0081] For example, taking use case A as an example, first obtain the task identifier A corresponding to use case A. Then, for the multiple code coverage information sub-files corresponding to use case A, let's say code coverage information sub-files 1 to 4, use the task identifier A as the prefix for the filenames of code coverage information sub-files 1 to 4. That is, code coverage information sub-files 1 to 4 have the same prefix, which is task identifier A. In this way, code coverage information sub-files 1 to 4 can be merged into a single code coverage information file (i.e., a single code coverage information file corresponding to use case A) based on task identifier A.

[0082] In step 108, for each code coverage information subfile, the following processing is performed: a first suffix and a second suffix are set for the code coverage information subfile.

[0083] Here, the first suffix is ​​used to identify all the lines of code corresponding to the code coverage information subfile, and the second suffix is ​​used to identify the lines of code that were executed in all the lines of code corresponding to the code coverage information subfile.

[0084] In some embodiments, after obtaining the code coverage information subfile corresponding to each dataset, the following processing can be performed on each code coverage information subfile: set a first suffix (e.g., the suffix Total, used to identify all the code lines corresponding to the code coverage information subfile) and a second suffix (e.g., the suffix Cov, used to identify the executed code lines among all the code lines corresponding to the code coverage information subfile) to the filename of the code coverage information subfile. In this way, all the code lines corresponding to each code coverage information subfile, as well as the executed code lines among all the code lines, can be conveniently determined through the first suffix and the second suffix.

[0085] See also Figure 3 In step 104, multiple code coverage information sub-files are merged into a single code coverage information file based on the task identifier.

[0086] In some embodiments, after setting a corresponding prefix for the filename of each code coverage information sub-file based on step 107, multiple code coverage information sub-files can be merged into a single code coverage information file based on the set prefix (i.e., task identifier). That is, multiple code coverage information sub-files with the same task identifier can be merged into one code coverage information file. For example, assuming that the prefix of code coverage information sub-files 1 to 4 is task identifier A, the prefix of code coverage information sub-files 5 to 7 is task identifier B, and the prefix of code coverage information sub-files 8 to 10 is task identifier C, then... By merging code coverage information subfiles 1 to 4 into one code coverage information file (corresponding to use case A), code coverage information subfiles 5 to 7 into one code coverage information file (corresponding to use case B), and code coverage information subfiles 8 to 10 into one code coverage information file (corresponding to use case C), multiple code coverage information subfiles corresponding to the same use case can be merged into one code coverage information file based on the task identifier, facilitating subsequent processing.

[0087] In step 105, multiple code coverage information files are stored in key-value pairs.

[0088] In some embodiments, the above-mentioned storage of multiple code coverage information files in key-value pairs can be achieved by performing the following process for each task identifier: storing the task identifier as the key and the code coverage information file corresponding to the task identifier as the value.

[0089] For example, after obtaining multiple code coverage information files, these files can be stored as key-value pairs. For instance, assuming four code coverage information files are obtained in step 104, namely code coverage information file 1 corresponding to task identifier A, code coverage information file 2 corresponding to task identifier B, code coverage information file 3 corresponding to task identifier C, and code coverage information file 4 corresponding to task identifier D, then task identifiers A to D can be used as keys, and the corresponding code coverage information files can be stored as values. This key-value pair storage reduces the time required for subsequent searches.

[0090] In some embodiments, to avoid the performance overhead caused by the creation and destruction of multiple connections, the following process can also be performed: creating a connection pool (also known as a database connection pool), wherein the connection pool includes multiple connections (also known as database connections); when multiple write requests corresponding to multiple code coverage information files are received, multiple write requests are processed in parallel based on the multiple connections included in the connection pool, so as to store multiple code coverage information files into the database.

[0091] For example, during initialization, a database connection pool can create a certain number of database connections and place them in the pool. The number of these database connections can be set by the minimum number of database connections. Regardless of whether these database connections are used, the connection pool will always ensure that it has at least this number of connections. The maximum number of database connections in the connection pool limits the maximum number of connections that the connection pool can hold. When the number of connections requested from the connection pool exceeds the maximum number of connections, these requests will be added to the waiting queue. The settings for the minimum and maximum number of connections in a database connection pool need to consider the following factors: 1. Minimum number of connections: This is the number of database connections the pool maintains. If the usage of database connections is not high, a significant amount of database connection resources will be wasted. 2. Maximum number of connections: This is the maximum number of connections the pool can request. If the number of database connection requests exceeds this limit, subsequent requests will be added to a waiting queue, affecting future database operations. 3. If the minimum and maximum number of connections differ significantly, the first connection request will benefit. Subsequent requests exceeding the minimum number of connections are equivalent to establishing a new database connection. However, these connections exceeding the minimum number will not be released immediately after use; they will be placed in the connection pool for reuse or released after the connection pool timeout. By creating a connection pool, the system resource consumption caused by creating and destroying multiple connections is avoided, further improving the efficiency of code coverage testing.

[0092] In other embodiments, when the code being tested is the updated code, the following processes may also be performed: comparing the code coverage information file corresponding to the updated code with the code coverage information file corresponding to the original code to obtain an incremental code coverage information file; generating a code coverage report based on the incremental code coverage information file; and determining the code coverage test result corresponding to the updated code based on the code coverage report.

[0093] For example, taking the source code of application A as the code to be tested, after updating application A, the code coverage information file corresponding to the updated source code of application A and the code coverage information file corresponding to the source code of application A before the update can be obtained by the code coverage test processing method provided in this application embodiment. Then, the code coverage information file corresponding to the updated source code of application A is compared with the code coverage information file corresponding to the source code of application A before the update to obtain the incremental code coverage information file. Subsequently, a corresponding code coverage report can be generated based on the incremental code coverage information file. Finally, the code coverage test result corresponding to the updated source code of application A is determined based on the generated code coverage report.

[0094] The code coverage testing method provided in this application first matches multiple code coverage data files to be processed based on filenames to obtain multiple datasets. Then, multiple datasets are processed in parallel based on multiple processes included in a process pool to obtain a code coverage information sub-file corresponding to each dataset. Subsequently, the multiple code coverage information sub-files are merged based on task identifiers. Finally, the merged multiple code coverage information files are stored in the form of key-value pairs. In this way, the datasets to be processed are parallelized, which greatly improves the testing efficiency of code coverage. Furthermore, the multiple code coverage information files are finally stored in the form of key-value pairs, which reduces subsequent search time and thus greatly improves the work efficiency of developers / testers.

[0095] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0096] In related technologies, code coverage testing tools (such as Lcov, a front-end graphical display tool for GCC code coverage testing, which collects code coverage information such as lines, functions, and branches from multiple source files, i.e., collects Gcda and Gcno files generated after program execution, and generates HTML pages based on the collected information) are typically used to process Gcda and Gcno files to generate readable Info format code coverage information files. (Lcov's geninfo script converts Gcda and Gcno files into Info format files. The Info file contains code coverage information corresponding to one or more source files, with one record corresponding to each source file. The record includes the source file name with full path, the covered lines, and the number of executions, etc.) However, this method is too slow to calculate code coverage and cannot meet the needs of testing.

[0097] For example, see Figure 6 , Figure 6 This is a flowchart illustrating the code coverage testing methods provided by related technologies, such as... Figure 6 As shown, the technical solution provided by the related technology is to directly generate code coverage information files using Lcov. The specific processing flow of Lcov is as follows: First, all Gcda and Gcno files in the current directory are obtained. Then, Gcov (a program tool for testing code coverage; when used correctly in conjunction with GCC, it can analyze and help users write more efficient code, and also help users optimize programs. It can collect some basic performance statistics, such as the frequency of execution of each line of code, the number of lines actually executed in each code file, and the execution time of each code block, etc.) is used to process the obtained Gcda and Gcno files to generate intermediate Gcov files. Then, all intermediate Gcov files are traversed to generate Info format files. Finally, HTML format files are generated as needed for display on the front end.

[0098] However, the applicant discovered that in the solutions provided by the relevant technologies, the intermediate calculation process is not only single-threaded, but also leaves many useless intermediate files on the disk. For example, when using Gcov to process Gcda and Gcno files, it can be executed in parallel, and the generated Gcov file does not need to be written to the disk. In addition, when processing Gcov files to generate a single Info file, it can also be executed in parallel, and the generated Info file does not need to be written to the disk. Furthermore, in the solutions provided by the relevant technologies, the code coverage data display files are not all necessary.

[0099] In other words, the main problem with the solutions provided by the relevant technologies is that the calculation speed of code coverage data is too slow. For example, for 500+ code coverage data files, the solutions provided by the relevant technologies usually require about five minutes of calculation time. This calculation speed will affect the subsequent processes of merging, displaying and providing feedback on code coverage results, which is not conducive to code coverage testing and also results in a poor user experience for testers.

[0100] In addition, the applicant also found that the main reason why the related technology is slow in calculating code coverage data is that the solution provided by the related technology has very frequent input and output (IO) operations on files and serially traverses all code coverage data files. Furthermore, the speed of Lcov in processing intermediate files is not satisfactory, which makes the entire calculation process very slow.

[0101] In view of this, this application provides a code coverage testing method. By extracting the Gcov tool from the Lcov tool's source code and directly modifying the Gcov tool's source code, the intermediate processing of Lcov is discarded. Furthermore, all code coverage data files are processed in parallel. Simultaneously, each file is stored as key-value pairs in a database (e.g., Redis, an open-source, ANSI C-written, BSD-licensed, network-enabled, in-memory or persistent log-structured key-value database that provides APIs for multiple languages; it is often called a data structure server because values ​​can be strings, hashes, lists, sets, and sorted sets). The prefix of the key can identify a single task (e.g., testers can write multiple test cases at once, each corresponding to a task), facilitating task-level code coverage diffing and merging operations. The Diff operation refers to the fact that the code coverage generated from the Gcda and Gcno files contains all the information of a single file. However, testers often only want to focus on the code lines modified by developers, so a Diff operation is needed. Therefore, the time complexity of performing a difference Diff operation in Redis is O(1), which is more advantageous than operating directly at the file level. Similarly, the merge operation is also advantageous. For example, for thousands of code coverage data files, the code coverage test processing method provided in this application greatly improves the processing speed after parallelization, and can finally complete the calculation of code coverage data in seconds. According to the barrel effect, the code coverage calculation time is affected by the longest code coverage data file among these code coverage data files.

[0102] The code coverage testing method provided in this application can be used in various calculation scenarios that utilize Gcda and Gcno files to generate code coverage information files. By storing the calculated code coverage information in Redis key-value pairs, it can quickly extract various technical requirements for code coverage, such as Diff operations on a single code coverage information file, merging operations on multiple code coverage information files, and configuring filtering rules for some files. For example, it can be used for backend code coverage calculation of instant messaging clients (such as WeChat Work), code coverage calculation on the WeChat Work iOS client, and code coverage calculation on the WeChat Work MAC client, achieving more efficient calculation.

[0103] The code coverage testing method provided in the embodiments of this application will be described in detail below.

[0104] The code coverage testing method provided in this application quickly calculates the code coverage test results for a large number of uploaded code coverage data files, such as Gcda and Gcno files, to obtain the code coverage test results report required by testers. Addressing the slow speed of related technologies using Lcov to process code coverage data files, this application extracts and modifies the Gcov tool from GCC 4.4+ to meet the requirements of code coverage data calculation, processing, and output format. For ease of description, this application refers to the modified Gcov tool as Gcov4.

[0105] For example, see Figure 7 , Figure 7 This is a schematic diagram of the processing flow of a single Gcov4 provided in an embodiment of this application, as shown below. Figure 7 As shown, Gcov4 records the input path (e.g., the path where a set of Gcda and Gcno files to be processed are located), the output path (e.g., the path where the generated Info file is located), and the output format requirements by processing input parameters. Figure 7 (Not shown in the image). To meet the requirement of directly outputting Info format files, a new format parameter -i has been added. This parameter can directly determine whether the output file is in Info format, while keeping other Gcov functionalities unchanged. This allows for modification of the Gcov source code at minimal cost, adding new functionality without affecting existing features. Furthermore, when using Gcov4, only a set of corresponding Gcda and Gcno files can be passed in, facilitating subsequent concurrent processing at the file level.

[0106] The following explains the processing procedures for Gcda and Gcno files.

[0107] The process of processing Gcda and Gcno files involves reading code coverage information from these files and storing it in the Gcov4 data structure. Since the code coverage information in Gcda and Gcno files is represented based on basic blocks (Block_Info) and arcs (ARC_Info), Gcov4 needs to extract code coverage information in dimensions such as function coverage and line coverage from the basic block and arc information, and express it as line number information (Line_Info) and function information (Function_Info). The entire process of reading basic blocks and arcs is essentially traversing the entire file's execution chain, requiring judgments on the predecessors (Pred) and successors (Succ) of basic blocks and arcs.

[0108] Finally, in the output step of generating the Info format file (i.e., writing the generated standardized code coverage information to the Info file), it is necessary to perform a link traversal from the line number information and function information that store the code coverage information. The code coverage display only needs to be in the line dimension, for example, see [link to relevant documentation]. Figure 8 , Figure 8 This is a schematic diagram of the output of the Info file provided in the embodiments of this application, such as... Figure 8 As shown, the final code coverage information is displayed only at the line level, eliminating irrelevant information, thereby reducing file read and write operations. Figure 8 The two numbers following DA in the diagram represent the line number and the number of times the current line has been executed. For example, DA: 23, 0 means that the current line is the 23rd line and has been executed 0 times. DA: 25, 1 means that the current line is the 25th line and has been executed 1 time. end_of_record represents the end-of-record marker.

[0109] In addition, it should be noted that after Gcov4 finishes processing a set of incoming Gcda and Gcno files, it can release the previously recorded data structure space for use by the next set of Gcda and Gcno files. That is, the code coverage information read from the next set of Gcda and Gcno files is stored in the Gcov4 data structure.

[0110] After completing the modifications to Gcov4, the embodiments of this application can perform concurrent calculations at the dimension of code coverage data files. For example, see [link to example]. Figure 9 , Figure 9 This is a flowchart illustrating the concurrent processing of multiple Gcov4 processes provided in the embodiments of this application, such as... Figure 9 As shown, the input consists of all code coverage data files generated during the test, including Gcda and Gcno files. Then, multiple code coverage data files are matched based on their filenames to obtain multiple datasets. Each dataset includes a corresponding Gcda and Gcno file. These datasets are then stored in a processing queue, waiting for a process pool to distribute the appropriate processes for computation. For example, the size of the process pool can be set according to the conditions of the computing machines and the number of code coverage data files to be computed, thereby achieving optimal concurrent processing.

[0111] Each dataset's corresponding Gcda and Gcno files generate multiple Info format files (corresponding to the code coverage information subfiles mentioned above) after computation. If these files are used for merging after concurrency, the computational advantage gained from concurrency will be diminished. Therefore, the computation results can be stored in Redis at the task level, allowing for more granular coverage operations within Redis. For example, Redis set operations can be used to perform the merging process during computation.

[0112] Redis's key-value design for code coverage information files is as follows: Figure 10 As shown, the prefix TaskID is used to identify a unique code coverage information file (i.e., one TaskID corresponds to all code coverage calculation data generated by one test case, and this data consists of multiple Info files, so multiple Info files corresponding to the same TaskID need to be merged together). Additionally, File1 and File20 are used to identify the file names, the suffix Total (corresponding to the first suffix mentioned above) is used to identify all the line numbers in the file, and the suffix Cov (corresponding to the second suffix mentioned above) is used to identify all the covered lines in the file (i.e., all executed lines of code). In Info format, this corresponds to the conversion result on the right. Furthermore, it distinguishes between executed and unexecuted lines of code within the file. Different styles can be used to distinguish them. For example, the executed lines of code can be represented by slashes. For a file named File1, all the lines of code in the file include 1, 2, and 4. Lines 1 and 4 are executed, corresponding to DA:1,1, DA:2,0, and DA:4,1 on the right. For a file named File20, all the lines of code in the file also include 1, 2, and 4. Only line 4 is executed, corresponding to DA:1,0, DA:2,0, and DA:4,1 on the right. It can be seen that the advantage of this structure is that it not only reduces file storage, but also facilitates operations such as merging and diffing code coverage information files corresponding to different tasks.

[0113] In addition, see Figure 11 , Figure 11 This is a schematic diagram of the Redis connection pool provided in the embodiments of this application, as shown below. Figure 11As shown, for multiple Gcda and Gcno files, when multiple Gcov4 processing threads perform multiple calculations (e.g., multiple Gcov4 processing threads simultaneously request read / write coverage connections from the Redis connection pool, meaning the Redis connection pool simultaneously receives multiple connection requests to store the calculated code coverage information file into Redis), since the calculation result (i.e., the code coverage information file) is stored in Redis, multiple Redis connections cannot be established here, as the creation and destruction of multiple connections would incur performance overhead. Therefore, during the data processing of a single task, the Redis connection pool mechanism can be utilized (i.e., a certain number of connections are pre-initialized and placed in the connection pool; when Redis needs to be operated, such as when the calculation result needs to be stored in Redis, the connection can be directly retrieved from the Redis connection pool, thus saving the performance overhead of creating and destroying connections), to achieve dynamic connection management, thereby reducing the performance overhead of connection creation and destruction, and ultimately achieving efficient writing. In addition, to speed up the reading of Redis code coverage data, a two-level caching mechanism can be used to cache the code coverage information file corresponding to a single task as a key. That is, the task identifier corresponding to the task is used as the key, and the code coverage information file corresponding to the task identifier is used as the value for storage, thereby reducing the time required to look up the key.

[0114] The code coverage testing method provided in this application modifies the source code of Gcov, performs parallel processing on it at the file level, and stores the calculated code coverage information file (containing the corresponding code coverage data) in a Redis collection in the form of key-value pairs. This facilitates subsequent version difference (Diff) and version merging operations, reduces the tedious operation of file persistence, and thus reduces the time consumption.

[0115] The beneficial effects of the code coverage testing method provided in the embodiments of this application will be further explained below with reference to experimental data.

[0116] For example, see Table 1, which is a comparison table of processing speeds provided in the embodiments of this application. As shown in Table 1, for 200+ code coverage data files (including Gcda files and Gcno files), the concurrent calculation of code coverage data using the modified Gcov (i.e., Gcov4) provided in the embodiments of this application can be completed in seconds. For example, for 240 files, the concurrent Gcov4 provided in the embodiments of this application can be completed in 2.09 seconds, while the Lcov provided by related technologies would take 127 seconds to complete. In other words, compared with the Lcov provided by related technologies, the technical solution provided in the embodiments of this application achieves an acceleration effect of about 60 times.

[0117] Table 1. Processing Speed ​​Comparison

[0118] Furthermore, in routine code coverage testing, code coverage data is stored in Redis key-value pairs. From front-end display to back-end data processing, this reduces unnecessary file writes by 70%, minimizing disk pressure. Additionally, Redis reads are faster than file reads, resulting in faster front-end display and a 3-4 times speedup in the entire code coverage testing process.

[0119] The following description continues to illustrate the exemplary structure of the code coverage test processing apparatus 243 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules in the code coverage test processing device 243 stored in the memory 240 may include: an acquisition module 2431, a matching module 2432, a processing module 2433, a merging module 2434, and a storage module 2435.

[0120] The acquisition module 2431 is used to acquire multiple code coverage data files, each of which includes: a data file generated during test code testing and a symbol file generated by compiling the code; the matching module 2432 is used to match the multiple code coverage data files according to the file names to obtain multiple datasets, each of which includes a corresponding data file and a symbol file; the processing module 2433 is used to process the multiple datasets in parallel based on multiple processes in the process pool used to run the code, to obtain a code coverage information sub-file corresponding to each dataset; the merging module 2434 is used to merge the multiple code coverage information sub-files into a code coverage information file based on the task identifier; and the storage module 2435 is used to store the multiple code coverage information files in the form of key-value pairs.

[0121] In some embodiments, the storage module 2435 is further configured to store multiple datasets in a processing queue; the processing module 2433 is further configured to obtain multiple datasets from the processing queue in the same number as multiple processes, and distribute the multiple datasets to the multiple processes respectively, with each process processing one of the distributed datasets; when any of the multiple processes finishes processing, the remaining dataset is obtained from the processing queue, and the remaining dataset is processed by any process, until all datasets stored in the processing queue have been processed.

[0122] In some embodiments, the processing module 2433 is further configured to perform the following processing through each process: obtain parameters carried by the dataset, wherein the parameters include an input path, an output path, and format parameters; obtain the data files and symbol files included in the dataset according to the input path; process the data files and symbol files included in the dataset based on the format parameters to obtain a code coverage information sub-file that meets the format requirements; and store the code coverage information sub-file that meets the format requirements in the database at the location corresponding to the output path.

[0123] In some embodiments, the processing module 2433 is further configured to obtain code coverage information from the data files and symbol files included in the dataset, wherein the code coverage information is characterized based on basic blocks and arcs; perform format conversion on the code coverage information according to format parameters; and generate a code coverage information sub-file that meets the format requirements based on the format-converted code coverage information.

[0124] In some embodiments, the processing module 2433 is further configured to obtain program flow graph information from the symbol file included in the dataset, and establish a program flow graph for each function in the code based on the program flow graph information; obtain the known execution counts of arcs from the data file included in the dataset, and write the known execution counts of arcs into the program flow graph; determine the execution counts of other arcs and basic blocks based on the program flow graph and the known execution counts of arcs; and determine the code coverage information corresponding to the code based on the execution counts of all arcs and basic blocks, wherein the code coverage information includes at least one of the following: function information and line number information.

[0125] In some embodiments, the processing module 2433 is further configured to perform the following processing for multiple code coverage information sub-files corresponding to each use case: obtaining the task identifier corresponding to the use case; using the task identifier as a prefix for multiple code coverage information sub-files; wherein the task identifiers corresponding to different use cases are different.

[0126] In some embodiments, the processing module 2433 is further configured to perform the following processing for each code coverage information sub-file: setting a first suffix and a second suffix for the code coverage information sub-file, wherein the first suffix is ​​used to identify all the code lines corresponding to the code coverage information sub-file, and the second suffix is ​​used to identify the executed code lines among all the code lines corresponding to the code coverage information sub-file.

[0127] In some embodiments, the code coverage test processing apparatus 243 further includes a creation module 2436 for creating a process pool; the code coverage test processing apparatus 243 also includes a determination module 2437 for determining the number of processes included in the process pool based on the number of datasets to be processed and the performance conditions for running the process pool.

[0128] In some embodiments, the creation module 2436 is further configured to create a connection pool, wherein the connection pool includes multiple connections; the processing module 2433 is further configured to, when receiving multiple write requests corresponding to multiple code coverage information files respectively, process multiple write requests in parallel based on the multiple connections included in the connection pool, so as to store multiple code coverage information files into the database.

[0129] In some embodiments, the storage module 2435 is further configured to perform the following processing for each task identifier: storing the task identifier as the key and the code coverage information file corresponding to the task identifier as the value.

[0130] In some embodiments, the code being tested is the updated code; the code coverage test processing device 243 further includes a comparison module 2438, used to compare the code coverage information file corresponding to the updated code with the code coverage information file corresponding to the code before the update, to obtain an incremental code coverage information file; the code coverage test processing device 243 further includes a generation module 2439, used to generate a code coverage report based on the incremental code coverage information file; the determination module 2437 is further used to determine the code coverage test result corresponding to the updated code based on the code coverage report.

[0131] It should be noted that the description of the device in the embodiments of this application is similar to the implementation of the code coverage test processing method described above, and has similar beneficial effects, therefore it will not be repeated. For any technical details not covered in the code coverage test processing device provided in the embodiments of this application, please refer to... Figure 3-5 The meaning is understood in accordance with the description of any of the accompanying drawings.

[0132] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the code coverage testing method described in this application.

[0133] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute the code coverage testing method provided in this application. For example, ... Figure 3-5 The code coverage test processing method is shown in any of the attached figures.

[0134] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0135] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0136] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0137] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0138] In summary, this embodiment first matches multiple code coverage data files to be processed based on their filenames to obtain multiple datasets. Then, it processes these datasets in parallel using multiple processes within a process pool to obtain a code coverage information sub-file for each dataset. Subsequently, it merges these multiple code coverage information sub-files based on task identifiers. Finally, it stores the merged multiple code coverage information files in key-value pairs. In this way, the datasets to be processed are parallelized, greatly improving the testing efficiency of code coverage. Furthermore, the storage of the final multiple code coverage information files in key-value pairs reduces subsequent search time, thereby significantly improving the work efficiency of developers and testers.

[0139] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for testing code coverage, characterized in that, The method includes: Obtain multiple code coverage data files, wherein each code coverage data file includes: a data file generated when testing the code based on test cases and a symbol file generated by compiling the code; The data files and symbol files with the same filename in the multiple code coverage data files are merged into the same dataset to obtain multiple datasets, wherein each dataset includes a corresponding set of the data file and a corresponding set of the symbol file; Store the multiple datasets into a queue to be processed; Obtain multiple datasets of the same number as the process from the queue to be processed, and distribute the multiple datasets to the process respectively; The following processing is performed through each of the aforementioned processes: Obtain the data files and symbol files included in the dataset based on the input path carried by the dataset; Code coverage information is obtained from the data files and symbol files included in the dataset, wherein the code coverage information is characterized based on basic blocks and arcs; The code coverage information is format-converted according to the format parameters carried by the dataset; Based on the code coverage information after format conversion, a code coverage information subfile that meets the format requirements is generated. Store the code coverage information sub-file that meets the format requirements in the database at the location corresponding to the output path carried by the dataset; When any of the processes in the process finishes processing, the space of the data structure recorded during the processing of the dataset is released. The remaining dataset is obtained from the queue to be processed. The code coverage information obtained from the remaining dataset is stored in the released data structure space. The remaining dataset is processed by any of the processes until all datasets stored in the queue to be processed are processed, and a code coverage information sub-file corresponding to each dataset is obtained. Multiple code coverage information sub-files are merged into a single code coverage information file based on a task identifier. The merging is achieved by performing a set operation on the set of multiple code coverage information sub-files corresponding to the task identifier in the database. For each of the task identifiers, perform the following processing: The task identifier is used as the key, and the code coverage information file corresponding to the task identifier is used as the value for storage.

2. The method according to claim 1, characterized in that, The step of obtaining code coverage information from the data files and symbol files included in the dataset includes: Obtain program flow graph information from the symbol files included in the dataset, and build a program flow graph for each function in the code based on the program flow graph information; The known number of executions of the arcs are obtained from the data files included in the dataset, and the known number of executions of the arcs are written into the program flow graph; Based on the program flow graph and the known number of executions of the arcs, determine the number of executions of the other arcs and basic blocks; Based on the number of executions of all arcs and basic blocks, the code coverage information corresponding to the code is determined, wherein the code coverage information includes at least one of the following: function information and line number information.

3. The method according to claim 1, characterized in that, After obtaining the code coverage information sub-file corresponding to each dataset, the method further includes: For each of the multiple code coverage information subfiles corresponding to the aforementioned use case, the following processing is performed: Obtain the task identifier corresponding to the use case; Use the task identifier as the prefix for the multiple code coverage information sub-files; Different use cases correspond to different task identifiers.

4. The method according to claim 3, characterized in that, The method further includes: For each of the code coverage information subfiles, perform the following processing: A first suffix and a second suffix are set for the code coverage information sub-file, wherein the first suffix is ​​used to identify all the code lines corresponding to the code coverage information sub-file, and the second suffix is ​​used to identify the executed code lines among all the code lines corresponding to the code coverage information sub-file.

5. The method according to claim 1, characterized in that, Before retrieving multiple datasets of the same number as the process from the queue to be processed, the method further includes: Create a process pool; The number of processes included in the process pool is determined based on the number of datasets to be processed and the performance conditions required to run the process pool.

6. The method according to claim 1, characterized in that, The method further includes: Create a connection pool, wherein the connection pool comprises multiple connections; When multiple write requests corresponding to multiple code coverage information files are received, the multiple write requests are processed in parallel based on the multiple connections included in the connection pool, so as to store the multiple code coverage information files into the database.

7. The method according to claim 1, characterized in that, The code is the updated code; the method also includes: The updated code coverage information file is compared with the original code coverage information file to obtain the incremental code coverage information file. Based on the incremental code coverage information file, a code coverage report is generated; Based on the code coverage report, determine the code coverage test results corresponding to the updated code.

8. A code coverage testing processing device, characterized in that, The device includes: The acquisition module is used to acquire multiple code coverage data files, wherein each code coverage data file includes: a data file generated when testing the test code based on test cases and a symbol file generated by compiling the code; The matching module is used to merge data files and symbol files with the same filename from the multiple code coverage data files into the same dataset to obtain multiple datasets, wherein each dataset includes a corresponding set of data files and a set of symbol files; A storage module is used to store the multiple datasets into a queue to be processed; A processing module is configured to obtain multiple datasets, the same number as the number of processes, from the processing queue and distribute the datasets to the processes respectively; each process performs the following processing: obtaining the data files and symbol files included in the dataset according to the input path carried by the dataset; obtaining code coverage information from the data files and symbol files included in the dataset, wherein the code coverage information is characterized based on basic blocks and arcs; performing format conversion on the code coverage information according to the format parameters carried by the dataset; generating a code coverage information sub-file that meets the format requirements based on the format-converted code coverage information; storing the code coverage information sub-file that meets the format requirements in the database at the location corresponding to the output path carried by the dataset; when any process in the process finishes processing, releasing the data structure space recorded during the processing of the dataset; obtaining the remaining dataset from the processing queue, storing the code coverage information obtained from the remaining dataset in the released data structure space, and processing the remaining dataset by any process until all datasets stored in the processing queue have been processed, obtaining the code coverage information sub-file corresponding to each dataset; The merging module is used to merge multiple code coverage information sub-files into a single code coverage information file based on a task identifier. The merging is achieved by performing a set operation on the set of multiple code coverage information sub-files corresponding to the task identifier in the database. The storage module is configured to perform the following processing for each task identifier: storing the task identifier as the key and the code coverage information file corresponding to the task identifier as the value.

9. The apparatus according to claim 8, characterized in that, The processing module is further configured to: Obtain program flow graph information from the symbol files included in the dataset, and build a program flow graph for each function in the code based on the program flow graph information; The known number of executions of the arcs are obtained from the data files included in the dataset, and the known number of executions of the arcs are written into the program flow graph; Based on the program flow graph and the known number of executions of the arcs, determine the number of executions of the other arcs and basic blocks; Based on the number of executions of all arcs and basic blocks, the code coverage information corresponding to the code is determined, wherein the code coverage information includes at least one of the following: function information and line number information.

10. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the code coverage test processing method according to any one of claims 1 to 7.

11. A computer-readable storage medium storing executable instructions, characterized in that, When the executable instructions are executed by the processor, they implement the code coverage test processing method according to any one of claims 1 to 7.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the code coverage test processing method according to any one of claims 1 to 7.

Images