Method and device for determining incremental code test coverage rate and processor

Abstract

The embodiment of the invention provides a method and device for determining the incremental code test coverage rate and a processor, and belongs to the technical field of software engineering.The method comprises the steps that a plurality of test coverage rate files corresponding to a plurality of test versions of a target code bin are combined through a hash value of first basic block data in the test coverage rate files, and the first basic block data in the test coverage rate files are obtained; determining a combined test coverage rate file; filtering the combined test coverage rate file by utilizing a hash value of second basic block data in a code analysis file corresponding to the latest version of the target code bin, and determining a test coverage rate file corresponding to the latest version of the target code bin; and determining the test coverage rate corresponding to the incremental code according to the incremental code corresponding to the newest version of the target code bin and the test coverage rate file corresponding to the newest version of the target code bin. According to the method provided by the embodiment of the invention, the test depth and breadth of the project test stage can be determined, and the overall test condition is quantitatively represented.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering, and in particular to a method, device and processor for determining incremental code test coverage. Background Art

[0002] Software testing is a key step in the software development process. It aims to verify whether the quality and functionality of the software system meet user needs through manual or automated means, and to discover potential defects.

[0003] In existing technologies, software functionality is typically verified by designing test cases. However, these test cases suffer from insufficient coverage, failing to cover all software functions, scenarios, and boundary conditions. Furthermore, these test cases only verify surface functionality, failing to delve into the software's internal logic and data processing. Black-box testing, in particular, ignores the software's internal implementation details and focuses solely on its inputs and outputs. By inputting various test data, the software is tested to determine whether it produces the correct output and verify that its functionality meets requirements. Summary of the Invention

[0004] The purpose of the embodiment of the present invention is to provide a method and device for determining incremental code test coverage. and processor, the method can solve or at least partially solve the above-mentioned defects of the prior art.

[0005] In order to achieve the above objectives, the first aspect of the embodiment of the present invention provides an incremental code test coverage A method for determining a rate, the method comprising: Merge multiple test coverage files corresponding to multiple test versions of the target code repository using the hash value of the first basic block data in the test coverage file to determine a merged test coverage file; Filtering the merged test coverage file using a hash value of the second basic block data in the code analysis file corresponding to the latest version of the target code repository to determine a test coverage file corresponding to the latest version of the target code repository; and Determining the test coverage corresponding to the incremental code according to the incremental code corresponding to the latest version of the target code repository and the test coverage file corresponding to the latest version of the target code repository; The first basic block data in the test coverage file includes: an instruction segment and the line number range, file name and execution times of the source code corresponding to the instruction segment; The second basic block data in the code analysis file includes: an instruction segment and: a line number range and a file name of a source code corresponding to the instruction segment.

[0006] In some embodiments, determining the merged test coverage file includes: When any of the hash values ​​corresponds to a plurality of the first basic block data: selecting any of the first basic block data among the plurality of the first basic block data corresponding to the hash value as the target basic block data; updating the target basic block data using the sum of the execution times of the instruction segments in the plurality of first basic block data corresponding to any one of the hash values; and Saving the target basic block data to the merged test coverage file; When any of the hash values ​​corresponds to only one piece of the first basic block data: The first basic block data corresponding to any of the hash values ​​is saved in the merged test coverage file.

[0007] In some embodiments, determining the test coverage file corresponding to the latest version of the target code repository includes: Analyze the hash value of the second basic block data in the code file corresponding to the latest version of the target code repository to generate a hash value set; For any first basic block data in the merged test coverage file, when the hash value of any first basic block is in the hash value set, the any first basic block data is saved to the test coverage file corresponding to the latest version of the target code warehouse.

[0008] In some embodiments, determining the test coverage corresponding to the incremental code includes: Determine, based on the incremental code corresponding to the latest version of the target code repository, the line number corresponding to the incremental code; Determine the test coverage corresponding to the incremental code based on the line number corresponding to the incremental code and the test coverage file corresponding to the latest version of the target code repository.

[0009] In some embodiments, the incremental code corresponding to the latest version of the target code repository is determined based on the Gerrit submission record of the target code repository.

[0010] In some embodiments, the multiple test coverage files corresponding to the multiple test versions of the target code repository are generated in the following manner: For any of the test versions of the target code repository, insert code that collects the execution status of each line of code during the compilation process to generate a target file corresponding to any of the test versions; Integrate and publish the target files corresponding to any of the test versions to the client; and Receive a test coverage file corresponding to any of the test versions generated by the client after the test is completed.

[0011] In some embodiments, the hash value of the first basic block data in the test coverage file is determined according to the instruction segment and the line number range and file name of the source code corresponding to the instruction segment.

[0012] In some embodiments, the hash value of the second basic block data in the code analysis file is determined according to the instruction segment and the line number range and file name of the source code corresponding to the instruction segment.

[0013] In some embodiments, the method further includes: giving a corresponding warning when the test coverage corresponding to the incremental code is less than a preset threshold.

[0014] A second aspect of an embodiment of the present invention provides a device for determining incremental code test coverage, comprising: a memory configured to store instructions; and a processor configured to call the instructions from the memory and to implement the method for determining incremental code test coverage when executing the instructions. A third aspect of an embodiment of the present invention provides a processor for running a program, wherein the program, when run, is used to execute: the method for determining incremental code test coverage.

[0015] A fourth aspect of an embodiment of the present invention provides a computer program product, including a computer program, which implements the method for determining incremental code test coverage when executed by a processor.

[0016] An embodiment of the present invention provides a method for determining incremental code test coverage. On the one hand, the method merges multiple test coverage files corresponding to multiple test versions of a target code repository to determine a merged test coverage file, and filters the merged test coverage file to determine the test coverage file corresponding to the latest version of the target code repository. This method can provide complete analysis data on the test coverage corresponding to multiple code changes, thereby determining the test depth and breadth of the project test phase and quantitatively characterizing the overall test situation. On the other hand, determining the test coverage data of the incremental code based on the code version changes can avoid missed tests.

[0017] Other features and advantages of the embodiments of the present invention will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings are used to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the following detailed description, they are used to explain the embodiments of the present invention, but do not constitute a limitation of the embodiments of the present invention. In the accompanying drawings: Figure 1 1 is a flow chart of a method for determining incremental code test coverage provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of a process for generating a test coverage file according to an embodiment of the present invention; Figure 3 Schematic diagram of the compilation process of the target code warehouse provided by an embodiment of the present invention; Figure 4 This is a schematic diagram of a process for determining a test coverage file corresponding to the latest version of a target code repository according to an embodiment of the present invention; Figure 5 1 is a flow chart of a method for determining incremental code test coverage provided by an embodiment of the present invention; Figure 6 It is a visualized HTML diagram of the execution times of incremental codes provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0019] The following describes the specific implementation of the embodiment of the present invention in detail with reference to the accompanying drawings. It should be understood that the specific implementation described herein is only used to illustrate and explain the embodiment of the present invention and is not used to limit the embodiment of the present invention.

[0020] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application are in compliance with the relevant provisions of laws and regulations. In the embodiments of this application, certain software, components, models, and other existing solutions in the industry may be mentioned. These should be considered as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or will necessarily use such solutions.

[0021] Before describing the method provided by the embodiment of the present invention in detail, the client testing process will be described in detail. The client testing process includes: the developer submits the test code of version A, the tester packages the test code of version A and deploys it to the application client of terminal devices of different models, the tester tests the client and feeds back the defects found during the test to the developer, the developer modifies the defect, generates the test code of version B, and submits version B to the tester for retesting. The tester needs to package and redeploy the test code of version B on different models to verify whether the developer has fixed the defect. During the client testing process, multiple defects are usually found, and the developer will submit multiple versions of test code to fix multiple defects. At this time, if the version corresponding to the client being tested by the tester is not the latest version of the code submitted by the developer, it is easy to miss the test of the latest version of the code submitted by the developer.

[0022] Figure 1 This is a flow chart of a method for determining incremental code test coverage provided by an embodiment of the present invention, referring to Figure 1 , an embodiment of the present invention provides a method for determining incremental code test coverage, the method comprising: S101. Using the hash value of the first basic block data in the test coverage file, multiple test coverage files corresponding to multiple test versions of the target code repository are merged to determine a merged test coverage file.

[0023] Figure 2 This is a schematic diagram of the process of generating a test coverage file provided by an embodiment of the present invention, referring to Figure 2 , the test coverage file is generated in the following way: S201: For any of the test versions of the target code repository, insert code that collects the execution status of each line of code during the compilation process to generate a target file corresponding to any of the test versions; In some embodiments, by setting corresponding compilation options, code for collecting the execution status of each line of code is inserted during the compilation process.

[0024] Figure 3 This is a schematic diagram of the compilation process of the target code warehouse provided by the embodiment of the present invention, referring to Figure 3 , S201 is explained in detail.

[0025] The compilation process consists of three phases: frontend, optimization, and backend. The frontend converts source code into LLVM intermediate representation (IR), including lexical / syntactic analysis, semantic analysis, and IR generation. Optimization analyzes and optimizes LLVM IR to improve code performance. The backend converts the optimized IR into assembly or binary code for the target machine.

[0026] Specifically, for IOS projects, IR code will be generated during the client compilation process. The embodiment of the present invention fully inserts the IR code after generating the IR file and before generating the target file, that is, inserts code to collect the execution status of each line of code, and compiles the IR code after insertion to generate the corresponding target file.

[0027] Furthermore, the target file is a .o file, which is a binary file and is an intermediate product after the compiler compiles the source code, and contains information such as machine code and symbol table.

[0028] In some embodiments, IR instrumentation is performed only in the packaging process corresponding to the testing phase, and the code for collecting the execution status of each line of code will filter all instrumentation operations of the packaging process corresponding to the online phase to avoid affecting the online application.

[0029] The testing phase involves comprehensive software testing prior to release, including functional, performance, and user experience testing. The launch phase involves moving the completed product or system from an internal testing environment to a production environment for real users.

[0030] S202: Integrate and publish the target files corresponding to any of the test versions to the client; The tester tests the client that has the target file corresponding to the test version integrated. During the test, the code inserted in S201 to collect the execution status of each line of code is executed, and the execution status of each line of code is collected and saved to the .profdata file. The execution status of each line of code specifically includes a true / false mark indicating whether each line of code is executed and the number of times each line of code is executed. S203: Receive the test coverage file corresponding to any of the test versions generated by the client after the test is completed.

[0031] In some embodiments, to reduce the number of uploads, the test coverage file is uploaded only via the client SDK during a cold start of the client, or an upload button is configured so that the client SDK uploads the test coverage file to the server when the user clicks the upload button. A cold start refers to starting the client application without any relevant processes or cached information remaining in memory.

[0032] Therefore, the method of obtaining the test coverage file through assembly language instrumentation (IR instrumentation) in the embodiment of the present invention will not affect the execution speed of the code, nor the page loading speed. On the other hand, the corresponding test coverage file can be generated by IR instrumentation by designing corresponding compilation options, which can be seamlessly and low-costly integrated into the project and can also be integrated into CI / CD platforms, such as Jenkins, to flexibly control packaging tasks.

[0033] It's important to note that client version changes (such as new feature releases or bug fixes) generally involve code changes across multiple repositories. IR instrumentation can be performed during the compilation and packaging of these repositories to generate corresponding test coverage files. Furthermore, during the compilation of any of the repositories involved, an option to enable IR instrumentation and generate corresponding test coverage files can be selected, allowing for rapid and cost-effective integration into client applications.

[0034] In some embodiments, the first basic block data in the test coverage file includes: an instruction segment and: a line number range of a source code, a file name, and execution times corresponding to the instruction segment.

[0035] The instruction segment is a basic block (or BB block). A basic block is an execution unit grouped by code execution unit. The instructions within each unit have the same execution count. Furthermore, a basic block meets the following conditions: control flow can only enter the basic block from the first instruction in the basic block. Except for the last instruction in the basic block, control flow does not stop or jump before leaving the basic block. Once the first instruction in the basic block is executed, all instructions in the basic block are executed. The execution count for an instruction segment is also the execution count of the source code corresponding to the instruction segment.

[0036] It should be noted that if the execution count corresponding to the instruction segment is greater than 0, it means that the test process covers multiple lines of source code corresponding to the instruction segment, or the execution count of the line of code is equal to 0, it means that the test process does not cover multiple lines of source code corresponding to the instruction segment.

[0037] In some embodiments, the hash value of the first basic block data in the test coverage file is determined according to the instruction segment and the line number range and file name of the source code corresponding to the instruction segment.

[0038] Specifically, the line number range of the source code includes the line number of each line of code corresponding to the source code.

[0039] Furthermore, determining the merged test coverage file in S101 includes the following steps: S301, when any of the hash values ​​corresponds to multiple first basic block data: execute S302 to S304; when any of the hash values ​​corresponds to only one first basic block data, execute S305; S302: Select any first basic block data from the plurality of first basic block data corresponding to any of the hash values ​​as target basic block data; S303: Update the target basic block data using the sum of the execution times of the instruction segments in the plurality of first basic block data corresponding to any of the hash values; For S302 to S303, when any of the hash values ​​corresponds to multiple first basic block data, it means that the source codes corresponding to the multiple first basic block data are the same and are executed multiple times, and it is necessary to summarize and count the execution times corresponding to the source code. In some embodiments, reference Figure 4 In section 601, S302~S303 are described in detail.

[0040] like Figure 4 As shown, the three test versions include version 1, version 2 and version 3. Figure 4 The class object A in the example has code changes in all three test versions. The test coverage file for test version 1 includes BB block 1 (corresponding to hash value h1, executed once) and BB block 2 (corresponding to hash value h2, executed once). The test coverage file corresponding to test version 2 includes BB block 3 (corresponding to hash value h1, executed once) and BB block 4 (corresponding to hash value h3, executed once). The test coverage file for test version 3 includes BB block 5 (corresponding hash value is h4, executed 0 times); First, by summarizing and analyzing the first basic block data in the test coverage files corresponding to the three test versions, we can find that: Hash value h1 corresponds to: BB block 1, and BB block 3; Hash value h2 corresponds to: BB block 2; Hash value h3 corresponds to: BB block 4; Hash value h4 corresponds to: BB block 5.

[0041] Among them, for the hash value h1, it corresponds to multiple BB blocks: BB block 1 and BB block 3, which means that the source code corresponding to BB block 1 and BB block 3 is the same and has been executed multiple times. It is necessary to summarize the total number of executions of the code segments corresponding to BB block 1 and BB block 3.

[0042] Then, for the hash value h1, BB block 1 or BB block 3 is selected as the target basic block data corresponding to the hash value h1. In this embodiment, BB block 1 is selected as the target basic block T1 corresponding to the hash value h1. According to the number of executions of the instruction segments corresponding to BB block 1 (executed 1 time) and BB block 3 (executed 1 time), the corresponding total number of executions Sum = 2 is determined, and then the number of executions in T1 is updated using Sum, and T1 is saved to the merged test coverage file.

[0043] Then, for hash values ​​h2, h3, and h4, since they all correspond to one BB block, BB block 2, BB block 4, and BB block 5 are directly saved to the merged test coverage file.

[0044] Finally, the finalized merged test coverage files include: T1 (corresponding to hash value h1, executed 2 times), BB block 2 (corresponding to hash value h2, executed 1 time), BB block 4 (corresponding to hash value h3, executed 1 time) and BB block 5 (corresponding to hash value h4, executed 0 times).

[0045] S304, saving the target basic block data to the merged test coverage file; S305: Save the first basic block data corresponding to any of the hash values ​​to the merged test coverage file.

[0046] S102: Filter the merged test coverage file using a hash value of the second basic block data in the code analysis file corresponding to the latest version of the target code repository to determine a test coverage file corresponding to the latest version of the target code repository; In some embodiments, the second basic block data in the code analysis file includes: an instruction segment and: a line number range and a file name of a source code corresponding to the instruction segment.

[0047] In some embodiments, the hash value of the second basic block data in the code analysis file is determined according to the instruction segment and the line number range and file name of the source code corresponding to the instruction segment.

[0048] Specifically, a hash value is a fixed-length string or numeric value generated by applying a hash function to input data (such as a file, string, or number). A hash value uniquely identifies the input data, and even the slightest change in the original data will result in a completely different hash value.

[0049] In some embodiments, determining the test coverage file corresponding to the latest version of the target code repository in step 102 includes the following steps: S401: Analyze the hash value of the second basic block data in the code file corresponding to the latest version of the target code repository to generate a hash value set; S402. For any first basic block data in the merged test coverage file, when the hash value of any first basic block is in the hash value set, save the any first basic block data to the test coverage file corresponding to the latest version of the target code repository.

[0050] It should be noted that, for S402, when the hash value of any of the first basic blocks, such as H1, H2, H3, is not in the hash value set, it means that the source code in the first basic block data corresponding to the hash values ​​H1, H2, H3 is not the latest and has been replaced by new code. It is necessary to discard the first basic block data corresponding to H1, H2, H3, that is, discard the coverage statistics of the source code corresponding to H1, H2, H3.

[0051] In some embodiments, reference Figure 4 Part 602 provides a detailed description of S401~S402.

[0052] First, the code analysis file corresponding to the latest version of the target code repository includes BB block 6 (corresponding hash value h1), BB block 7 (corresponding hash value h2), and the hash value set S is (h1, h2).

[0053] Then, according to Figure 4 The final merged test coverage files for part 601 include: T1 (corresponding to hash value h1, executed 2 times), BB block 2 (corresponding to hash value h2, executed 1 time), BB block 4 (corresponding to hash value h3, executed 1 time) and BB block 5 (corresponding to hash value h4, executed 0 times).

[0054] Since the hash values ​​corresponding to BB block 4 (corresponding hash value is h3) and BB block 5 (corresponding hash value is h4) are not in the hash value set S, BB block 4 and BB block 5 are discarded, and only T1 (corresponding hash value is h1, executed 2 times) and BB block 2 (corresponding hash value is h2, executed 1 time) are saved to the test coverage file corresponding to the latest version of the target code repository.

[0055] S103. Determine the test coverage corresponding to the incremental code based on the incremental code corresponding to the latest version of the target code repository and the test coverage file corresponding to the latest version of the target code repository; In some embodiments, determining the test coverage corresponding to the incremental code includes the following steps: S501. Determine, based on the incremental code corresponding to the latest version of the target code repository, the line number corresponding to the incremental code; In some embodiments, the incremental code corresponding to the latest version of the target code repository is determined based on the Gerrit submission record of the target code repository.

[0056] Specifically, the line numbers involved in the incremental code can be determined through the Gerrit commit record or Git commit record corresponding to the target code repository. For example, the two versions are compared through the "git diff" command to determine the line numbers involved in the incremental code. Furthermore, "git diff" is a command for comparing code differences. This command can help developers quickly understand the modifications between different code versions. Specifically, "git diff" can display the differences in code snippets. For files that have been modified, the command will compare the file contents line by line and display the corresponding differences. Added code lines will be displayed with a "+" symbol, and deleted code lines will be displayed with a "-" symbol.

[0057] In some embodiments, the incremental code refers to the latest version of the target code repository and the main branch of the project (such as the master branch) by performing a "git diff" code comparison.

[0058] The master branch is the most stable and reliable primary branch, containing fully tested and reviewed code that meets release requirements. In large projects, team members develop code in their own branches. Once completed and tested, they merge the code into the master branch to form a new stable version.

[0059] Specifically, when a developer is developing specific functionality for a target repository, they first submit version 1.0 of the code to a tester for testing. After the tester detects defect A, the developer modifies the code, generates version 2.0, and submits it to the tester for testing again. After the tester reports defect B, the developer modifies the code, generates version 3.0, and submits it to the tester for testing again. At this point, the latest version of the target repository is version 3.0. Incremental code is determined by performing a git diff comparison between version 3.0 and the target repository's master branch.

[0060] S502: Determine the test coverage corresponding to the incremental code according to the line number corresponding to the incremental code and the test coverage file corresponding to the latest version of the target code repository.

[0061] Specifically, the test coverage file corresponding to the latest version of the target code repository includes multiple first basic block data, and the first basic block data includes: instruction segments and corresponding to the instruction segments: line number range, file name and execution count of the source code, thereby obtaining the execution count of each line of code in the full code of the target code repository. The line numbers corresponding to the incremental code are aggregated to determine a target filtered line number set. The test coverage file corresponding to the latest version of the target code repository is filtered to retain only the execution counts of the source code line numbers within the target filtered line number set. Finally, the test coverage corresponding to the incremental code is determined based on the total number of incremental code lines and the number of code lines with execution counts greater than 0.

[0062] It should be noted that client version changes (such as new feature releases or bug fixes) generally involve code changes in multiple code repositories, such as Figure 5 The code warehouse A, code warehouse B, and code warehouse C shown in the figure summarize the test coverage files corresponding to the latest version of any of the code warehouses to generate an .info file, where the .info file includes the data corresponding to the test coverage files corresponding to the latest version of code warehouse A, code warehouse B, and code warehouse C.

[0063] First, in S501 , the incremental code corresponding to the latest version of any code repository among code repository A, code repository B, and code repository C is determined, and the line number corresponding to the incremental code is determined.

[0064] Then, the execution count of each line of code in the incremental code corresponding to the latest version of any code repository among code repository A, code repository B, and code repository C is determined through S502.

[0065] For example, the line numbers corresponding to the incremental code corresponding to any code repository are summarized to determine a target filtered line number set; the test coverage file corresponding to the latest version of the target code repository is filtered to only retain the execution times of the source code whose line numbers are within the target filtered line number set.

[0066] Finally, the overall test coverage is determined based on the sum of the number of lines of code with execution times greater than 0 in the incremental code corresponding to the latest versions of Code Repository A, Code Repository B, and Code Repository C, as well as the total number of lines of incremental code corresponding to the latest versions of Code Repository A, Code Repository B, and Code Repository C.

[0067] In some embodiments, the following is generated based on the line number corresponding to the incremental code and the test coverage file corresponding to the latest version of the target code warehouse: Figure 6 The above-mentioned visual HTML page is displayed, so that at any stage of project testing, each R&D and testing colleague can intuitively see the degree of testing adequacy of the new code.

[0068] In some embodiments, when the test coverage of the incremental code is less than a preset threshold, a corresponding warning is issued. For example, when the test coverage of the incremental code is less than 80%, the relevant tester or developer is notified via email or text message that the test coverage is too low.

[0069] In some embodiments, during the testing phase, the incremental code test coverage method provided by the embodiments of the present invention is executed multiple times to generate multiple corresponding incremental code test coverage files, including the execution count for each line of code in the incremental code and the test coverage of the incremental code. These multiple corresponding incremental code test coverage files are saved, thereby providing corresponding analytical data for subsequent problem tracing and review.

[0070] An embodiment of the present invention provides a device for determining incremental code test coverage, comprising: a memory configured to store instructions; and a processor configured to call the instructions from the memory and implement the method for determining incremental code test coverage when executing the instructions. An embodiment of the present invention provides a processor for running a program, wherein the program, when run, is configured to perform the method for determining incremental code test coverage. An embodiment of the present invention provides a computer-readable storage medium having instructions stored thereon, which, when executed by the processor, implement the method for determining incremental code test coverage.

[0071] An embodiment of the present invention provides a computer program product, including a computer program, which implements the method for determining incremental code test coverage when executed by a processor.

[0072] An embodiment of the present invention provides a method for determining the test coverage of incremental code. On the one hand, the method determines the merged test coverage file by merging multiple test coverage files corresponding to multiple test versions of the target code repository, and filters the merged test coverage file to determine the test coverage file corresponding to the latest version of the target code repository. This method can provide complete analysis data for the test coverage corresponding to multiple code changes, thereby determining the test depth and breadth of the project testing phase, quantitatively characterizing the overall test situation, and providing corresponding analysis data for subsequent problem tracing and review. On the other hand, determining the test coverage data of the incremental code based on the code version changes can avoid missed tests.

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

[0074] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0075] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0076] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0077] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0078] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0079] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0080] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0081] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for determining incremental code test coverage, characterized in that: The method comprises: Merge multiple test coverage files corresponding to multiple test versions of the target code repository using the hash value of the first basic block data in the test coverage file to determine a merged test coverage file; Filtering the merged test coverage file using a hash value of the second basic block data in the code analysis file corresponding to the latest version of the target code repository to determine a test coverage file corresponding to the latest version of the target code repository; and Determining the test coverage corresponding to the incremental code according to the incremental code corresponding to the latest version of the target code repository and the test coverage file corresponding to the latest version of the target code repository; The first basic block data in the test coverage file includes: an instruction segment and the line number range, file name and execution times of the source code corresponding to the instruction segment; The second basic block data in the code analysis file includes: an instruction segment and: a line number range and a file name of a source code corresponding to the instruction segment.

2. The method according to claim 1, wherein: Determining the merged test coverage file includes: When any of the hash values ​​corresponds to a plurality of the first basic block data: selecting any of the first basic block data among the plurality of the first basic block data corresponding to the hash value as the target basic block data; updating the target basic block data using the sum of the execution times of the instruction segments in the plurality of first basic block data corresponding to any one of the hash values; and Saving the target basic block data to the merged test coverage file; When any of the hash values ​​corresponds to only one piece of the first basic block data: The first basic block data corresponding to any of the hash values ​​is saved in the merged test coverage file.

3. The method according to claim 1, wherein: Determining the test coverage file corresponding to the latest version of the target code repository includes: Analyze the hash value of the second basic block data in the code file corresponding to the latest version of the target code repository to generate a hash value set; For any first basic block data in the merged test coverage file, when the hash value of any first basic block is in the hash value set, the any first basic block data is saved to the test coverage file corresponding to the latest version of the target code warehouse.

4. The method according to claim 1, wherein: Determining the test coverage corresponding to the incremental code includes: Determine, based on the incremental code corresponding to the latest version of the target code repository, the line number corresponding to the incremental code; Determine the test coverage corresponding to the incremental code based on the line number corresponding to the incremental code and the test coverage file corresponding to the latest version of the target code repository.

5. The method according to claim 1, characterized in that The incremental code corresponding to the latest version of the target code repository is determined based on the Gerrit submission record of the target code repository.

6. The method according to claim 1, characterized in that The multiple test coverage files corresponding to the multiple test versions of the target code repository are generated in the following way: For any of the test versions of the target code repository, insert code that collects the execution status of each line of code during the compilation process to generate a target file corresponding to any of the test versions; Integrate and publish the target files corresponding to any of the test versions to the client; as well as Receive a test coverage file corresponding to any of the test versions generated by the client after the test is completed.

7. The method according to claim 1, characterized in that The hash value of the first basic block data in the test coverage file is determined according to the instruction segment and the line number range and file name of the source code corresponding to the instruction segment.

8. The method according to claim 1, characterized in that The hash value of the second basic block data in the code analysis file is determined according to the instruction segment and the line number range and file name of the source code corresponding to the instruction segment.

9. The method according to claim 1, characterized in that The method further includes: giving a corresponding warning when the test coverage corresponding to the incremental code is less than a preset threshold.

10. A device for determining incremental code test coverage, characterized in that: include: a memory configured to store instructions; and a processor configured to call the instructions from the memory and implement the method for determining incremental code test coverage according to any one of claims 1 to 9 when executing the instructions.

11. A processor, characterized in that: Used to run a program, wherein the program is used to execute when run: the method for determining incremental code test coverage according to any one of claims 1 to 9.

12. A computer program product, characterized in that It comprises a computer program, which, when executed by a processor, implements the method for determining incremental code test coverage as claimed in any one of claims 1 to 9.

Images