Test coverage data generation method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a test coverage data generation method and device, electronic equipment and storage medium; wherein, the method determines whether the test code file has code library and / or local modification through the code library version information corresponding to the two tests, the code library file version information of different test code files, and the local modification information, determines the integration mode of the coverage data generated by the two tests, and then integrates and reuses the coverage data generated by the two tests, so as to improve the test efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of testing technology, and in particular to a method, apparatus, electronic device, and storage medium for generating test coverage data. Background Technology

[0002] In application testing techniques, the coverage data generated during testing can be used to calculate code coverage. Code coverage is an important indicator for evaluating the quality of code testing. The higher the code coverage, the more code branches and code logic are run during testing, and the more comprehensive the test coverage.

[0003] Existing technologies typically require clearing old version test coverage data for different versions of code, and then retesting and generating new test coverage data based on the new version of code. This approach cannot reuse test coverage data generated by different versions. Whether it is local code modification or code repository modification, test coverage data cannot be compatible or reused between different versions of code, resulting in a waste of test resources and low test efficiency. Summary of the Invention

[0004] In view of this, the purpose of this disclosure is to provide a method, apparatus, electronic device and storage medium for generating test coverage data, so as to improve the accuracy and efficiency of test coverage data generation.

[0005] In a first aspect, embodiments of this disclosure provide a method for generating test coverage data. The method includes: acquiring first test data and second test data for at least one test code file, wherein the first test data is previous test data and the second test data is current test data; the test data includes at least code repository version information and coverage data of the test code file; acquiring first coverage data of the first test data and second coverage data of the second test data; the coverage data includes at least: test code line number information, test code modification information, and code repository file version information corresponding to the test code file; wherein the test code file is obtained from the code repository; the test code modification information includes at least: local modification status of the test code file and modification time; and generating test coverage data based on the first coverage data and second coverage data. The modification status of at least one test code file is determined by combining the code library file version information and test code modification information in the data, as well as the code library version information in the first test data and the second test data. The modification status of the test code file includes a first modification status and a second modification status, where the first modification status indicates whether the at least one test code file has been modified in the code library, and the second modification status indicates whether the test code file has been modified locally. Based on the modification status of the at least one test code file, the first coverage data and the second coverage data of the test code file are integrated to obtain the target coverage data of the at least one test code file. The target coverage data of each test code file is determined as the coverage data of each test code file in the second test data.

[0006] Secondly, embodiments of this disclosure provide a test coverage data generation apparatus, comprising: a first acquisition module, configured to acquire first test data and second test data of at least one test code file, wherein the first test data is previous test data and the second test data is current test data; the test data includes at least code repository version information and coverage data of the test code file; a second acquisition module, configured to acquire first coverage data of the first test data and second coverage data of the second test data; the coverage data includes at least: test code line number information, test code modification information, and code repository file version information corresponding to the test code file; wherein the test code file is acquired from the code repository; the test code modification information includes at least: local modification status of the test code file and modification time; a first determination module, configured to determine the test code file based on the first coverage data and the second test data. The modification status of at least one test code file is determined by combining the code library file version information and test code modification information in the second coverage data, as well as the code library version information in the first and second test data. The modification status of the test code file includes a first modification status and a second modification status, wherein the first modification status indicates whether the at least one test code file has been modified in the code library, and the second modification status indicates whether the test code file has been modified locally. A data integration module is used to integrate the first coverage data and the second coverage data of the test code file according to the modification status of the at least one test code file to obtain the target coverage data of the at least one test code file. A second determination module is used to determine the target coverage data of each test code file as the coverage data of each test code file in the second test data.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described method for generating test coverage data.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the above-described method for generating test coverage data.

[0009] The embodiments disclosed herein bring the following beneficial effects:

[0010] The aforementioned method, apparatus, electronic device, and storage medium for generating test coverage data acquire first test data and second test data for at least one test code file. The first test data is the previous test data, and the second test data is the current test data. The test data includes at least code repository version information and coverage data for the test code file. The method further acquires first coverage data of the first test data and second coverage data of the second test data. The coverage data includes at least: test code line number information, test code modification information, and code repository file version information corresponding to the test code file. The test code file is obtained from the code repository. The test code modification information includes at least: the local modification status of the test code file and the modification time. Based on the first and second coverage data... The modification status of at least one test code file is determined by using the codebase version information and test code modification information, as well as the codebase version information in the first and second test data. The modification status of the test code file includes a first modification status and a second modification status. The first modification status indicates whether the at least one test code file has been modified by the codebase, and the second modification status indicates whether the test code file has been modified locally. Based on the modification status of the at least one test code file, the first coverage data and the second coverage data of the test code file are integrated to obtain the target coverage data of the at least one test code file. The target coverage data of each test code file is determined as the coverage data of each test code file in the second test data. In this method, by using the codebase version information corresponding to two tests, the codebase version information of different test code files, and local modification information, it is determined whether the test code file has been modified by the codebase and / or locally, thereby determining the integration method of the coverage data generated by the two tests. This allows for the integration and reuse of the coverage data generated by the two tests, improving testing efficiency.

[0011] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0012] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0014] Figure 1 This is a flowchart of one embodiment of the test coverage data generation method in this disclosure;

[0015] Figure 2 A schematic diagram of a method for generating test coverage data provided in an embodiment of this disclosure;

[0016] Figure 3 A schematic diagram of a test coverage data generation apparatus provided in an embodiment of this disclosure;

[0017] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0019] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] For ease of understanding, the specific process of the embodiments of this disclosure is described below. Please refer to [link / reference]. Figure 1 One embodiment of the test coverage data generation method in this disclosure includes:

[0021] Step S10: Obtain first test data and second test data from at least one test code file. The first test data is the previous test data, and the second test data is the current test data. The test data includes at least code repository version information and test code file coverage data.

[0022] Understandably, programmers or testers, and other personnel with testing needs, can conduct code testing in batches according to specific requirements. Each time code testing is performed, code repository version information and test code file coverage data are collected to generate test data. Each generation of test data constitutes one test. The test data generated by two consecutive tests are the previous test data and the current test data.

[0023] It should be noted that during each test, at least one test code file is run to obtain the code repository version information and the coverage data of the test code file, resulting in either the first test data or the second test data. The code repository version information refers to the version information of the target code repository recorded locally, and the target code repository contains at least one test code file. It is understood that if the test code from the target code repository is not fetched locally between two tests, or if the test code from the target code repository can be changed, the code repository version information in the two test data will be the same. Conversely, if the test code from the target code repository is fetched locally, and the test code from the target code repository can be changed, the code repository version information in the two test data will be different.

[0024] Step S20: Obtain the first coverage data of the first test data and the second coverage data of the second test data; the coverage data includes at least: test code line number information, test code modification information, and code library file version information corresponding to the test code file; wherein the test code file is obtained from the code library; the test code modification information includes at least: the local modification status of the test code file and the modification time;

[0025] In this embodiment, the coverage data is used to indicate the running status of the test code file during testing. It includes at least the test code line number information, test code modification information, and the version information of the code library file corresponding to the test code file. It may also include information such as the test code file name or test code file path information used to identify the test code file.

[0026] It's important to note that the test code line number information refers to the line number in the test code file containing the test code being run during testing, such as lines 10-15 in test code file A. The library file version information corresponding to the test code file refers to the file version information of the test code file recorded locally in the target library. It's understandable that when any test code file in the target library is modified, the library version information will also change, for example, by incrementing sequentially. Therefore, the library file version information corresponding to the specifically modified test code file in the target library will also change accordingly, while the library file version information corresponding to the unmodified test code file will remain unchanged. Thus, the library file version information will always be less than or equal to the target library version information.

[0027] In this embodiment, the test code modification information includes at least the local modification status and modification time of the test code file. The local modification status refers to whether the test code file has been modified locally. The local modification status can be a flag bit. When a test code file is modified locally, the flag bit corresponding to the test code file is set to true. After each test data is generated, the flag bits corresponding to all test code files are cleared, that is, the flag bits corresponding to all test code files are set to false, in order to record the local modification status before or during the next test.

[0028] Understandably, the modification information of the test code file is used to indicate the time of the most recent local modification of the test code file. That is, every time the test code file is modified locally, the modification time is overwritten and recorded in the modification information of the test code file for comparison.

[0029] For example, during testing, the code is run to obtain information such as the file name (used to identify the test code file), line number, and last modified version number (i.e., code repository file version information) of the actual executed code. If the file is modified locally, the file's flag "dirty" (used to indicate local modification status) and the last local modification time "mod_time" can be set. The above information is combined to form the coverage data of a test code file. The coverage data of all test code files is collected, and the last modified version number of the local test code repository (i.e., code repository version information) is added to form a test dataset.

[0030] Step S30: Based on the code library file version information and test code modification information in the first coverage data and the second coverage data, as well as the code library version information in the first test data and the second test data, determine the modification status of at least one test code file; the modification status of the test code file includes a first modification status and a second modification status, the first modification status indicating whether there is a code library modification in at least one test code file, and the second modification status indicating whether there is a local modification in the test code file;

[0031] Understandably, based on the codebase file version information, the local modification status and modification time of the test code file, and the codebase version information in the two test data sets, it can be determined whether the test code file has been modified in the codebase (i.e., the first modification status) and whether it has been modified locally (i.e., the second modification status). Specifically, whether the codebase has been modified refers to whether the test code file in the target codebase has changed, and whether it has been modified locally refers to whether the test code file has changed locally, thus obtaining the modification status of at least one test code file.

[0032] Step S40: Based on the modification status of at least one test code file, integrate the first coverage data and the second coverage data of the test code file to obtain the target coverage data of at least one test code file;

[0033] In this embodiment, depending on the different modification states of the test code file, different integration methods / rules can be used to integrate the first and second coverage data of the test code file to obtain the target coverage data. It should be noted that integrating the first and second coverage data of the test code file actually integrates the test code line number information within the coverage data, making it possible to reuse the test code line number information recorded in the two tests.

[0034] It is understood that, based on the combination of the first modification state and the second modification state, the modification state includes: there is modification to the codebase but no local modification; there is modification to the codebase and local modification; there is no modification to the codebase but local modification; and there is no modification to the codebase and no local modification. In one implementation, different modification states can correspond to different preset integration methods / rules. By integrating the first coverage data and the second coverage data of the test code file using the preset integration method / rules corresponding to the modification state, the target coverage data of at least one test code file can be obtained.

[0035] Step S50: Determine the target coverage data of each test code file as the coverage data of each test code file of the second test data.

[0036] Understandably, once the integrated target coverage data is obtained, it can be identified as the coverage data of the test code files in the current test data. This data can be integrated with the coverage data generated in the next test, making it possible to reuse the coverage data generated in each test, without having to discard the coverage data recorded in the previous test in each test, thus avoiding the waste of test resources and improving test efficiency.

[0037] The aforementioned method, apparatus, electronic device, and storage medium for generating test coverage data determine whether test code files have been modified by using the code library version information corresponding to the two tests, the code library file version information of different test code files, and local modification information. This determines the integration method of the coverage data generated by the two tests, and then integrates and reuses the coverage data generated by the two tests, thereby improving testing efficiency.

[0038] The following section provides a detailed explanation of the different modification states of the test code file.

[0039] In one implementation, based on the code library file version information in the first coverage data and the second coverage data, and the code library version information in the first test data and the second test data, it is determined whether at least one test code file has been modified in the code library, thus obtaining a first modification state of at least one test file; based on the test code modification information in the first coverage data and the second coverage data, it is determined whether at least one test code file has been modified locally, thus obtaining a second modification state of at least one test file; combining the first modification state and the second modification state of at least one test file, the modification state of at least one test code file is obtained.

[0040] In this embodiment, based on the code repository version information corresponding to the test code files in the first and second coverage data, and the code repository version information in the first and second test data, it can be determined whether the test code files have been modified in the code repository. It is understood that in a collaborative development model, different development terminals can submit test code files to the target code repository, causing changes to the test code files in the target code repository. Different development terminals can also retrieve / fetch test code files from the target code repository, thereby synchronizing code modifications made by other development terminals.

[0041] For example, when any development terminal submits at least one test code file to the target code repository, the test code file changes within the target code repository, and the repository version information also changes accordingly, for example, by adding 1 to the original version number. The repository version information corresponding to the test code file submitted by that development terminal remains consistent with the latest repository version information, while the repository version information for test code files other than those submitted by that development terminal remains unchanged. In one implementation, by determining whether the repository version information corresponding to the test code file is the same as the repository version information, it can be determined whether the test code file has been modified in the repository, thus obtaining the first modified state of the test file.

[0042] Furthermore, in one embodiment, based on the code library version information in the first test data and the second test data, it is determined whether the versions of the code libraries are the same; if the versions of the code libraries are the same, it is determined that at least one test code file has not been modified by the code library, and a first modification state of at least one test file is obtained; if the versions of the code libraries are different, based on the code library file version information in the first coverage data and the second coverage data, it is determined whether at least one test code file has been modified by the code library, and a first modification state of at least one test file is obtained.

[0043] In this implementation, it is first determined whether the code library version information in the two / two test data sets (i.e., the first test data and the second test data) is the same. If they are the same, it means that the two tests are based on test code files of the same code library version. Possible reasons include: the test code file targeted by the current test data does not pull the test code file of the target code library based on the test code file targeted by the previous test data, or the test code file of the target code library is pulled but the test code file of the target code library is not modified. That is, during the two tests, the end point of collaborative development did not submit a new test code file to the target code library. Therefore, as long as the code library version information is the same, it can be determined that there are no modifications to the code library in all test code files.

[0044] In another scenario, if the codebase version information differs, it's necessary to further determine whether any codebase modifications exist for each test code file. Specifically, based on the coverage data in the two test datasets, it's determined whether the codebase file version information is the same in the two coverage datasets. For cases where the version information increments sequentially, if the codebase file version information corresponding to the test code file in the second coverage dataset is greater than the codebase file version information corresponding to the same test code file in the first coverage dataset, then it's determined that the test code file has undergone codebase modifications. Conversely, if the codebase file version information corresponding to the test code file in the second coverage dataset is less than or equal to the codebase file version information corresponding to the same test code file in the first coverage dataset, then it's determined that the test code file has not undergone codebase modifications.

[0045] On the other hand, in one embodiment of determining whether a test code file has been locally modified, the local modification status in the test code modification information is used to indicate whether the test code file has been locally modified; the modification time in the test code modification information is used to indicate the time of the local modification; when determining whether at least one test code file has been locally modified based on the test code modification information in the first coverage data and the second coverage data, and obtaining the second modification status of at least one test file, if the local modification status of the test code file in the first coverage data and / or the second coverage data indicates that the test code file has been locally modified, and the time of the local modification of the test code file in the second coverage data is later than the time of the local modification of the test code file in the first coverage data, then it is determined that the test code file has been locally modified, and the second modification status of at least one test file is obtained.

[0046] In this implementation, the local modification status of each test code file is recorded by the local modification status in the test code modification information, and the most recent local modification time of the test code file is recorded by the modification time in the test code modification information. It should be noted that any local modification to any test code file after one test data generation and before another test data generation is considered a local modification of that test code file. The terminal can pull test code files from the target code library before, during, or after local modification. The local modification status in the test code modification information is used to record the local modification status of a test data.

[0047] In one implementation, if the local modification status of the test code file in either of the two test data sets indicates that the test code file has been locally modified, then it can be determined that the test code file has been locally modified. If the local modification status of the test code file in both test data sets indicates that the test code file has been locally modified, then if the local modification time of the test code file in the second coverage data is later than the local modification time of the test code file in the first coverage data, it is determined that the test code file has been locally modified. Conversely, if the local modification time of the test code file in the second coverage data is earlier than or equal to the local modification time of the test code file in the first coverage data, it is determined that the test code file has not been locally modified, thereby obtaining the second modification status of the test code file.

[0048] Next, the specific integration method of the coverage data will be explained.

[0049] In one implementation, based on the modification status of at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data are determined; the second coverage data of the second code file is determined as the target coverage data of the second code file; and the target coverage data of the first code file is generated based on the first coverage data and the second coverage data of the first code file.

[0050] In this embodiment, based on the different modification states of the test code files, all test code files can be divided into first code files with valid first coverage data and second code files with invalid first coverage data. For second code files with invalid first coverage data, that is, test code files whose line number information generated in the previous test cannot be reused, the first coverage data of the second code file is directly discarded, and the coverage data in the current test data (i.e., the second coverage data) is used as the target coverage data of the second code file. For first code files with valid first coverage data, that is, test code files whose line number information generated in the previous test can be reused, the first coverage data and the second coverage data of the first code file are integrated according to the preset integration rules to obtain the target coverage data of the first code file.

[0051] In one implementation, test code files that have neither codebase modifications nor local modifications can be identified as first code files with valid first coverage data, while other test code files can be identified as second code files with invalid first coverage data. Alternatively, test code files that have no codebase modifications can be identified as first code files with valid first coverage data, while other test code files can be identified as second code files with invalid first coverage data. Another approach is to identify test code files that have no local modifications as first code files with valid first coverage data, while other test code files can be identified as second code files with invalid first coverage data, depending on the specific implementation.

[0052] In one implementation, if the second modification status of the test code file indicates that the test code file has been modified locally, then the test code file is determined to be a second code file with invalid first coverage data; if the second modification status of the test code file indicates that the test code file has not been modified locally, then the test code file is determined to be a first code file with valid first coverage data.

[0053] Understandably, in order to make the integrated coverage data easier for other development terminals to use, any test code file that has undergone local modification is considered a second code file with invalid first coverage data, and the first coverage data is discarded. On the other hand, test code files that have not undergone local modification are considered first code files with valid first coverage data, and the first coverage data can be integrated with the second coverage data and reused.

[0054] In one implementation, if the first modification status of the first code file indicates that there is no modification to the code library, then the first coverage data and the second coverage data of the first code file are merged to obtain the target coverage data corresponding to the first code file; if the first modification status of the first code file indicates that there is modification to the code library, then based on the difference between the first test data and the second test data, the first coverage data of the first code file is converted to the second coverage data of the first code file to obtain the target coverage data of the first code file.

[0055] In this embodiment, for test code files whose first coverage data is valid and have no codebase modifications, the test code line number information in the first and second coverage data of the test code file can be directly merged to obtain the target coverage data corresponding to the test code file. Specifically, a test code file whose first coverage data is valid and has no codebase modifications refers to a test code file that has neither local modifications nor codebase modifications. Since the test code file is identical in both tests, the coverage data can be directly merged and reused, greatly improving testing efficiency.

[0056] Furthermore, for a first code file where the first coverage data is valid but the codebase has been modified, coverage data with the same lines of code can be reused, while coverage data with different lines of code can be discarded, thereby obtaining the integrated target coverage data. Specifically, in one implementation, if the modification status of the first code file indicates that the first code file has been modified by the codebase, then based on the test code line number information in the coverage data, the mapping relationship of the same lines of code in the first and second test data of the first code file is obtained through a version control tool, and the different lines of code are identified; according to the mapping relationship, the coverage data with different lines of code in the first coverage data of the first code file is discarded, and the coverage data with the same lines of code in the first coverage data of the first code file is converted to the second coverage data of the first code file to obtain the target coverage data of the first code file.

[0057] As an example, and not a limitation, version control tools can include Subversion (SVN), the distributed version control system Git, etc. SVN's diff interface allows you to obtain the mapping relationship between the locations of the same line of code in different code files. For example... Figure 2 The diagram shows the mapping of identical lines of code between an old version (the version tested in the previous test) and a new version (the version tested in the current test) of a .txt file obtained through the diff interface. Figure 2 In this context, "@@-6,7+6,6@@" means that the 7 lines starting from line 6 of the old version file (i.e., lines 6-12) are changed to the 6 lines starting from line 6 of the new version file (i.e., lines 6-11). "@@-23,6+22,7@@" works in the same way.

[0058] Based on the above mapping relationship, the line numbers of the same code line in the new version of the .txt file are "1-5, 12-21, 30-last line". Therefore, apart from the same code line, the rest are different code lines. For the same code line, the coverage data of the same code line in the first coverage data can be converted to the second coverage data. For different code lines, the coverage data of different code lines in the second coverage data can be discarded, thus obtaining the target coverage data.

[0059] The following section provides a comprehensive explanation of the different modification states of the test code files and the specific integration methods for the overlay data.

[0060] For the new batch of test data (i.e., the second batch of test data), if the last modified version number of the codebase (i.e., the codebase version information) is continuously increasing, then if the last modified version number of the new test data (i.e., the second batch of test data) is smaller than that of the old test data (i.e., the first batch of test data), the test operation is considered erroneous and no action is taken. If the last modified version number of the new test data is equal to that of the old test data, it is necessary to determine whether the test code file has been modified locally. For each test code file, based on whether local modifications exist, it is determined whether the old overlay data (i.e., the first overlay data) is valid. The new overlay data (i.e., the second overlay data) and the old overlay data that meet the conditions are merged. The rules for determining whether local modifications exist are as follows:

[0061] The old overwritten data dirty is: old_dirty, the new overwritten data dirty is: new_dirty, the old overwritten data modification time mod_time is: old_mod_time, and the new overwritten data modification time mod_time is: new_mod_time;

[0062] (1) If old_dirty and new_dirty of the test code file are true and new_mod_time is greater than old_mod_time, it means that the test code file has been modified locally and the old overwritten data is invalid; otherwise, it is considered that the test code file has not been modified locally and the old overwritten data is valid.

[0063] (2) If old_dirty is true and new_dirty is false, it means that the test code file has been modified locally and the old overwritten data is invalid.

[0064] (3) If old_dirty is false and new_dirty is true, it means that the test code file has been modified locally and the old overwritten data is invalid;

[0065] (4) If both old_dirty and new_dirty are false, it means that the test code file has not been modified and the old overwritten data is valid.

[0066] The rules for merging overlay data are as follows:

[0067] If the row number information of the old overlay data has expired and cannot be used, the old overlay data will be cleared and only the new overlay data will be retained; if the row number information of the old overlay data is valid, the row number information of the new overlay data will be recorded based on the old overlay data to merge the old overlay data and the new overlay data to obtain the target overlay data.

[0068] On the other hand, if the last modified version number of the codebase for the new test data is greater than that of the old test data, then the line number information in the old overwritten data needs to be corrected first, based on whether there are local modifications to the files, before merging the overwritten data, according to the following rules:

[0069] The last modified version number (i.e., the code library file version information) of the test code file in the old overwrite data is recorded as old_version, and the last modified version number of the test code file in the new overwrite data is recorded as new_version;

[0070] (1) If new_version is less than old_version, the overwritten data is considered to be incorrect and no action is taken;

[0071] (2) If new_version equals old_version, it is assumed that the test code file has no code library modification. Using the above rules for judging whether there is local modification, the validity of the old overlay data is determined based on whether there is local modification. Then, the new overlay data (i.e. the second overlay data) and the old overlay data that meet the conditions are merged using the above rules for merging overlay data.

[0072] (3) If new_version is greater than old_version, it is assumed that the test code file has been modified in the codebase. Next, we will discuss whether the line number information in the old overwrite data can be converted into the line number information in the new overwrite data, and how to do so:

[0073] a. If old_dirty is true, it means that the old overwritten data has been modified locally. In this case, the row number information in the old overwritten data cannot be converted. The old overwritten data will be cleared, and only the new overwritten data will be kept.

[0074] b. If old_dirty is false and new_dirty is true, it means that the newly overwritten data has been modified locally, making data merging impossible. In this case, the old overwritten data is cleared, and only the new overwritten data is kept.

[0075] c. If both `old_dirty` and `new_dirty` are false, it means that there are no local modifications to the newly overwritten data. In this case, the line count information in the old overwritten data is converted before being merged with the new overwritten data. Specifically, the version control tool obtains the mapping relationship between identical lines of code in the old and new overwritten data and identifies the dissimilar lines of code. Based on the mapping relationship, the line count information of identical lines of code in the old overwritten data is converted to the corresponding line count information in the new overwritten data and then merged into the new overwritten data. Overwritten data with dissimilar lines of code in the old overwritten data is discarded.

[0076] After the above processing, the new test data is merged and processed, which can retain the previous test results to the greatest extent. After the next test, the above process can be repeated.

[0077] For the corresponding method embodiments described above, see [link to relevant documentation]. Figure 3 The diagram illustrates a test coverage data generation device, which includes: a first acquisition module 31, configured to acquire first test data and second test data of at least one test code file, wherein the first test data is previous test data and the second test data is current test data; the test data includes at least code library version information and coverage data of the test code file; a second acquisition module 32, configured to acquire first coverage data of the first test data and second coverage data of the second test data; the coverage data includes at least: test code line number information, test code modification information, and code library file version information corresponding to the test code file; wherein the test code file is acquired from the code library; the test code modification information includes at least: local modification status of the test code file and modification time; and a first determination module 33, configured to determine the test code file based on the first coverage data and the second test data. The modification status of at least one test code file is determined by combining the code library file version information and test code modification information in the coverage data, as well as the code library version information in the first test data and the second test data. The modification status of the test code file includes a first modification status and a second modification status, where the first modification status indicates whether the at least one test code file has been modified in the code library, and the second modification status indicates whether the test code file has been modified locally. The data integration module 34 is used to integrate the first coverage data and the second coverage data of the test code file according to the modification status of the at least one test code file to obtain the target coverage data of the at least one test code file. The second determination module 35 is used to determine the target coverage data of each test code file as the coverage data of each test code file in the second test data.

[0078] In this device, the existence of code library and / or local modifications in the test code file is determined by the code library version information corresponding to the two tests, the code library file version information of different test code files, and local modification information. This determines the integration method of the coverage data generated by the two tests, and then integrates and reuses the coverage data generated by the two tests, thereby improving testing efficiency.

[0079] Optionally, the first determining module 33 includes: a first determining unit, configured to determine whether the at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, and the code library version information in the first test data and the second test data, to obtain a first modification status of the at least one test file; a second determining unit, configured to determine whether the at least one test code file has been modified locally based on the test code modification information in the first coverage data and the second coverage data, to obtain a second modification status of the at least one test file; and a data combining unit, configured to combine the first modification status and the second modification status of the at least one test file to obtain the modification status of the at least one test code file.

[0080] Optionally, the first determining unit is specifically used to: determine whether the versions of the code libraries are the same based on the code library version information in the first test data and the second test data; if the versions of the code libraries are the same, determine that the at least one test code file has not been modified by the code library, and obtain a first modification status of the at least one test file; if the versions of the code libraries are different, determine whether the at least one test code file has been modified by the code library based on the code library file version information in the first coverage data and the second coverage data, and obtain a first modification status of the at least one test file.

[0081] Optionally, the local modification status in the test code modification information is used to indicate whether the test code file has been locally modified; the modification time in the test code modification information is used to indicate the time of the local modification; the second determining unit is specifically used to: if the local modification status of the test code file in the first coverage data and / or the second coverage data indicates that the test code file has been locally modified, and the time of the local modification of the test code file in the second coverage data is later than the time of the local modification of the test code file in the first coverage data, then it is determined that the test code file has been locally modified, and the second modification status of the at least one test file is obtained.

[0082] Optionally, the data integration module 34 includes: a third determining unit, configured to determine, based on the modification status of the at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data; a fourth determining unit, configured to determine the second coverage data of the second code file as the target coverage data of the second code file; and a data generating unit, configured to generate the target coverage data of the first code file based on the first coverage data and the second coverage data of the first code file.

[0083] Optionally, the third determining unit is specifically used to: if the second modification status of the test code file indicates that the test code file has local modifications, then determine the test code file as a second code file with invalid first coverage data; if the second modification status of the test code file indicates that the test code file has no local modifications, then determine the test code file as a first code file with valid first coverage data.

[0084] Optionally, the data generation unit includes: a merging subunit, configured to merge the first coverage data and the second coverage data of the first code file to obtain target coverage data corresponding to the first code file if the first modification status of the first code file indicates that the first code file has no code library modification; and a conversion subunit, configured to convert the first coverage data of the first code file to the second coverage data of the first code file according to the difference between the first test data and the second test data, to obtain target coverage data of the first code file if the first modification status of the first code file indicates that the first code file has code library modification.

[0085] Optionally, the above conversion subunit is specifically used for: if the modification status of the first code file indicates that the first code file has been modified by the code library, then based on the test code line number information in the coverage data, obtaining the mapping relationship of the same code lines in the first test data and the second test data of the first code file through a version control tool, and determining the different code lines; according to the mapping relationship, discarding the coverage data of the different code lines in the first coverage data of the first code file, and converting the coverage data of the same code lines in the first coverage data of the first code file to the second coverage data of the first code file to obtain the target coverage data of the first code file.

[0086] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the above-described method for generating test coverage data. This electronic device can be a server or a terminal device.

[0087] See Figure 4 As shown, the electronic device includes a processor 400 and a memory 401. The memory 401 stores machine-executable instructions that can be executed by the processor 400. The processor 400 executes the machine-executable instructions to implement the above-described method for generating test coverage data.

[0088] Furthermore, Figure 4The electronic device shown also includes a bus 402 and a communication interface 403. The processor 400, the communication interface 403 and the memory 401 are connected via the bus 402.

[0089] The memory 401 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 403 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 402 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0090] The processor 400 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 400 or by instructions in software form. The processor 400 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 401. The processor 400 reads information from memory 401 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments, for example:

[0091] Obtain first test data and second test data for at least one test code file, where the first test data is the previous test data and the second test data is the current test data. The test data includes at least codebase version information and test code file coverage data. Obtain first coverage data for the first test data and second coverage data for the second test data. The coverage data includes at least: test code line number information, test code modification information, and codebase file version information corresponding to the test code file. The test code file is obtained from the codebase. The test code modification information includes at least: the local modification status of the test code file and the modification time. Based on the codebase file version information and test code modification information in the first and second coverage data, and the codebase version information in the first and second test data, determine the modification status of at least one test code file. The modification status of the test code file includes a first modification status and a second modification status. The first modification status indicates whether the at least one test code file has been modified in the codebase, and the second modification status indicates whether the test code file has been modified locally. Based on the modification status of at least one test code file, integrate the first coverage data and the second coverage data of the test code file to obtain target coverage data for at least one test code file. Determine the target coverage data of each test code file as the coverage data of each test code file in the second test data.

[0092] In this approach, the presence of codebase and / or local modifications in the test code files is determined by the codebase version information corresponding to the two tests, the codebase file version information of different test code files, and local modification information. This determines the integration method of the coverage data generated by the two tests, and then integrates and reuses the coverage data generated by the two tests, thereby improving testing efficiency.

[0093] Optionally, the step of determining the modification status of at least one test code file based on the code library file version information and test code modification information in the first coverage data and the second coverage data, as well as the code library version information in the first test data and the second test data, includes: determining whether at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, to obtain a first modification status of at least one test file; determining whether at least one test code file has been modified locally based on the test code modification information in the first coverage data and the second coverage data, to obtain a second modification status of at least one test file; and combining the first modification status and the second modification status of at least one test file to obtain the modification status of at least one test code file.

[0094] Optionally, the step of determining whether at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, and the code library version information in the first test data and the second test data, and obtaining a first modification state of at least one test file, includes: determining whether the versions of the code libraries are the same based on the code library version information in the first test data and the second test data; if the versions of the code libraries are the same, determining that at least one test code file has not been modified in the code library, and obtaining a first modification state of at least one test file; if the versions of the code libraries are different, determining whether at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, and obtaining a first modification state of at least one test file.

[0095] Optionally, the local modification status in the test code modification information is used to indicate whether the test code file has been locally modified; the modification time in the test code modification information is used to indicate the time of the local modification; the step of determining whether at least one test code file has been locally modified based on the test code modification information in the first coverage data and the second coverage data, and obtaining the second modification status of at least one test file, includes: if the local modification status of the test code file in the first coverage data and / or the second coverage data indicates that the test code file has been locally modified, and the time of the local modification of the test code file in the second coverage data is later than the time of the local modification of the test code file in the first coverage data, then it is determined that the test code file has been locally modified, and the second modification status of at least one test file is obtained.

[0096] Optionally, the step of integrating the first coverage data and the second coverage data of the test code files to obtain the target coverage data of the at least one test code file based on the modification status of the at least one test code file includes: determining, based on the modification status of the at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data; determining the second coverage data of the second code file as the target coverage data of the second code file; and generating the target coverage data of the first code file based on the first coverage data and the second coverage data of the first code file.

[0097] Optionally, the step of determining a first code file with valid first coverage data and a second code file with invalid first coverage data based on the modification status of at least one test code file includes: if the second modification status of the test code file indicates that the test code file has local modifications, then the test code file is determined to be a second code file with invalid first coverage data; if the second modification status of the test code file indicates that the test code file has no local modifications, then the test code file is determined to be a first code file with valid first coverage data.

[0098] Optionally, the step of generating target coverage data for the first code file based on the first coverage data and the second coverage data of the first code file includes: if the first modification status of the first code file indicates that there is no modification to the code library, then the first coverage data and the second coverage data of the first code file are merged to obtain the target coverage data corresponding to the first code file; if the first modification status of the first code file indicates that there is modification to the code library, then the first coverage data of the first code file is converted to the second coverage data of the first code file based on the difference between the first test data and the second test data to obtain the target coverage data of the first code file.

[0099] Optionally, if the first modification status of the first code file indicates that the first code file has been modified by the codebase, then the step of converting the first coverage data of the first code file to the second coverage data of the first code file according to the differences between the first test data and the second test data to obtain the target coverage data of the first code file includes: if the modification status of the first code file indicates that the first code file has been modified by the codebase, then based on the test code line number information in the coverage data, obtaining the mapping relationship of the same code lines in the first test data and the second test data of the first code file through a version control tool, and identifying the different code lines; according to the mapping relationship, discarding the coverage data of the different code lines in the first coverage data of the first code file, and converting the coverage data of the same code lines in the first coverage data of the first code file to the second coverage data of the first code file to obtain the target coverage data of the first code file.

[0100] This embodiment also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned method for generating test coverage data. For example:

[0101] Obtain first test data and second test data for at least one test code file, where the first test data is the previous test data and the second test data is the current test data. The test data includes at least codebase version information and test code file coverage data. Obtain first coverage data for the first test data and second coverage data for the second test data. The coverage data includes at least: test code line number information, test code modification information, and codebase file version information corresponding to the test code file. The test code file is obtained from the codebase. The test code modification information includes at least: the local modification status of the test code file and the modification time. Based on the codebase file version information and test code modification information in the first and second coverage data, and the codebase version information in the first and second test data, determine the modification status of at least one test code file. The modification status of the test code file includes a first modification status and a second modification status. The first modification status indicates whether the at least one test code file has been modified in the codebase, and the second modification status indicates whether the test code file has been modified locally. Based on the modification status of at least one test code file, integrate the first coverage data and the second coverage data of the test code file to obtain target coverage data for at least one test code file. Determine the target coverage data of each test code file as the coverage data of each test code file in the second test data.

[0102] In this approach, the presence of codebase and / or local modifications in the test code files is determined by the codebase version information corresponding to the two tests, the codebase file version information of different test code files, and local modification information. This determines the integration method of the coverage data generated by the two tests, and then integrates and reuses the coverage data generated by the two tests, thereby improving testing efficiency.

[0103] Optionally, the step of determining the modification status of at least one test code file based on the code library file version information and test code modification information in the first coverage data and the second coverage data, as well as the code library version information in the first test data and the second test data, includes: determining whether at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, to obtain a first modification status of at least one test file; determining whether at least one test code file has been modified locally based on the test code modification information in the first coverage data and the second coverage data, to obtain a second modification status of at least one test file; and combining the first modification status and the second modification status of at least one test file to obtain the modification status of at least one test code file.

[0104] Optionally, the step of determining whether at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, and the code library version information in the first test data and the second test data, and obtaining a first modification state of at least one test file, includes: determining whether the versions of the code libraries are the same based on the code library version information in the first test data and the second test data; if the versions of the code libraries are the same, determining that at least one test code file has not been modified in the code library, and obtaining a first modification state of at least one test file; if the versions of the code libraries are different, determining whether at least one test code file has been modified in the code library based on the code library file version information in the first coverage data and the second coverage data, and obtaining a first modification state of at least one test file.

[0105] Optionally, the local modification status in the test code modification information is used to indicate whether the test code file has been locally modified; the modification time in the test code modification information is used to indicate the time of the local modification; the step of determining whether at least one test code file has been locally modified based on the test code modification information in the first coverage data and the second coverage data, and obtaining the second modification status of at least one test file, includes: if the local modification status of the test code file in the first coverage data and / or the second coverage data indicates that the test code file has been locally modified, and the time of the local modification of the test code file in the second coverage data is later than the time of the local modification of the test code file in the first coverage data, then it is determined that the test code file has been locally modified, and the second modification status of at least one test file is obtained.

[0106] Optionally, the step of integrating the first coverage data and the second coverage data of the test code files to obtain the target coverage data of the at least one test code file based on the modification status of the at least one test code file includes: determining, based on the modification status of the at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data; determining the second coverage data of the second code file as the target coverage data of the second code file; and generating the target coverage data of the first code file based on the first coverage data and the second coverage data of the first code file.

[0107] Optionally, the step of determining a first code file with valid first coverage data and a second code file with invalid first coverage data based on the modification status of at least one test code file includes: if the second modification status of the test code file indicates that the test code file has local modifications, then the test code file is determined to be a second code file with invalid first coverage data; if the second modification status of the test code file indicates that the test code file has no local modifications, then the test code file is determined to be a first code file with valid first coverage data.

[0108] Optionally, the step of generating target coverage data for the first code file based on the first coverage data and the second coverage data of the first code file includes: if the first modification status of the first code file indicates that there is no modification to the code library, then the first coverage data and the second coverage data of the first code file are merged to obtain the target coverage data corresponding to the first code file; if the first modification status of the first code file indicates that there is modification to the code library, then the first coverage data of the first code file is converted to the second coverage data of the first code file based on the difference between the first test data and the second test data to obtain the target coverage data of the first code file.

[0109] Optionally, if the first modification status of the first code file indicates that the first code file has been modified by the codebase, then the step of converting the first coverage data of the first code file to the second coverage data of the first code file according to the differences between the first test data and the second test data to obtain the target coverage data of the first code file includes: if the modification status of the first code file indicates that the first code file has been modified by the codebase, then based on the test code line number information in the coverage data, obtaining the mapping relationship of the same code lines in the first test data and the second test data of the first code file through a version control tool, and identifying the different code lines; according to the mapping relationship, discarding the coverage data of the different code lines in the first coverage data of the first code file, and converting the coverage data of the same code lines in the first coverage data of the first code file to the second coverage data of the first code file to obtain the target coverage data of the first code file.

[0110] The computer program product of the test coverage data generation method, apparatus, electronic device and storage medium provided in the embodiments of this disclosure includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0112] Furthermore, in the description of the embodiments of this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure based on the specific circumstances.

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

[0114] In the description of this disclosure, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0115] Finally, it should be noted that the above embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for generating test coverage data, characterized in that, The method includes: Obtain first test data and second test data from at least one test code file, wherein the first test data is the previous test data and the second test data is the current test data; the test data includes at least code repository version information and test code file coverage data; Obtain first coverage data of the first test data and second coverage data of the second test data; the coverage data includes at least: test code line number information, test code modification information, and code library file version information corresponding to the test code file; wherein the test code file is obtained from the code library; the test code modification information includes at least: the local modification status of the test code file and the modification time; Based on the code library file version information and test code modification information in the first and second coverage data, as well as the code library version information in the first and second test data, determine the modification status of the at least one test code file. The modification status of the test code file includes a first modification status and a second modification status. The first modification status indicates whether the at least one test code file has been modified in the code library, and the second modification status indicates whether the test code file has been modified locally. Based on the modification status of the at least one test code file, the first coverage data and the second coverage data of the test code file are integrated to obtain the target coverage data of the at least one test code file; The target coverage data for each test code file is determined as the coverage data for each test code file of the second test data; The step of integrating the first coverage data and the second coverage data of the at least one test code file to obtain the target coverage data of the at least one test code file based on the modification status of the at least one test code file includes: Based on the modification status of the at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data are determined among the at least one test code file; The second coverage data of the second code file is determined as the target coverage data of the second code file; Based on the first coverage data and the second coverage data of the first code file, the target coverage data of the first code file is generated.

2. The method according to claim 1, characterized in that, The step of determining the modification status of the at least one test code file based on the code library file version information and test code modification information in the first and second coverage data, and the code library version information in the first and second test data, includes: Based on the code library file version information in the first coverage data and the second coverage data, as well as the code library version information in the first test data and the second test data, it is determined whether the at least one test code file has been modified in the code library, and the first modification status of the at least one test file is obtained. Based on the test code modification information in the first coverage data and the second coverage data, determine whether the at least one test code file has been locally modified, and obtain the second modification status of the at least one test file; The modification status of the at least one test code file is obtained by combining the first modification status and the second modification status of the at least one test file.

3. The method according to claim 2, characterized in that, The step of determining whether the at least one test code file has been modified based on the code library file version information in the first coverage data and the second coverage data, and the code library version information in the first test data and the second test data, and obtaining the first modification status of the at least one test file, includes: Based on the code library version information in the first test data and the second test data, determine whether the versions of the code library are the same; If the versions of the code libraries are the same, it is determined that the at least one test code file has not been modified by the code library, and the first modification status of the at least one test file is obtained; If the versions of the code library are different, the code library file version information in the first coverage data and the second coverage data is used to determine whether the at least one test code file has been modified by the code library, and the first modification status of the at least one test file is obtained.

4. The method according to claim 2, characterized in that, The local modification status in the test code modification information is used to indicate whether the test code file has been modified locally; the modification time in the test code modification information indicates the time of the local modification. The step of determining whether the at least one test code file has been locally modified based on the test code modification information in the first coverage data and the second coverage data, and obtaining the second modification status of the at least one test file, includes: If the local modification status of the test code file in the first coverage data and / or the second coverage data indicates that the test code file has been locally modified, and the time of the local modification of the test code file in the second coverage data is later than the time of the local modification of the test code file in the first coverage data, then it is determined that the test code file has been locally modified, and the second modification status of the at least one test file is obtained.

5. The method according to claim 1, characterized in that, The step of determining, based on the modification status of the at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data, includes: If the second modification status of the test code file indicates that the test code file has been modified locally, then the test code file is determined to be a second code file with invalid first overwrite data; If the second modification status of the test code file indicates that there are no local modifications to the test code file, then the test code file is determined as the first code file with valid first coverage data.

6. The method according to claim 1, characterized in that, The step of generating target coverage data for the first code file based on the first coverage data and the second coverage data of the first code file includes: If the first modification status of the first code file indicates that there is no modification to the code library, then the first overlay data and the second overlay data of the first code file are merged to obtain the target overlay data corresponding to the first code file. If the first modification status of the first code file indicates that the first code file has been modified in the code library, then based on the differences between the first code file in the first test data and the second test data, the first coverage data of the first code file is converted to the second coverage data of the first code file to obtain the target coverage data of the first code file.

7. The method according to claim 6, characterized in that, If the first modification status of the first code file indicates that the first code file has been modified in the code library, then the step of converting the first coverage data of the first code file to the second coverage data of the first code file according to the differences between the first test data and the second test data to obtain the target coverage data of the first code file includes: If the modification status of the first code file indicates that the first code file has been modified by the code library, then based on the test code line number information in the coverage data, the version control tool is used to obtain the mapping relationship of the same code lines in the first test data and the second test data of the first code file, and to determine the different code lines. According to the mapping relationship, the coverage data of different lines of code in the first coverage data of the first code file are discarded, and the coverage data of the same lines of code in the first coverage data of the first code file are converted to the second coverage data of the first code file to obtain the target coverage data of the first code file.

8. A device for generating test coverage data, characterized in that, The device includes: The first acquisition module is used to acquire first test data and second test data of at least one test code file, wherein the first test data is the previous test data and the second test data is the current test data; the test data includes at least code library version information and coverage data of the test code file. The second acquisition module is used to acquire first coverage data of the first test data and second coverage data of the second test data; the coverage data includes at least: test code line number information, test code modification information, and code library file version information corresponding to the test code file; wherein the test code file is acquired from the code library; the test code modification information includes at least: the local modification status of the test code file and the modification time; The first determining module is used to determine the modification status of the at least one test code file based on the code library file version information and test code modification information in the first coverage data and the second coverage data, as well as the code library version information in the first test data and the second test data; the modification status of the test code file includes a first modification status and a second modification status, wherein the first modification status indicates whether the at least one test code file has been modified in the code library, and the second modification status indicates whether the test code file has been modified locally. The data integration module is used to integrate the first coverage data and the second coverage data of the test code files according to the modification status of the at least one test code file to obtain the target coverage data of the at least one test code file. The second determining module is used to determine the target coverage data of each test code file as the coverage data of each test code file of the second test data; The data integration module includes: The third determining unit is used to determine, based on the modification status of the at least one test code file, a first code file with valid first coverage data and a second code file with invalid first coverage data; The fourth determining unit is used to determine the second coverage data of the second code file as the target coverage data of the second code file; The data generation unit is configured to generate target coverage data for the first code file based on the first coverage data and the second coverage data of the first code file.

9. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the test coverage data generation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the method for generating test coverage data according to any one of claims 1-7.

Images