Code coverage rate determination method, electronic equipment, communication system and readable storage medium

Abstract

The invention provides a code coverage rate determination method, electronic equipment, a communication system and a readable storage medium, and the method comprises the steps: recording difference information between a new-version file and an old-version file, inserting at least one test probe in each to-be-tested paragraph of the new-version file and the old-version file, and recording an identifier of the test probe, and determining runtime data of the new-version file and runtime data of the old-version file based on the inserted test probe, fusing the runtime data of the new-version file and the runtime data of the old-version file based on the difference information and the identifier of the test probe, and determining the running coverage rate of the new-version file. According to the method, the runtime data of different versions can be fused, the dependence of test work on the versions is eliminated, the combination of the runtime data of early-stage full-quantity test is supported to obtain a more comprehensive coverage rate, the test efficiency can be effectively improved, the accuracy of a test result is improved, and the flexibility of making a test plan is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for determining code coverage, an electronic device, a communication system, and a readable storage medium. Background Art

[0002] In related technologies, full testing is usually performed at certain important nodes of the project. After the test is completed, the runtime data of the full test is obtained, and then the overall operation coverage of the code is calculated. After the full test, the software version will continue to iterate and evolve due to various reasons. For each new version, it may no longer be possible to perform full testing. You can only select some relevant test cases for the modified code and perform incremental testing.

[0003] Because existing code coverage determination tools do not support the fusion of runtime data between different versions, it is impossible to calculate the overall coverage of the project code based on the early full test data and subsequent scattered incremental test data at the end of the project. Summary of the invention

[0004] The present application aims to solve one of the technical problems in the related art at least to some extent.

[0005] To this end, the following technical solutions are proposed:

[0006] The first embodiment of the present application provides a method for determining code coverage, the method comprising:

[0007] Get the difference information between the new version file and the old version file;

[0008] Inserting at least one test probe into each to-be-tested paragraph of the new version file and the old version file;

[0009] Recording the identification of the test probe inserted into each to-be-tested paragraph of the new version file and the old version file;

[0010] Running the new version file and the old version file based on the inserted test probe to determine runtime data of the new version file and runtime data of the old version file;

[0011] Based on the difference information and the identifier of the test probe, the runtime data of the new version file and the runtime data of the old version file are merged to determine the operation coverage of the new version file.

[0012] Optionally, the fusing the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identifier of the test probe to determine the operation coverage of the new version file includes:

[0013] In response to matching the to-be-tested section of the new version file in the difference information, the running coverage of the new version file is determined based on the runtime data of the to-be-tested section of the new version file.

[0014] Optionally, the fusing the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identifier of the test probe to determine the operation coverage of the new version file includes:

[0015] In response to not matching the paragraph to be tested of the new version file in the difference information, merging the runtime data of the paragraph to be tested of the new version file with the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file;

[0016] Based on the merged runtime data, the runtime coverage of the new version file is determined.

[0017] Optionally, the merging of the runtime data of the paragraph to be tested of the new version file and the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file comprises:

[0018] A logical OR operation is performed on the runtime data of the to-be-tested paragraph of the new version file and the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file to obtain merged runtime data.

[0019] Optionally, recording the test probes inserted into each to-be-tested paragraph of the new version file and the old version file includes:

[0020] The identifier of the first test probe and the identifier of the last test probe inserted into each to-be-tested paragraph of the new version file and the old version file, as well as the identifier of each to-be-tested paragraph are recorded.

[0021] Optionally, the difference information includes:

[0022] The identifier of the new version file, the identifier of the old version file, and the paragraph information of the new version file that is changed relative to the old version file.

[0023] The second aspect of the present application provides a device for determining code coverage, including:

[0024] The first recording module is used to obtain the difference information between the new version file and the old version file;

[0025] A first testing module, configured to insert at least one testing probe into each to-be-tested paragraph of the new version file and the old version file;

[0026] A second recording module, used for recording the identification of the test probe inserted into each to-be-tested paragraph of the new version file and the old version file;

[0027] A second test module, configured to run the new version file and the old version file based on the inserted test probe to determine runtime data of the new version file and runtime data of the old version file;

[0028] The processing module is used to merge the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identifier of the test probe, and determine the operation coverage of the new version file.

[0029] Optionally, the processing module is specifically used for:

[0030] In response to matching the to-be-tested section of the new version file in the difference information, the running coverage of the new version file is determined based on the runtime data of the to-be-tested section of the new version file.

[0031] Optionally, the processing module is specifically used for:

[0032] In response to not matching the paragraph to be tested of the new version file in the difference information, merging the runtime data of the paragraph to be tested of the new version file with the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file;

[0033] Based on the merged runtime data, the runtime coverage of the new version file is determined.

[0034] Optionally, the processing module is specifically used for:

[0035] A logical OR operation is performed on the runtime data of the to-be-tested paragraph of the new version file and the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file to obtain merged runtime data.

[0036] Optionally, the second recording module is specifically used to:

[0037] The identifier of the first test probe and the identifier of the last test probe inserted into each to-be-tested paragraph of the new version file and the old version file, as well as the identifier of each to-be-tested paragraph are recorded.

[0038] Optionally, the difference information includes:

[0039] The identifier of the new version file, the identifier of the old version file, and the paragraph information of the new version file that is changed relative to the old version file.

[0040] The third aspect embodiment of the present application proposes an electronic device, comprising: a processor; a memory for storing executable instructions of the processor; wherein the processor is configured to call and execute the executable instructions stored in the memory to implement the code coverage determination method proposed in the first aspect embodiment of the present application.

[0041] The fourth aspect embodiment of the present application proposes a non-temporary computer-readable storage medium. When the instructions in the storage medium are executed by the processor of an electronic device, the electronic device can execute the code coverage determination method proposed in the first aspect embodiment of the present application.

[0042] The fifth aspect embodiment of the present application proposes a computer program product. When the computer program is executed by a processor of an electronic device, the electronic device can execute the code coverage determination method proposed in the first aspect embodiment of the present application.

[0043] The technical solution of the present application records the difference information between the new version file and the old version file; inserts at least one test probe in each paragraph to be tested of the new version file and the old version file; records the identification of the test probe inserted in each paragraph to be tested of the new version file and the old version file; runs the new version file and the old version file based on the inserted test probe to determine the runtime data of the new version file and the runtime data of the old version file; based on the difference information and the identification of the test probe, the runtime data of the new version file and the runtime data of the old version file are merged to determine the running coverage of the new version file. It can merge the runtime data of different versions to eliminate the dependence of the testing work on the version, and also supports combining the runtime data of the early full test to obtain more comprehensive coverage, which can effectively improve the efficiency of the test, improve the accuracy of the test results, and increase the flexibility of formulating the test plan.

[0044] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0046] Figure 1 A flowchart of a method for determining code coverage provided in an embodiment of the present application;

[0047] Figure 2 A schematic diagram of a code organization method provided in an embodiment of the present application;

[0048] Figure 3 A flowchart of another method for determining code coverage provided in an embodiment of the present application;

[0049] Figure 4 A schematic diagram of the structure of a code coverage determination device provided in an embodiment of the present application;

[0050] Figure 5 A structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0052] In related technologies, full testing is usually performed at certain important nodes of the project. After the test is completed, the runtime data of the full test is obtained, and then the overall operation coverage of the code is calculated. After the full test, the software version will continue to iterate and evolve due to bug fixes or the development of new functions. For each new version, due to the limitation of testing resources, it may not be possible to perform full testing. Only some relevant test cases can be selected for the modified code and incremental testing can be performed.

[0053] Because existing code coverage calculation tools do not support the integration of runtime data between different versions, it is impossible to calculate the overall coverage of the project code based on the early full test data and subsequent scattered incremental test data at the end of the project.

[0054] The code coverage determination method, electronic device, and computer-readable storage medium of the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0055] Figure 1 A flowchart of a method for determining code coverage provided in an embodiment of the present application is provided. It should be noted that the method is applied to a terminal device.

[0056] like Figure 1 As shown, the code coverage determination method may include the following steps:

[0057] Step 101, obtaining difference information between a new version file and an old version file.

[0058] In an embodiment of the present application, the difference information between the new version file and the old version file for which the running coverage of the code needs to be calculated can be recorded.

[0059] In some embodiments, the difference information includes: an identifier of the new version file, an identifier of the old version file, and paragraph information of changes in the new version file relative to the old version file.

[0060] Optionally, the granularity of the paragraph can be flexibly selected according to different actual situations, for example, it can be a class in the Java programming language, or a method, etc.

[0061] As an example, the implementation details of the present technical solution can be described in detail by taking the Java programming language as an example. It should be noted that the present technical solution is universal, and the method used is also applicable to other programming languages.

[0062] In this example, the difference information includes the identifier of the old version file (oldCommitId), the identifier of the new version file (newCommitId), and the changed paragraph information (changedClasses and changedMethods). Among them, "oldCommitId" and "newCommitId" are the unique identifiers of the old version code and the new version code respectively. "changedClasses" is a list that contains all the changed class and method information. Each sub-item contained in "changedClasses" corresponds to a class, and "className" is the name of the package where the class is located (class package) + the name of the class (class name), and "changedMethods" contains all the changed method information of the class. Each item in "changedMethods" corresponds to a method, and the information contained is the method name and the parameter type information of the method (for example: method name_parameter 1 type_..._parameter N type).

[0063] It should be noted that the granularity of the code organization mentioned above is from large to small: package > class > method > block. Generally, it can be organized as follows: Figure 2 Organized in the manner shown.

[0064] Step 102: insert at least one test probe into each to-be-tested paragraph of the new version file and the old version file.

[0065] In the embodiment of the present application, in order to obtain the runtime data of the file, it is necessary to insert a test probe into each to-be-tested section of the file. Inserting a test probe may also be called inserting a stub.

[0066] It should be noted that after the file is run, the values ​​of the test probes inserted therein can be used to know which codes in the file have been run and which codes have not been run. The values ​​of all the test probes inserted in the file are the runtime data of the file.

[0067] As an example, insert a test probe probe[x] after the 26th line of code in the file, where x is the identifier of the test probe. Generally speaking, in a class, the identifiers of the inserted test probes start from 0 and increase in sequence. After the file is run, if the value of probe[x] is 1 (or true), it means that the code on line 26 in the file has been run. If the value of probe[x] is 0 (or false), it means that the code on line 26 in the file has not been run.

[0068] Step 103 : Record the identification of the test probe inserted into each to-be-tested paragraph of the new version file and the old version file.

[0069] In the embodiment of the present application, it is necessary to record the identifier of the test probe inserted in each paragraph to be tested in the new version file and the old version file.

[0070] In some embodiments, what is recorded is the identifier of the first test probe and the identifier of the last test probe inserted into each paragraph to be tested of the new version file and the old version file, as well as the identifier of each paragraph to be tested.

[0071] As an example, the test probe information inserted in each class can be saved separately as a file, which includes the id of the class, the id of the first test probe and the id of the last test probe inserted in each method included in the class, and the name and parameter type of the method.

[0072] Among them, class id can be used to uniquely distinguish classes. Class id is calculated based on the content of the class itself using a specific algorithm (such as hash algorithm, cyclic checksum algorithm, etc.). As long as the content of the class does not change, the class id will not change.

[0073] Optionally, in order to facilitate subsequent search for probe information corresponding to a class based on the class id, the file name can be saved as the class id of the class.

[0074] Step 104: Run the new version file and the old version file based on the inserted test probe to determine runtime data of the new version file and runtime data of the old version file.

[0075] In the embodiment of the present application, after running the file, the values ​​of the test probes inserted in the file can be used to know which codes in the file have been run and which codes have not been run, and the runtime data of the file can be obtained. The values ​​of all the test probes inserted in the file are the runtime data of the file.

[0076] Step 105: Based on the difference information and the identification of the test probe, the runtime data of the new version file and the runtime data of the old version file are merged to determine the operation coverage of the new version file.

[0077] In an embodiment of the present application, the runtime data of the new and old versions of the files can be merged based on the recorded difference information between the new and old versions of the files and the identifiers of the test probes inserted in the files to determine the runtime coverage of the new version of the files.

[0078] In some embodiments, in response to matching a to-be-tested section of the new version file in the difference information, the running coverage of the new version file is determined based on the runtime data of the to-be-tested section of the new version file.

[0079] In some embodiments, in response to not matching the to-be-tested paragraph of the new version file in the difference information, merging the runtime data of the to-be-tested paragraph of the new version file with the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file;

[0080] Based on the fused runtime data, determine the running coverage of the new version file.

[0081] Optionally, the runtime data of the paragraph to be tested of the new version file and the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file are merged, including:

[0082] A logical OR operation is performed on the runtime data of the paragraph to be tested in the new version file and the runtime data of the paragraph to be tested in the old version file corresponding to the paragraph to be tested in the new version file to obtain the merged runtime data.

[0083] The embodiment of the present application records the difference information between the new version file and the old version file; inserts at least one test probe in each paragraph to be tested of the new version file and the old version file; records the identification of the test probe inserted in each paragraph to be tested of the new version file and the old version file; runs the new version file and the old version file based on the inserted test probe to determine the runtime data of the new version file and the runtime data of the old version file; based on the difference information and the identification of the test probe, the runtime data of the new version file and the runtime data of the old version file are merged to determine the running coverage of the new version file. It can merge the runtime data of different versions and eliminate the dependence of the testing work on the version. It also supports combining the runtime data of the early full test to obtain more comprehensive coverage. It can effectively improve the efficiency of the test, improve the accuracy of the test results, and increase the flexibility of formulating the test plan.

[0084] Figure 3 A flowchart of another method for determining code coverage provided in an embodiment of the present application is provided. It should be noted that the method is applied to a terminal device.

[0085] like Figure 3 As shown, the code coverage determination method may include the following steps:

[0086] Step 301, record the difference information between the new version file and the old version file.

[0087] In an embodiment of the present application, the difference information between the new version file and the old version file for which the running coverage needs to be calculated can be recorded.

[0088] In some embodiments, the difference information includes: an identifier of the new version file, an identifier of the old version file, and paragraph information of changes in the new version file relative to the old version file.

[0089] Optionally, the granularity of the paragraph can be flexibly selected according to different actual situations, for example, it can be a class in the Java programming language, or a method, etc.

[0090] As an example, the implementation details of the present technical solution can be described in detail by taking the Java programming language as an example. It should be noted that the present technical solution is universal, and the method used is also applicable to other programming languages.

[0091] In this example, the difference information includes the identifier of the old version file (oldCommitId), the identifier of the new version file (newCommitId), and the changed paragraph information (changedClasses and changedMethods). Among them, "oldCommitId" and "newCommitId" are the unique identifiers of the old version code and the new version code respectively. "changedClasses" is a list that contains all the changed class and method information. Each sub-item contained in "changedClasses" corresponds to a class, and "className" is the name of the package where the class is located (class package) + the name of the class (class name), and "changedMethods" contains all the changed method information of the class. Each item in "changedMethods" corresponds to a method, and the information contained is the method name and the parameter type information of the method (for example: method name_parameter 1 type_..._parameter N type).

[0092] It should be noted that the granularity of the code organization mentioned above is from large to small: package > class > method > block. Generally, it can be organized as follows: Figure 2 Organized in the manner shown.

[0093] Step 302: insert at least one test probe into each to-be-tested paragraph of the new version file and the old version file.

[0094] In the embodiment of the present application, in order to obtain the runtime data of the file, it is necessary to insert a test probe into each to-be-tested section of the file. Inserting a test probe may also be called inserting a stub.

[0095] It should be noted that after the file is run, the values ​​of the test probes inserted therein can be used to know which codes in the file have been run and which codes have not been run. The values ​​of all the test probes inserted in the file are the runtime data of the file.

[0096] As an example, insert a test probe probe[x] after the 26th line of code in the file, where x is the identifier of the test probe. Generally speaking, in a class, the identifiers of the inserted test probes start from 0 and increase in sequence. After the file is run, if the value of probe[x] is 1 (or true), it means that the code on line 26 in the file has been run. If the value of probe[x] is 0 (or false), it means that the code on line 26 in the file has not been run.

[0097] Step 303 : Record the identifier of the first test probe and the identifier of the last test probe inserted into each to-be-tested paragraph of the new version file and the old version file, as well as the identifier of each to-be-tested paragraph.

[0098] In the embodiment of the present application, the identifier of the first test probe and the identifier of the last test probe inserted into each paragraph to be tested of the new version file and the old version file, as well as the identifier of each paragraph to be tested are also recorded.

[0099] As an example, the test probe information inserted in each class can be saved separately as a file, which includes the id of the class, the id of the first test probe and the id of the last test probe inserted in each method included in the class, and the name and parameter type of the method.

[0100] Among them, class id can be used to uniquely distinguish classes. Class id is calculated based on the content of the class itself using a specific algorithm (such as hash algorithm, cyclic checksum algorithm, etc.). As long as the content of the class does not change, the class id will not change.

[0101] Optionally, in order to facilitate subsequent search for probe information corresponding to a class based on the class id, the file name can be saved as the class id of the class.

[0102] Step 304: Run the new version file and the old version file based on the inserted test probe to determine runtime data of the new version file and runtime data of the old version file.

[0103] In the embodiment of the present application, after running the new and old versions of the file respectively, the values ​​of the test probes inserted in the file can be used to know which codes in the file have been run and which codes have not been run, and the runtime data of the new and old versions of the file can be obtained. The values ​​of all the test probes inserted in the file are the runtime data of the file.

[0104] Step 305 : Match the to-be-tested section of the new version file in the difference information, and determine the operation coverage of the new version file based on the runtime data of the to-be-tested section of the new version file.

[0105] In an embodiment of the present application, if the paragraph to be tested of the new version file is included in the difference information of the aforementioned record, it means that the paragraph to be tested of the new version file is newly added or changed compared with the old version file, and the operation coverage of the new version file can be calculated directly based on the runtime data corresponding to the paragraph in the new version file.

[0106] Step 306: If the paragraph to be tested of the new version file is not matched in the difference information, the runtime data of the paragraph to be tested of the new version file is merged with the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file.

[0107] In an embodiment of the present application, if the paragraph to be tested of the new version file is not included in the difference information of the aforementioned record, it means that the paragraph to be tested of the new version file is not changed compared with the old version file, and it is necessary to merge the runtime data of the paragraph to be tested in the new and old version files to obtain the merged runtime data, and calculate the operation coverage of the new version file based on the merged runtime data.

[0108] Optionally, a logical OR operation is performed on the runtime data of the paragraph to be tested in the new version file and the runtime data of the paragraph to be tested in the old version file corresponding to the paragraph to be tested in the new version file to obtain the merged runtime data.

[0109] Step 307: Determine the operation coverage of the new version file based on the merged runtime data.

[0110] In an embodiment of the present application, if the paragraph to be tested in the new version file is unchanged compared to the old version file, it is necessary to merge the runtime data of the paragraph to be tested in the new and old version files to obtain the merged runtime data, and calculate the operation coverage of the new version file based on the merged runtime data.

[0111] As an example, the implementation details of the solution can be described in detail using the Java programming language. It should be noted that this technical solution is universal, and the method used is also applicable to other programming languages. In the embodiment of the present application, the fusion of the runtime data of the new and old versions can be shown in the following process:

[0112] 1) Construct the class list contained in the new version file, recorded as newClassList; construct the class list contained in the old version file, recorded as oldClassList.

[0113] 2) If newClassList is empty, exit directly. Otherwise, jump to step 3).

[0114] 3) Take out a class from newClassList and record it as currentClass.

[0115] 4) If currentClass does not exist in oldClassList, it means that currentClass is a newly added class, and the runtime data of the new version file is used directly, and jump to step 2); otherwise, it means that currentClass is a changed class, and jump to step 5).

[0116] 5) For currentClass, construct the method list contained in the currentClass of the new version file, recorded as newMethodList; construct the method list contained in the currentClass of the old version file, recorded as oldMethodList.

[0117] 6) If newMethodList is empty, jump to step 2).

[0118] 7) Take out a method from newMethodList and record it as currentMethod.

[0119] 8) If currentMethod does not exist in oldMethodList, it means that currentMethod is a newly added method; if currentMethod exists in oldMethodList and there is a matching method in the recorded difference information, it means that currentMethod is a changed method; if currentMethod exists in oldMethodList and there is no matching method in the recorded difference information, it means that currentMethod is an unchanged method. For newly added methods and changed methods, directly use the runtime data of the new version file, and jump to step 7) to match the next method; for unchanged methods, jump to step 9) to merge the runtime data of the new and old versions.

[0120] 9) According to the probe information inserted by currentMethod in the old version and the new version, the runtime data of the old version and the new version are merged, and then jump to step 6).

[0121] Optionally, the method to fuse runtime data is as follows:

[0122]

[0123] Among them, class A v1 is the runtime data corresponding to the test of class A on the old version, and the part of probe[x]-probe[x+len] is the runtime data corresponding to currentMethod. x and x+len are the id of the starting (first) probe and the id of the ending (last) probe inserted into currentMethod in the old version respectively.

[0124] class Av2 is the runtime data corresponding to the test of class A in the new version, where the part of probe[y]-probe[y+len] is the runtime data corresponding to currentMethod, and y and y+len are the id of the starting (first) probe and the id of the ending (last) probe inserted into currentMethod in the new version respectively.

[0125] class A merged is the runtime data after class A is merged, where the part probe[y]-probe[y+len] is the runtime data corresponding to currentMethod, and y and y+len are respectively the id of the starting (first) probe and the id of the ending (last) probe inserted into currentMethod in the new version.

[0126] The number of probes inserted into class A in the old version v1 is m. Because the code has changed, the number of probes inserted in the new version v2 becomes n. Because the code of currentMethod has not changed in the two versions, the number of probes inserted will not change; but because the code before currentMethod has changed, the start id and end id of the probes inserted into currentMethod will change in the new version.

[0127] The merged runtime data is based on the runtime data of the new version, finds the corresponding probe data in the old version, and performs a logical OR operation on the two data. For example, merged_probe[y+i]=v2_probe[y+i]|v1_probe[x+i].

[0128] The code coverage determination method of the embodiment of the present application records the difference information between the new version file and the old version file; inserts at least one test probe into each paragraph to be tested in the new version file and the old version file; records the identification of the first test probe and the identification of the last test probe inserted in each paragraph to be tested in the new version file and the old version file, as well as the identification of each paragraph to be tested; runs the new version file and the old version file based on the inserted test probes to determine the runtime data of the new version file and the runtime data of the old version file; matches the paragraph to be tested of the new version file in the difference information, and based on the paragraph to be tested of the new version file The runtime data of the new version file is used to determine the running coverage of the new version file; for the paragraphs to be tested that are not matched to the new version file in the difference information, the runtime data of the paragraphs to be tested of the new version file and the runtime data of the paragraphs to be tested of the old version file corresponding to the paragraphs to be tested of the new version file are merged, and the running coverage of the new version file is determined based on the merged runtime data. It can merge the runtime data of different versions and eliminate the dependency of the testing work on the version. It also supports combining the runtime data of the early full test to obtain more comprehensive coverage, which can effectively improve the efficiency of the test, improve the accuracy of the test results, and increase the flexibility of formulating the test plan.

[0129] In order to implement the above embodiment, the present application also proposes a device for determining code coverage.

[0130] Figure 4 A schematic diagram of the structure of a terminal device provided in an embodiment of the present application.

[0131] like Figure 4 As shown, the code coverage determination device includes: a first recording module 410, a first testing module 420, a second recording module 430, a second testing module 440, and a processing module 450.

[0132] The first recording module 410 is used to obtain the difference information between the new version file and the old version file;

[0133] A first testing module 420, configured to insert at least one testing probe into each to-be-tested paragraph of the new version file and the old version file;

[0134] A second recording module 430 is used to record the identification of the test probe inserted into each to-be-tested paragraph of the new version file and the old version file;

[0135] A second test module 440 is used to run the new version file and the old version file based on the inserted test probe to determine the runtime data of the new version file and the runtime data of the old version file;

[0136] The processing module 450 is used to merge the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identifier of the test probe, and determine the operation coverage of the new version file.

[0137] Optionally, the processing module 450 is specifically configured to:

[0138] In response to matching the to-be-tested section of the new version file in the difference information, the running coverage of the new version file is determined based on the runtime data of the to-be-tested section of the new version file.

[0139] Optionally, the processing module 450 is specifically configured to:

[0140] In response to not matching the to-be-tested paragraph of the new version file in the difference information, merging the runtime data of the to-be-tested paragraph of the new version file with the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file;

[0141] Based on the merged runtime data, the runtime coverage of the new version file is determined.

[0142] Optionally, the processing module 450 is specifically configured to:

[0143] A logical OR operation is performed on the runtime data of the to-be-tested paragraph of the new version file and the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file to obtain merged runtime data.

[0144] Optionally, the second recording module 440 is specifically used for:

[0145] The identifier of the first test probe and the identifier of the last test probe inserted into each to-be-tested paragraph of the new version file and the old version file, as well as the identifier of each to-be-tested paragraph are recorded.

[0146] Optionally, the difference information includes:

[0147] The identifier of the new version file, the identifier of the old version file, and the paragraph information of the new version file that has changed compared with the old version file.

[0148] The terminal device of the embodiment of the present application records the difference information between the new version file and the old version file; inserts at least one test probe in each paragraph to be tested of the new version file and the old version file; records the identification of the test probe inserted in each paragraph to be tested of the new version file and the old version file; runs the new version file and the old version file based on the inserted test probe to determine the runtime data of the new version file and the runtime data of the old version file; based on the difference information and the identification of the test probe, the runtime data of the new version file and the runtime data of the old version file are merged to determine the running coverage of the new version file. It can merge the runtime data of different versions and eliminate the dependence of the testing work on the version. It also supports combining the runtime data of the early full test to obtain more comprehensive coverage, which can effectively improve the efficiency of the test, improve the accuracy of the test results, and increase the flexibility of formulating the test plan.

[0149] It should be noted that the aforementioned explanation of the embodiment of the code coverage determination method applied to the terminal device is also applicable to the terminal device of this embodiment and will not be repeated here.

[0150] In order to implement the above embodiment, the present application also proposes an electronic device, comprising: a processor; a memory for storing executable instructions of the processor; wherein the processor is configured to call and execute the executable instructions stored in the memory to implement the above Figure 1-Figure 3 The code coverage determination method proposed in the embodiment.

[0151] In order to implement the above embodiment, the present application also proposes a non-transitory computer-readable storage medium. When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device can execute the above Figure 2-Figure 3 The code coverage determination method proposed in the embodiment.

[0152] In order to implement the above-mentioned embodiment, the embodiment of the present application further provides a computer program product, which, when executed by a processor of an electronic device, enables the electronic device to perform the above-mentioned Figure 1-Figure 3 The code coverage determination method proposed in the embodiment.

[0153] Figure 5 5 is a block diagram of an electronic device according to an exemplary embodiment. For example, the electronic device 500 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0154] Reference Figure 5, the electronic device 500 may include one or more of the following components: a processing component 502 , a memory 504 , a power component 506 , a multimedia component 508 , an audio component 510 , an input / output (I / O) interface 512 , a sensor component 514 , and a communication component 516 .

[0155] The processing component 502 generally controls the overall operation of the electronic device 500, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 502 may include one or more processors 520 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 502 may include one or more modules to facilitate the interaction between the processing component 502 and other components. For example, the processing component 502 may include a multimedia module to facilitate the interaction between the multimedia component 508 and the processing component 502.

[0156] The memory 504 is configured to store various types of data to support operations on the electronic device 500. Examples of such data include instructions for any application or method operating on the electronic device 500, contact data, phone book data, messages, pictures, videos, etc. The memory 504 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0157] The power component 506 provides power to the various components of the electronic device 500. The power component 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 500.

[0158] The multimedia component 508 includes a screen that provides an output interface between the electronic device 500 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 508 includes a front camera and / or a rear camera. When the electronic device 500 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0159] The audio component 510 is configured to output and / or input audio signals. For example, the audio component 510 includes a microphone (MIC), and when the electronic device 500 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 504 or sent via the communication component 516. In some embodiments, the audio component 510 also includes a speaker for outputting audio signals.

[0160] I / O interface 512 provides an interface between processing component 502 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0161] The sensor assembly 514 includes one or more sensors for providing various aspects of status assessment for the electronic device 500. For example, the sensor assembly 514 can detect the open / closed state of the electronic device 500, the relative positioning of components, such as the display and keypad of the electronic device 500, and the sensor assembly 514 can also detect the position change of the electronic device 500 or a component of the electronic device 500, the presence or absence of user contact with the electronic device 500, the orientation or acceleration / deceleration of the electronic device 500, and the temperature change of the electronic device 500. The sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 514 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 514 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0162] The communication component 516 is configured to facilitate wired or wireless communication between the electronic device 500 and other devices. The electronic device 500 can access a wireless network based on a communication standard, such as WiFi, 4G or 5G, or a combination thereof. In an exemplary embodiment, the communication component 516 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 516 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0163] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0164] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, and the instructions can be executed by a processor 520 of an electronic device 500 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0165] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0166] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0167] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0168] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0169] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0170] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0171] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0172] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for determining code coverage, characterized in that: The method comprises the following steps: Get the difference information between the new version file and the old version file; Inserting at least one test probe into each to-be-tested paragraph of the new version file and the old version file; Recording the identification of the test probe inserted into each to-be-tested paragraph of the new version file and the old version file; Running the new version file and the old version file based on the inserted test probe to determine runtime data of the new version file and runtime data of the old version file; Based on the difference information and the identifier of the test probe, the runtime data of the new version file and the runtime data of the old version file are merged to determine the operation coverage of the new version file.

2. The method according to claim 1, characterized in that: The step of fusing the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identifier of the test probe to determine the operation coverage of the new version file includes: In response to matching the to-be-tested section of the new version file in the difference information, the running coverage of the new version file is determined based on the runtime data of the to-be-tested section of the new version file.

3. The method according to claim 1, characterized in that The step of fusing the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identifier of the test probe to determine the operation coverage of the new version file includes: In response to not matching the paragraph to be tested of the new version file in the difference information, merging the runtime data of the paragraph to be tested of the new version file with the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file; Based on the merged runtime data, the runtime coverage of the new version file is determined.

4. The method according to claim 3, characterized in that The merging of the runtime data of the paragraph to be tested of the new version file and the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file comprises: A logical OR operation is performed on the runtime data of the to-be-tested paragraph of the new version file and the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file to obtain merged runtime data.

5. The method according to any one of claims 1 to 4, characterized in that: The recording of the test probes inserted into each to-be-tested paragraph of the new version file and the old version file includes: The identifier of the first test probe and the identifier of the last test probe inserted into each to-be-tested paragraph of the new version file and the old version file, as well as the identifier of each to-be-tested paragraph are recorded.

6. The method according to any one of claims 1 to 4, characterized in that: The difference information includes: The identifier of the new version file, the identifier of the old version file, and the paragraph information of the new version file that is changed relative to the old version file.

7. A device for determining code coverage, characterized in that: The device comprises: The first recording module is used to obtain the difference information between the new version file and the old version file; A first testing module, configured to insert at least one testing probe into each to-be-tested paragraph of the new version file and the old version file; A second recording module, used for recording the identification of the test probe inserted into each to-be-tested paragraph of the new version file and the old version file; A second test module, configured to run the new version file and the old version file based on the inserted test probe to determine runtime data of the new version file and runtime data of the old version file; The processing module is used to merge the runtime data of the new version file and the runtime data of the old version file based on the difference information and the identification of the test probe, and determine the operation coverage of the new version file.

8. The device according to claim 7, characterized in that The processing module is specifically used for: In response to matching the to-be-tested section of the new version file in the difference information, the running coverage of the new version file is determined based on the runtime data of the to-be-tested section of the new version file.

9. The device according to claim 7, characterized in that The processing module is specifically used for: In response to not matching the paragraph to be tested of the new version file in the difference information, merging the runtime data of the paragraph to be tested of the new version file with the runtime data of the paragraph to be tested of the old version file corresponding to the paragraph to be tested of the new version file; Based on the merged runtime data, the runtime coverage of the new version file is determined.

10. The device according to claim 9, characterized in that The processing module is specifically used for: A logical OR operation is performed on the runtime data of the to-be-tested paragraph of the new version file and the runtime data of the to-be-tested paragraph of the old version file corresponding to the to-be-tested paragraph of the new version file to obtain merged runtime data.

11. The device according to any one of claims 7 to 10, characterized in that: The second recording module is specifically used for: The identifier of the first test probe and the identifier of the last test probe inserted into each to-be-tested paragraph of the new version file and the old version file, as well as the identifier of each to-be-tested paragraph are recorded.

12. The device according to any one of claims 7 to 10, characterized in that: The difference information includes: The identifier of the new version file, the identifier of the old version file, and the paragraph information of the new version file that is changed relative to the old version file.

13. An electronic device, characterized in that: include: processor; a memory for storing executable instructions for the processor; The processor is configured to call and execute executable instructions stored in the memory to implement the method according to any one of claims 1 to 6.

14. A non-transitory computer-readable storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method as claimed in any one of claims 1 to 6.

Images