A method and device for determining code coverage

Abstract

The present invention provides a method and device for determining code coverage, wherein the method comprises: querying multiple associated code versions according to the requirements of the software under test; determining the code impact range of the code involved in the requirement; accumulating the coverage of the multiple code versions to obtain the cumulative coverage of the requirement; and determining the coverage of the code under test according to the code impact range and the cumulative coverage. This method can solve the problem in the field of software testing in the related art that the existing coverage calculation has limitations and low testing value, supports testing scenarios that require multiple rounds and mid-term version changes, and improves the testing value of code coverage.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a method and device for determining code coverage. Background Art

[0002] With the rapid development of software technology, software testing is also evolving. Industry testing standards are gradually forming, and new testing tools and methods are being implemented. The role of testing as a fundamental guarantee for improving software quality and efficiency and preventing and controlling risks is becoming increasingly apparent. Faced with the new requirements of the national ICT innovation strategy and the emerging demands of new business models such as open banking, bank software testing must grasp the trends, strengthen capacity building, continuously expand its scope, innovate methods, and establish standards. The goal is to become a supporter, guardian, and leader of financial technology innovation, and to demonstrate greater value in the process of bank digital transformation.

[0003] The code coverage of software testing refers to the proportion or degree to which the code is executed during testing. The code coverage can be used to measure the quality of the code to a certain extent.

[0004] Existing technical solutions or open source solutions only support test coverage of the entire code or incremental coverage, and the application scenarios are relatively simple.

[0005] In the field of software testing, existing coverage calculation technologies have the following shortcomings:

[0006] Testing limitations: Existing coverage technology only supports measuring software coverage metrics for the same version. It cannot support testing scenarios that require multiple rounds or mid-test version changes, such as system testing.

[0007] The test value is low. The measurement results of existing coverage technology have nothing to do with the functions and requirements of the software. It is just a simple and indiscriminate coverage calculation for all codes. Testers have no way of knowing the actual coverage of the target function.

[0008] In the field of software testing, there are problems in related technologies such as limitations in existing coverage calculations and low testing value, and no solution has yet been proposed. Summary of the Invention

[0009] The embodiments of the present invention provide a method and apparatus for determining code coverage, so as to at least solve the problem in the related art that existing coverage calculation has limitations and low testing value in the field of software testing.

[0010] According to one embodiment of the present invention, a method for determining code coverage is provided, comprising:

[0011] Query multiple code versions associated with the software under test;

[0012] Determine the code impact scope of the code involved in the requirement;

[0013] Accumulating the coverage of the multiple code versions to obtain a cumulative coverage of the requirement;

[0014] The coverage of the tested code is determined according to the code impact range and the cumulative coverage.

[0015] Optionally, after determining the coverage of the tested code according to the code impact range and the cumulative coverage, the method further includes:

[0016] The codes covered by the software under test are colored according to the code impact range of the requirement.

[0017] Optionally, determining the code impact scope of the code involved in the requirement includes:

[0018] Using a version comparison tool to compare the Java code of the starting version and the current version of the multiple code versions associated with the requirement, obtain a code change line number set DL[line], and save it to a storage medium;

[0019] Parse the current version of the Java code using an abstract syntax tree (AST) to identify a function set F[function];

[0020] The function set F[function] is screened according to the change line number set DL[line] to obtain the required change function set DF[function], wherein the code impact range is the change function set DF[function].

[0021] Optionally, determining the coverage of the tested code according to the code impact range and the cumulative coverage includes:

[0022] The cumulative coverage is screened using the changed function set DF[function] to obtain the requirement coverage.

[0023] Optionally, accumulating the coverage of the multiple code versions to obtain the cumulative coverage of the requirement includes:

[0024] Using the code coverage tool jacoco, a single application of the software under test is instrumented, and coverage information of the multiple code versions is collected at a fixed frequency and saved in a storage medium in an XML file format;

[0025] Get multiple XML files from storage media;

[0026] Sort the multiple XML files in chronological order to obtain File 1, File 2, File 3, ..., File n;

[0027] Taking the latest File n as the benchmark, merge File 1, File 2, File 3, ..., File n-1 into File n in sequence to obtain a merged result;

[0028] The cumulative coverage is determined according to the merging result.

[0029] Optionally, the latest File n is used as a benchmark, and File 1, File 2, File 3, ..., File n-1 are merged into File n in sequence, and the merged result includes:

[0030] The following steps are performed on each of File 1, File 2, File 3, ..., File n-1 until File 1, File 2, File 3, ..., File n-1 are merged into File n to obtain the merged result. The one currently being executed is called the current file:

[0031] Get the coverage details COVa of the unique signature KEYa of the function from the current File;

[0032] Parse the Filen to obtain the coverage details COVan of the function's unique signature KEYan;

[0033] If the KEYa corresponding to the current File is equal to the KEYan, merge the coverage details COVa corresponding to the current File and the coverage details COVan corresponding to the Filen;

[0034] If the KEYa corresponding to the current File is not equal to the KEYan, the coverage detail COVa corresponding to the current File is discarded, and only the coverage detail COVan corresponding to the Filen is retained.

[0035] According to another embodiment of the present invention, there is further provided a code coverage determination device, comprising:

[0036] The query module is used to query multiple code versions associated with the software under test;

[0037] A first determining module is used to determine the code impact scope of the code involved in the requirement;

[0038] An accumulation module, configured to accumulate the coverage of the multiple code versions to obtain a cumulative coverage of the requirement;

[0039] The second determining module is configured to determine the coverage of the tested code according to the code impact range and the cumulative coverage.

[0040] Optionally, the device further comprises:

[0041] The coloring module is used to color the code covered by the software under test according to the code impact range of the requirement.

[0042] Optionally, the first determining module includes:

[0043] The comparison submodule is used to compare the Java code of the starting version and the current version of the multiple code versions associated with the requirement using a version comparison tool to obtain a code change line number set DL[line] and save it to a storage medium;

[0044] A parsing submodule is used to parse the current version of the Java code using an abstract syntax tree (AST) to identify a function set F[function];

[0045] The screening submodule is used to screen the function set F[function] according to the change line number set DL[line] to obtain the required change function set DF[function], wherein the code impact range is the change function set DF[function].

[0046] Optionally, the second determining module is further configured to:

[0047] The cumulative coverage is screened using the changed function set DF[function] to obtain the requirement coverage.

[0048] Optionally, the accumulation module includes:

[0049] The instrumentation submodule is used to instrument a single application of the software under test using the code coverage tool jacoco, collect coverage information of the multiple code versions at a fixed frequency, and save it in a storage medium in XML file format;

[0050] The acquisition submodule is used to obtain multiple XML files from the storage medium;

[0051] A sorting submodule, configured to sort the plurality of XML files in chronological order to obtain File 1, File 2, File 3, ..., File n;

[0052] A merging submodule is used to take the latest File n as a benchmark and merge File 1, File 2, File 3, ..., File n-1 into File n in sequence to obtain a merged result;

[0053] The cumulative coverage is determined according to the merging result.

[0054] Optionally, the merging submodule is further configured to:

[0055] The following steps are performed on each of File 1, File 2, File 3, ..., File n-1 until File 1, File 2, File 3, ..., File n-1 are merged into File n to obtain the merged result. The one currently being executed is called the current file:

[0056] Get the coverage details COVa of the unique signature KEYa of the function from the current File;

[0057] Parse the File n to obtain the coverage details COVan of the function's unique signature KEYan;

[0058] If the KEYa corresponding to the current file is equal to the KEYan, merge the coverage details COVa corresponding to the current file and the coverage details COVa n corresponding to the file n;

[0059] If the KEYa corresponding to the current File is not equal to the KEYan, the coverage detail COVa corresponding to the current File is discarded, and only the coverage detail COVan corresponding to the File n is retained.

[0060] According to yet another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when run.

[0061] According to another embodiment of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments.

[0062] Through the present invention, multiple associated code versions are queried according to the requirements of the software under test; the code impact range of the code involved in the requirement is determined; the coverage rates of the multiple code versions are accumulated to obtain the cumulative coverage rate of the requirement; and the coverage rate of the code under test is determined according to the code impact range and the cumulative coverage rate. This can solve the problems in the related art of software testing that the existing coverage rate calculation has limitations and low testing value, supports testing scenarios that require multiple rounds and mid-term version changes, and improves the testing value of code coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0064] Figure 1 1 is a hardware structure block diagram of a mobile terminal according to a method for determining code coverage according to an embodiment of the present invention;

[0065] Figure 2 is a flowchart of a method for determining code coverage according to an embodiment of the present invention;

[0066] Figure 3 is a flowchart of code analysis according to an embodiment of the present invention;

[0067] Figure 4 is a flowchart of coverage collection and merging according to an embodiment of the present invention;

[0068] Figure 5 is a schematic diagram of a merging process of coverage details COVa1 and COVan according to an embodiment of the present invention;

[0069] Figure 6 is a flowchart of a demand coverage query according to an embodiment of the present invention;

[0070] Figure 7 is a block diagram of a code coverage determination apparatus according to an embodiment of the present invention. DETAILED DESCRIPTION

[0071] The present invention will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of the present application can be combined with each other.

[0072] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0073] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 is a hardware structure block diagram of a mobile terminal of a method for determining code coverage according to an embodiment of the present invention, such as Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown in the figure) processor 102 (processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA and other processing devices) and a memory 104 for storing data. Optionally, the mobile terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0074] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the code coverage determination method in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0075] The transmission device 106 is used to receive or send data via a network. A specific example of the aforementioned network may include a wireless network provided by the mobile terminal's communications provider. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one embodiment, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0076] In this embodiment, a method for determining code coverage running on the above mobile terminal or network architecture is provided. Figure 2 is a flow chart of a method for determining code coverage according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0077] Step S202, querying multiple associated code versions according to the requirements of the software under test;

[0078] Step S204: determining the code impact scope of the code involved in the requirement;

[0079] Step S206, accumulating the coverage of the multiple code versions to obtain the cumulative coverage of the requirement;

[0080] Step S208: determining the coverage of the tested code according to the code impact range and the cumulative coverage.

[0081] Through the above steps S202 to S208, multiple associated code versions are queried according to the requirements of the software under test; the code impact range of the code involved in the requirement is determined; the coverage rates of the multiple code versions are accumulated to obtain the cumulative coverage rate of the requirement; the coverage rate of the code under test is determined according to the code impact range and the cumulative coverage rate. This can solve the problem in the field of software testing in related technologies that the existing coverage rate calculation has limitations and low testing value, supports testing scenarios that require multiple rounds and mid-term version changes, and improves the testing value of code coverage.

[0082] In an optional embodiment, after the above step S208, the code covered by the software under test is colored according to the code impact range of the requirement, so that the user can clearly see the code covered by the software under test, thereby improving the user experience.

[0083] In an embodiment of the present invention, the above-mentioned step S204 may specifically include: using a version comparison tool to compare the starting version and the current version of the Java code in the multiple code versions associated with the requirement, obtaining the code change line number set DL[line], and saving it to a storage medium; using an abstract syntax tree AST to parse the current version of the Java code, and identifying the function set F[function]; according to the change line number set DL[line], screening the function set F[function] to obtain the change function set DF[function] of the requirement, wherein the code impact range is the change function set DF[function].

[0084] Correspondingly, the above step S206 may specifically include: using the changed function set DF[function] to filter the cumulative coverage to obtain the demand coverage.

[0085] In an embodiment of the present invention, the above-mentioned step S206 may specifically include: using the code coverage tool jacoco to instrument a single application of the software under test, collecting the coverage information of the multiple code versions at a fixed frequency, and saving them in a storage medium in XML file format; obtaining multiple XML files from the storage medium; sorting the multiple XML files in chronological order to obtain File 1, File 2, File 3, ..., File n; taking the latest File n as a benchmark, merging File 1, File 2, File 3, ..., File n-1 into File n in turn to obtain a merged result; determining the cumulative coverage based on the merged result.

[0086] Furthermore, taking the latest File n as a benchmark, File 1, File 2, File 3, ..., File n-1 are merged into File n in sequence to obtain the merge result, which may specifically include: performing the following steps on each of File 1, File 2, File 3, ..., File n-1 until File 1, File 2, File 3, ..., File n-1 are merged into File n to obtain the merge result, wherein the file being executed is called the current file: obtaining the coverage detail COVa of the unique signature KEYa of the function from the current file; parsing the File n to obtain the coverage detail COVan of the unique signature KEYan of the function; if the KEYa corresponding to the current file is equal to the KEYan, merging the coverage detail COVa corresponding to the current file and the coverage detail COVan corresponding to the File n; if the KEYa corresponding to the current file is not equal to the KEYan, discarding the coverage detail COVa corresponding to the current file and retaining only the coverage detail COVa n corresponding to the File n.

[0087] The embodiment of the present invention queries the associated code version according to the software requirement and calculates the specific impact range (function, line number) of the code involved in the requirement; in the case of multiple releases and tests of the tested software, the coverage rate between different versions is accumulated. According to the code impact range of the requirement, the requirement coverage rate is calculated; according to the code impact range of the requirement, the code covered by the test is colored. The following is a detailed description of each step.

[0088] 1. Query the associated code version based on software requirements.

[0089] During the code development, release, and testing process, requirements are described as an identifier, namely (EapsId).

[0090] During the development process, developers of the software application being tested will continuously submit new code using version management tools (such as Git). Each code submission must adhere to mandatory specifications, associating it with a specified requirement number. This way, after the code is pushed to a development branch (such as the develop branch) in a remote repository, version management platforms (such as GitLab and Gitee) can establish a mapping between commits and requirements using the requirement number.

[0091] When the operation and maintenance personnel of the software under test submit a new version for testing on the automated pipeline (CI / CD), they can specify one or more requirement numbers. The automated pipeline will only cherry-pick the commits associated with the selected requirements from the development branch of the code repository (such as the develop branch), and then merge them into the test branch (such as the baseline branch), and then generate a new version number.

[0092] Subsequently, the operation and maintenance personnel can initiate the deployment of this version on the automated pipeline (CI / CD) to complete the compilation, packaging, and deployment of the software under test.

[0093] The example of the present invention is integrated with the automated pipeline (CI / CD). Whenever a new code version of the software under test is submitted for testing / deployed, the example of the present invention will receive a corresponding notification and record the application identifier, requirement number, version number, test submission time, and deployment time of the software under test to the storage medium to establish a mapping relationship between the requirement and the test version.

[0094] 2. Calculate the specific impact range (function, line number) of the code involved in the requirement.

[0095] Use the version comparison tool to compare the starting version of the requirement and the current version of the Java code to obtain the code change line number set DL[line] and save it to the storage medium.

[0096] Then, the abstract syntax tree (AST) is used to parse the current version of the Java code and identify the function set F[function].

[0097] Then, according to the change line number set DL[line], the function set function set F[function] is filtered to obtain the change function set DF[function] of the requirement.

[0098] 3. When the software under test is released and tested multiple times, the coverage of different versions can be accumulated.

[0099] Use the code coverage tool jacoco to instrument a single application of the software under test, collect coverage information of the target application at a fixed frequency, and save it in the storage medium in XML file format.

[0100] By modifying jacoco, each function running in the Java virtual machine will be uniquely signed during the coverage collection process. Each function will generate a unique signature (function key) and a coverage detail (function coverage), which will be reflected in the saved XML file.

[0101] Typically, coverage information for an hour is saved as a separate XML file. For example, coverage information from 9:00 to 10:00 is saved as cover_2021091409_1.xml.

[0102] Specifically, when a version change occurs, the XML file within that hour will be split into multiple copies for storage. For example, the coverage information from 10:00 to 11:00 will be split into cover_2021091410_1.xml and cover_2021091410_2.xml due to a version change at 10:25.

[0103] Then, sort the multiple XML files into File1, File2, File3...Filen according to time from old to new, and take the latest XML file Filen as the benchmark, and merge File1, File2, File3...Filen-1 into Filen in sequence.

[0104] For the existing function a, take the merging of File1 and Filen as an example. The specific process of merging two by two is as follows:

[0105] Parse File1 and get the function's unique signature KEYa1 and coverage details COVa1

[0106] Parse Filen to get the unique signature of the function KEYan coverage details COVan

[0107] If KEYa1 is equal to KEYan, it means that the method has not been modified and the coverage details COVa1 and COVan can be directly merged. Otherwise, it means that the method has been modified and COVa1 needs to be discarded. Only the coverage details of COVan need to be retained.

[0108] Furthermore, the detailed merging of COVa1 and COVan coverage details essentially takes the union of the lines of code covered by both. Cumulative coverage is an intermediate product in the process of calculating requirement coverage.

[0109] 4. Calculate the requirement coverage based on the code impact scope of the requirement.

[0110] This example sets a switch that triggers when a requirement is first deployed, accumulating coverage during testing. When the upstream system changes the requirement's status to "deployed," the switch is turned off, stopping coverage accumulation. The accumulated coverage is then used as the COV[accumulate] for the requirement during testing.

[0111] The calculation process of the requirement coverage is the process of screening the cumulative coverage COV[accumulate] containing functions using the change function set DF[function] corresponding to the requirement.

[0112] From this we can see that demand coverage increases or decreases in two situations:

[0113] Under this requirement, the developer submitted new code, which caused the function to change (addition or modification), resulting in the coverage of the function being cleared. This impact will reduce the requirement coverage.

[0114] New tests cover the changed function codes involved in the requirements, which will increase the requirement coverage.

[0115] Figure 3 Flowchart of code analysis according to an embodiment of the present invention. Figure 3 As shown in the figure, the code analysis process includes:

[0116] Step S301: Receive and process the test notification sent by the automated pipeline (CI / CD platform).

[0117] When the interface device receives the code version test notification sent by the automated pipeline (CI / CD platform), it will write the code version test record into the data storage device, including the tested software application identifier, test version number, test requirement number, and version test time.

[0118] The interface device then sends a version update instruction to the code analysis device, the instruction including the tested software application identifier, the test version number, the test requirement number, the test branch, and the remote code repository address.

[0119] Step S302: Update the local code repository.

[0120] After the code analysis device receives the version update instruction, the code update module will pull the latest code from the test branch of the remote code repository and download the update to the local code repository.

[0121] After the update is completed, the code update module will call the code comparison module, and the parameters include the application ID of the software being tested, the test version number, the test requirement number, and the test branch.

[0122] Step S303: Compare the test version code.

[0123] After receiving the call request, the calling code comparison module performs subsequent processing, which is divided into two sub-steps.

[0124] First, calculate the difference between the tested version (Vn) and the previous version (Vn-1).

[0125] First, use a version comparison tool (such as jgitdiff) to compare the local repository's test version (Vn) with the previous version (Vn-1) to obtain the difference line number set DL[line]. Then, use the abstract syntax tree (AST) to parse the Java code in the test version (Vn) and identify the function set F[function]. Then, based on the changed line number set DL[line], filter the function set F[function] to obtain the changed function set DF[function].

[0126] Second, merge the resulting differences with the historical records in the requirement code change table.

[0127] Using the application ID of the software being tested and the requirement number as conditions, query the historical change records that have been inserted from the requirement code change table to obtain the historical change line number set HDL[line] and the historical change function set HDF[function] of the requirement. If the requirement is tested for the first time, both HDL[line] and HDF[function] are empty sets.

[0128] Traverse the elements in the DL[line] collection one by one. If the element already exists in the HDL[line] collection, do not process it. If not, add the element to the HDL[line] collection.

[0129] Similarly, traverse the elements in the DF[function] collection one by one. If the element already exists in the HDF[function] collection, no processing will be done. If not, the element will be added to the HDF[function] collection.

[0130] Then the historical change line number set HDL[line] and the historical change function set HDF[function] are updated to the requirement code change table.

[0131] Figure 4 is a flow chart of coverage collection and merging according to an embodiment of the present invention, such as Figure 4As shown in the figure, the coverage collection and merging process includes:

[0132] Step S401: Receive and process a deployment notification from the automated pipeline (CI / CD platform).

[0133] When the interface device receives the code version deployment notification from the automated pipeline (CI / CD platform), it will write the code version deployment record into the data storage device, including the tested software application ID, test version number, test requirement number, tested application IP, deployment package path, and version deployment time.

[0134] Then the interface device sends a deployment package pull instruction to the agent device according to the IP of the application under test. The instruction includes the software application identifier under test, the deployment version number, the deployment requirement number, the test branch, and the deployment package path.

[0135] Step S402: Pull the latest deployment package of the software under test.

[0136] After the agent device receives the deployment package pull instruction, since the agent device and the software under test are on the same server, it can find the latest deployment package of the software under test (including the compiled java class) according to the deployment package path, and then upload the deployment package to the file storage device of the instance of the present invention. The communication method used for uploading includes but is not limited to FTP, SFTP, SCP and other forms.

[0137] When the deployment package is pulled, if the requirement is deployed for the first time, the status of the requirement will be activated to be effective and written to the data storage device.

[0138] It should be noted that when the code of the requirement is put into production, the requirement management party will set the status of the requirement to invalid, which means that the testing cycle of the requirement is over.

[0139] Step S403: collecting coverage information from the software under test at a fixed frequency.

[0140] The scheduled task device will communicate with the instrumentation device of the tested software via TCP at a certain frequency (e.g., once per hour), extract coverage information (using the jacoco dump command), and generate an exec file. The deployment package file (including the compiled Java class) obtained in the previous step is then used to convert the exec file (using the jacoco report command) to an XML file. The file is saved in the following format:

[0141] / {Tested software application identifier} / coverage / cover-yyyymmddHH_{subscript}.xml

[0142] Typically, coverage information for an hour is saved as a separate XML file. For example, coverage information from 9:00 to 10:00 is saved as cover_2021091409_1.xml.

[0143] Specifically, when a version change occurs, the XML file within that hour will be split into multiple copies for storage. For example, the coverage information from 10:00 to 11:00 will be split into cover_2021091410_1.xml and cover_2021091410_2.xml due to a version change at 10:25.

[0144] Step S404: Calculate the cumulative coverage for each requirement and generate XML.

[0145] Since the start and end time of each requirement test cycle are different, the cumulative coverage of each requirement needs to be accumulated separately. The merging module of the timed task device performs the following processing on all valid requirements of the tested software:

[0146] The XML files collected by the previous acquisition module every hour are sorted from old to new by time every day as File1, File2, File3...Filen. Taking the latest XML file Filen as the benchmark, File1, File2, File3...Filen-1 are merged into Filen in sequence.

[0147] Taking function a as an example, the specific process of merging File1 and Filen is as follows:

[0148] Parse File1 and get the function's unique signature KEYa1 and coverage details COVa1

[0149] Parse Filen to get the unique signature of the function KEYan coverage details COVan

[0150] If KEYa1 is equal to KEYan, it means that the method has not been modified and the coverage details COVa1 and COVan can be directly merged. Otherwise, it means that the method has been modified and COVa1 needs to be discarded. Only the coverage details of COVan need to be retained.

[0151] Furthermore, for the detailed merging process covering details COVa1 and COVan, Figure 5 FIG. 1 is a schematic diagram of a merging process of coverage details COVa1 and COVan according to an embodiment of the present invention. Figure 5 As shown, it is essentially the union of the lines of code covered by the two.

[0152] Finally, the cumulative merge results are written into the cumulative coverage file corresponding to the requirements.

[0153] For example, the file save format is:

[0154] / {Tested software application identifier} / requiment / cov_{requirement number}.xml

[0155] Figure 6 is a flow chart of a demand coverage query according to an embodiment of the present invention, such as Figure 6 As shown in the figure, the demand coverage query process includes:

[0156] Step S601: The user initiates a demand coverage query from the front-end page.

[0157] The tester selects the requirement number of the software under test on the page to query. The front-end page will initiate a query request to the coverage device, and the request parameters include the software under test ID and the requirement number.

[0158] Step S602: The backend calculates the demand coverage and returns the result.

[0159] After receiving the query request, the coverage device reads the cumulative coverage file corresponding to the requirement and obtains the cumulative coverage details COV[accumulate] of the requirement.

[0160] Then, the change function set DF[function] corresponding to the requirement is queried from the data storage device.

[0161] As explained in the principle, the requirement coverage calculation process involves filtering the functions included in the cumulative coverage COV[accumulate] using the set of change functions corresponding to the requirement, DF[function]. If the function exists in DF[function], it is retained; otherwise, the function's coverage is eliminated.

[0162] After the screening is completed, the coverage information of each function is summarized according to the formula Σ(the number of rows covered by the changed function) / Σ(the total number of rows of the changed function) to calculate the requirement coverage.

[0163] After the calculation is completed, the requirement coverage Cov(requiment) (including detailed coverage information and summary values for each row) is converted into json and returned to the front end.

[0164] Step S603: The user checks the code coloring status.

[0165] The tester selects a single Java source code file on the page for query. The front-end page will initiate a code review request to the code analysis device. The request parameters include the requirement number, the branch of the code being tested, the code version, and the full path of the code.

[0166] Step S604: the backend downloads the specified code.

[0167] After the code analysis device receives the query request, the code download module will download the code of a single source code file according to the tested code branch, code version, and code full path, and return the source code content to the front-end page.

[0168] Step S605: The front-end page colors the source code.

[0169] After the front-end page receives the source code content, it finds the corresponding line coverage information from the json of the required coverage rate according to the code file name to be colored, and renders the source code line by line according to the line number. The covered lines can be rendered green, and the uncovered content is rendered red. Finally, the colored source code content is displayed on the interface (not shown in the figure).

[0170] This embodiment of the present invention boasts a powerful cross-version coverage merging capability. This allows testers to accumulate the results of each test round, rather than simply resetting them to zero. Furthermore, after completing multiple rounds of software testing, testers can select any time period and query the cumulative test coverage of multiple versions within that period. This allows testers to focus on truly untested code within a limited timeframe, thereby improving overall testing efficiency.

[0171] The present invention also provides a requirement coverage query function, allowing testers to focus on specific requirement change codes instead of viewing a bunch of indistinguishable coverage statistics. This allows testers to focus on the code that needs more testing in a limited time, thereby improving testing efficiency.

[0172] According to another embodiment of the present invention, a device for determining code coverage is provided. Figure 7 is a block diagram of a code coverage determination apparatus according to an embodiment of the present invention. Figure 7 As shown, including:

[0173] A query module 72 is used to query multiple code versions associated with the software under test according to the requirements;

[0174] A first determining module 74 is configured to determine a code impact scope of the code involved in the requirement;

[0175] An accumulation module 76, configured to accumulate the coverage of the multiple code versions to obtain a cumulative coverage of the requirement;

[0176] The second determining module 78 is configured to determine the coverage of the tested code according to the code impact range and the cumulative coverage.

[0177] Optionally, the device further comprises:

[0178] The coloring module is used to color the code covered by the software under test according to the code impact range of the requirement.

[0179] Optionally, the first determining module 74 includes:

[0180] The comparison submodule is used to compare the Java code of the starting version and the current version of the multiple code versions associated with the requirement using a version comparison tool to obtain a code change line number set DL[line] and save it to a storage medium;

[0181] A parsing submodule is used to parse the current version of the Java code using an abstract syntax tree (AST) to identify a function set F[function];

[0182] The screening submodule is used to screen the function set F[function] according to the change line number set DL[line] to obtain the required change function set DF[function], wherein the code impact range is the change function set DF[function].

[0183] Optionally, the second determining module 78 is further configured to:

[0184] The cumulative coverage is screened using the changed function set DF[function] to obtain the requirement coverage.

[0185] Optionally, the accumulation module includes:

[0186] The instrumentation submodule is used to instrument a single application of the software under test using the code coverage tool jacoco, collect coverage information of the multiple code versions at a fixed frequency, and save it in a storage medium in XML file format;

[0187] The acquisition submodule is used to obtain multiple XML files from the storage medium;

[0188] A sorting submodule, configured to sort the plurality of XML files in chronological order to obtain File 1, File 2, File 3, ..., File n;

[0189] A merging submodule is used to take the latest File n as a benchmark and merge File 1, File 2, File 3, ..., File n-1 into File n in sequence to obtain a merged result;

[0190] The cumulative coverage is determined according to the merging result.

[0191] Optionally, the merging submodule is further configured to:

[0192] The following steps are performed on each of File 1, File 2, File 3, ..., File n-1 until File 1, File 2, File 3, ..., File n-1 are merged into File n to obtain the merged result. The one currently being executed is called the current file:

[0193] Get the coverage details COVa of the unique signature KEYa of the function from the current File;

[0194] Parse the Filen to obtain the coverage details COVan of the function's unique signature KEYan;

[0195] If the KEYa corresponding to the current File is equal to the KEYan, merge the coverage details COVa corresponding to the current File and the coverage details COVa n corresponding to the Filen;

[0196] If the KEYa corresponding to the current File is not equal to the KEYan, the coverage detail COVa corresponding to the current File is discarded, and only the coverage detail COVa n corresponding to the File n is retained.

[0197] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0198] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when running.

[0199] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0200] S1, query multiple code versions associated with the software under test;

[0201] S2, determining the code impact scope of the code involved in the requirement;

[0202] S3, accumulating the coverage of the multiple code versions to obtain the cumulative coverage of the requirement;

[0203] S4. Determine the coverage of the tested code according to the code impact range and the cumulative coverage.

[0204] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store computer programs.

[0205] An embodiment of the present invention further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0206] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0207] Optionally, in this embodiment, the processor may be configured to execute the following steps through a computer program:

[0208] S1, query multiple code versions associated with the software under test;

[0209] S2, determining the code impact scope of the code involved in the requirement;

[0210] S3, accumulating the coverage of the multiple code versions to obtain the cumulative coverage of the requirement;

[0211] S4. Determine the coverage of the tested code according to the code impact range and the cumulative coverage.

[0212] Optionally, specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0213] Obviously, those skilled in the art will appreciate that the various modules or steps of the present invention described above can be implemented using a general-purpose computing device, centralized on a single computing device, or distributed across a network of multiple computing devices. Alternatively, they can be implemented using program code executable by a computing device, which can then be stored in a storage device and executed by the computing device. In some cases, the steps shown or described can be performed in a different order than that shown, or can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0214] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the principles of the present invention are intended to be within the scope of protection of the present invention.

Claims

1. A method for determining code coverage, characterized in that: include: Query multiple code versions associated with the software under test; Determining the code impact scope of the code involved in the requirement includes: using a version comparison tool to compare the Java code of the starting version and the current version of the multiple code versions associated with the requirement to obtain a code change line number set DL[line], and saving the code change line number set DL[line] to a storage medium; using an abstract syntax tree AST to parse the Java code of the current version to identify a function set F[function]; screening the function set F[function] according to the change line number set DL[line] to obtain a change function set DF[function] of the requirement, wherein the code impact scope is the change function set DF[function]; Accumulating the coverage of the multiple code versions to obtain a cumulative coverage of the requirement; The requirement coverage of the tested code is determined based on the code impact range and the cumulative coverage, including: using the change function set DF[function] to filter the cumulative coverage, and after the screening is completed, summarizing the coverage information of each function according to the formula Σ(the number of rows covered by the change function test) / Σ(the total number of rows of the change function) to obtain the requirement coverage.

2. The method according to claim 1, characterized in that After determining the coverage of the tested code according to the code impact range and the cumulative coverage, the method further includes: The codes covered by the software under test are colored according to the code impact range of the requirement.

3. The method according to any one of claims 1 to 2, characterized in that Accumulating the coverage of the multiple code versions to obtain the cumulative coverage of the requirement includes: Using the code coverage tool jacoco, a single application of the software under test is instrumented, and coverage information of the multiple code versions is collected at a fixed frequency and saved in a storage medium in an XML file format; Get multiple XML files from storage media; Sorting the multiple XML files in chronological order to obtain File 1, File 2, File 3, ..., File n; Taking the latest File n as a benchmark, merge File 1, File 2, File 3, ..., File n-1 into File n in sequence to obtain a merge result; The cumulative coverage is determined according to the merging result.

4. The method according to claim 3, characterized in that Taking the latest File n as the benchmark, merge File 1, File 2, File 3, ..., File n-1 into File n in sequence, and obtain the merged result including: The following steps are performed on each of File 1, File 2, File 3, ..., File n-1 until File 1, File 2, File 3, ..., File n-1 are merged into File n to obtain the merged result. The one currently being executed is called the current file: Get the coverage details COVa of the unique signature KEYa of the function from the current File; Parse the File n to obtain the coverage details COVa n of the function's unique signature KEYan; If the KEYa corresponding to the current file is equal to the KEYan, merge the coverage details COVa corresponding to the current file and the coverage details COVa n corresponding to the file n; If the KEYa corresponding to the current File is not equal to the KEYan, the coverage detail COVa corresponding to the current File is discarded, and only the coverage detail COVa n corresponding to the File n is retained.

5. A code coverage determination device, characterized in that: include: The query module is used to query multiple code versions associated with the software under test; A first determination module is configured to determine a code impact scope of the code involved in the requirement, including: using a version comparison tool to compare the Java code of the starting version and the current version of the multiple code versions associated with the requirement to obtain a code change line number set DL[line], and saving the code change line number set DL[line] to a storage medium; using an abstract syntax tree AST to parse the Java code of the current version to identify a function set F[function]; and screening the function set F[function] according to the change line number set DL[line] to obtain a change function set DF[function] of the requirement, wherein the code impact scope is the change function set DF[function]. An accumulation module, configured to accumulate the coverage of the multiple code versions to obtain a cumulative coverage of the requirement; The second determination module is used to determine the required coverage of the tested code according to the code impact range and the cumulative coverage, including: using the change function set DF[function] to filter the cumulative coverage to obtain the required coverage.

6. The device according to claim 5, characterized in that The device further comprises: The coloring module is used to color the code covered by the software under test according to the code impact range of the requirement.

7. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 4 when executed.

8. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 4.

Images