Code coverage rate determination method and device, equipment and storage medium
By adding a use case identifier to each test case and obtaining the corresponding tested code from the test record, the problem that the existing technology cannot accurately reflect the code coverage of a single test case is solved, and accurate measurement of the code coverage of each test case and accurate selection of applicable test cases is achieved.
Patent Information
- Application Number
- CN202411586767.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-07
- Publication Date
- 2025-03-07
AI Technical Summary
The existing technology cannot accurately reflect the code coverage of a single test case, making it difficult to accurately select suitable test cases after software code changes.
By adding a use case identifier to the request header of each test case, the code being tested triggered in the test record based on the use case identifier is obtained, and the code coverage of each test case is calculated.
It realizes accurate measurement of the code coverage of each test case, and can accurately select suitable test cases based on the test cases before the change after the software code changes.
Smart Images
Figure CN119576764A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of software testing technology, and in particular to a method, device, equipment and storage medium for determining code coverage. Background Art
[0002] Code coverage is a measure of software testing quality, used to evaluate whether test cases have executed enough statements, branches, functions, etc. in the code. Code coverage is usually expressed as a percentage, indicating the proportion of the number of tested codes to the total number of codes. The higher the code coverage, the wider the code coverage of the test cases, which helps to discover and fix potential code errors or vulnerabilities.
[0003] Since a software test often uses multiple test cases, the number of codes tested mentioned above is obtained by counting the total number of codes tested by multiple test cases. Therefore, the code coverage determined based on this reflects the code coverage of all test cases run during the entire testing process, but cannot reflect the code coverage of each test case run - that is, the code coverage determined using the existing technology cannot reflect which software codes each test case will cover.
[0004] The existence of the above problems will make it difficult to accurately determine which test case(s) should be selected for the changed code based on the code coverage of historical tests on the software after the software code is changed. Summary of the invention
[0005] The embodiments of the present application provide a method, apparatus, device and storage medium for determining code coverage, so as to solve the problem that the code coverage determined based on the prior art can only generally reflect the code coverage of all test cases run during the entire test process, but cannot accurately reflect the code coverage of a single test case, thus making it difficult to provide data support for the accurate selection of test cases.
[0006] The present application embodiment adopts the following technical solutions: A method for determining code coverage, comprising: Obtaining a test case identifier pre-added to a request header of a test case request; the request is a request sent by the test case to the software under test to achieve the test purpose; the test case identifier is an identifier that uniquely represents the test case; According to the use case identifier, the tested code that is triggered to run based on each request containing the use case identifier is obtained from the test record; the tested code is at least part of the code of the software under test; The code coverage of the test case represented by the use case identifier is determined according to the ratio of the amount of the tested code to the total amount of code of the software.
[0007] A device for determining code coverage, comprising: A use case identifier acquisition unit, used to acquire a use case identifier pre-added to a request header of the test case request; the request is a request issued by the test case to the software under test to achieve the test purpose; the use case identifier is an identifier that uniquely represents the test case; A test code acquisition unit, configured to acquire, from the test record, the tested code triggered to run based on each request containing the use case identifier, according to the use case identifier; the tested code is at least part of the code of the software under test; The coverage determination unit is used to determine the code coverage of the test case represented by the use case identifier according to the ratio of the amount of the tested code to the total amount of code of the software.
[0008] A computing device, comprising: a memory and a processor, wherein: The memory is used to store computer programs; The processor is coupled to the memory and is used to execute the computer program stored in the memory to perform the above method.
[0009] A computer-readable storage medium storing a computer program, wherein the computer program can implement the above method when executed by a computer.
[0010] A computer program product, comprising a computer program, which implements the above method when executed by a processor At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: Each test case is uniquely characterized by adding a use case identifier to the request header of each test case; the test code corresponding to the use case identifier is determined by obtaining the test code triggered by each request containing the use case identifier from the test record; thus, the test code covered by each test case is determined, and the code coverage of each test case can be determined. When the code of the object under test changes, the test case corresponding to the code before the change can be used to provide data support for the accurate selection of test cases for the test of the changed code. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1A flowchart of a method for determining code coverage provided in an embodiment of the present application; Figure 2 A specific implementation flow chart of a device for determining code coverage provided in an embodiment of the present application; Figure 3 A schematic diagram of the specific structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0012] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.
[0013] Those skilled in the art may appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.
[0014] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.
[0015] In order to solve the problem that the code coverage determined based on the prior art can only generally reflect the code coverage of all test cases run in the entire testing process, but cannot accurately reflect the code coverage of a single test case, making it difficult to provide data support for the accurate selection of test cases, an embodiment of the present application provides a method for determining code coverage.
[0016] The executor of the method may be any computing device that can implement the method, such as a server, a mobile phone, a personal computer, a smart wearable device, a smart robot, and the like.
[0017] In addition, the execution order of different steps is not limited in the embodiment of the present application. When using the method provided in the embodiment of the present application, the execution order of different steps can be adjusted according to actual needs.
[0018] For ease of description, the method provided in the embodiment of the present application is described in detail below by taking a device for determining code coverage as the execution subject of the present method as an example.
[0019] like Figure 1 As shown, it is a specific implementation flow chart of a method for determining code coverage provided in an embodiment of the present application, including the following steps 11 to 13: Step 11, obtain the test case identifier pre-added to the request header of the test case request.
[0020] Among them, a test case is a description of a test task for a specific software product, reflecting the test plan, method, technology and strategy. A test case contains test objectives, test environment, input data, test steps, expected results and test scripts, and finally forms a document. In simple terms, a test case is a set of test inputs, execution conditions and expected results compiled for a specific goal, which is used to verify whether a specific software requirement is met.
[0021] A test case request refers to a request issued to the software under test (software under test) based on a test case to achieve the test purpose; the test purpose refers to a certain function or performance of the test software. The request issued can be an HTTP (HyperText Transfer Protocol request).
[0022] The use case identifier is an identifier that uniquely represents a test case and is used to represent the uniqueness of the test case. The use case identifier can be expressed as a use case ID (Identification, identity identification information).
[0023] For testing in different scenarios such as interface testing and user interface (UI) testing, there are some differences in adding the test case identifier of the test case to the request header. Specifically: When this embodiment is applied to the scenario of performing interface testing on the software under test, the use case identifier of the test case is added to the request header, including: sending the request by using a third-party library (such as Apache HttpClient), and adding the use case identifier information by setting the request header field. The use case identifier can be added when the request is sent.
[0024] When this embodiment is applied to a scenario of performing user interface testing on the software under test, the use case identifier of the test case is added to the request header, including: adding the use case identifier to the request header of the running test case request through a preset browser plug-in (such as a Chrome browser plug-in).
[0025] In the scenario of user interface testing, if manual testing is performed, a use case identifier is added to the request header of the running test case request through a preset browser plug-in, specifically including the following steps 1001 to 1002: Step 1001: In response to a test operation clicked by a user through the browser plug-in, a test case is run.
[0026] During manual testing, the user (tester) selects pre-imported test cases through the browser plug-in based on the test requirements, and then clicks the test button.
[0027] The device for determining the code coverage starts to run the test case in response to the test operation clicked by the user through the browser plug-in.
[0028] Step 1002: intercepting, by means of the browser plug-in, a request sent by the test case to the software under test for achieving the test purpose, and adding a test case identifier to a request header of the intercepted request.
[0029] During the running of the browser plug-in identification test case, the request sent to the tested software is used to achieve the test purpose. Among them, the request identification can be identified by checking the request method, such as GET (request to request data from the specified resource), POST (submit data to the specified resource for processing), PUT (upload content to the specified resource location), etc.; the request can be identified through URL (Uniform Resource Locator, which specifies the location of the resource to be accessed) information, etc.
[0030] Adding a use case identifier to the request header of the intercepted request can be achieved through an integrated penetration testing tool, such as the ZAP (OWASP Zed Attack Proxy) tool.
[0031] In the scenario of user interface testing, if an automated test is performed, a use case identifier is added to the request header of each request of the running test case through a preset browser plug-in, specifically including the following steps 1011 to 1014: Step 1011, when initializing the automatic testing tool, load a preset browser plug-in.
[0032] The automated testing tool may be a seleniumDriver tool. Automated testing operates browser plug-ins through JS (JavaScript), and the browser plug-in information needs to be loaded when the seleniumDriver tool is initialized.
[0033] Step 1012: Use the automated testing tool to simulate the user's click test operation.
[0034] Through automated testing tools, simulate the user's selection of test cases that meet the test requirements and click test operations.
[0035] Step 1013: In response to the click test operation, run the test case.
[0036] Step 1014: intercepting, by means of the browser plug-in, a request sent by the test case to the software under test for achieving the test purpose, and adding a test case identifier to a request header of the intercepted request.
[0037] For the specific implementation process of this step, please refer to the above step 1002.
[0038] Step 12: According to the use case identifier, the tested code that is triggered to run based on each request containing the use case identifier is obtained from the test record.
[0039] Test records refer to the records formed after running test cases to test the specific requirements of the software under test. They are important documents to ensure that the test process is traceable and the results are reproducible. Test records include basic test information (such as project background, test purpose and test scope, etc.), test environment (including the hardware environment, software environment and network environment in which the test is conducted), test case information (case identification, case description, expected results, actual results after the test case is executed, and test results that indicate whether the actual results have passed or failed), and test execution process information (test start and end time, requests issued by test cases, code run by the software under test, test progress, problems encountered during the test), etc.
[0040] The code under test is at least part of the code of the software under test. In this step, the code in the software under test that is triggered to run based on the current request is obtained.
[0041] According to the use case identifier, the tested code triggered and executed by each request containing the use case identifier is obtained from the test record, specifically including the following steps 121 to 122: Step 121, based on the change of the state value of the embedded probe, determine all the tested codes run by the test.
[0042] The probe is used to indicate the location of each software code in the full software code; the status value of the probe is used to characterize the execution status of the code at the location indicated by the probe during the running of the test case.
[0043] The probe can be a Jacoco (Java Code Coverage, an open source Java code coverage tool) probe. The Jacoco probe uses the stub technology to insert probes into the code of the software under test before the test begins. Usually based on the test requirements, the probe is inserted before each line of code, each branch code, or each instruction code to collect the line coverage, branch coverage, or instruction coverage of the test. The inserted probe records the code being tested (execution status) during the test process.
[0044] The state of the code being tested is reflected by the state value of the probe. For example, when the probe is inserted, the state value of the probe is uniformly set to "false". When a certain code is tested during the test, the state value of the probe corresponding to the code becomes "true". Therefore, this step can determine all the tested codes run by the test based on the changes in the state value of the pre-embedded probe.
[0045] In addition, when obtaining the use case identifier in the request header, a step of obtaining the use case identifier in the request header can be added to the Jacoco instrumentation logic.
[0046] Based on the changes in the status values of the embedded probes, determine all the test codes run by the test, including: All pre-embedded probes whose state values have changed are obtained, and the codes at the positions indicated by all the pre-embedded probes are used as all the test codes to be run by the test.
[0047] Step 122: According to the use case identifier, the tested code that is triggered to run based on each request containing the use case identifier is selected from the entire test code.
[0048] Generally, the test record stores the request issued by each test case to the tested software, and the tested code triggered to run based on the request. Since the request header contains the test case identifier that represents the uniqueness of the test case, based on the test case identifier, the tested code triggered to run based on each request containing the test case identifier (a test case may issue multiple requests) can be selected from all the test codes determined in step 121.
[0049] In a feasible implementation, the method of this embodiment further includes: storing the acquired use case identifier and the status value of the pre-embedded probe in the form of a key-value pair; wherein the key in the key-value pair is the use case identifier of the test case, and the value in the key-value pair is the status value of the pre-embedded probe corresponding to the use case identifier. Storing the test case and the status value of the pre-embedded probe in the form of a key-value pair facilitates quick extraction of the code coverage of each test case.
[0050] Step 13: Determine the code coverage of the test case represented by the use case identifier according to the ratio of the amount of the tested code to the total amount of the software code.
[0051] The number of tested codes obtained in step 12 and the total number of codes of the software are counted respectively, and the ratio of the two is calculated as the code coverage of the test case represented by the current use case identifier.
[0052] The method for determining the code coverage of the embodiment of the present application uniquely characterizes each test case by adding a use case identifier to the request header of each test case; obtains the tested code triggered by each request containing the use case identifier from the test record, and determines the test code corresponding to the use case identifier; thereby determining the test code covered by each test case, and then determining the code coverage of each test case. When the code of the object under test changes, it can provide data support for accurately selecting test cases for testing the changed code based on the test cases corresponding to the code before the change.
[0053] In order to solve the problem that the code coverage determined based on the prior art can only generally reflect the code coverage of all test cases run in the entire testing process, but cannot accurately reflect the code coverage of a single test case, making it difficult to provide data support for accurate selection of test cases, based on the same inventive concept as the above-mentioned embodiment 1 of the present application, embodiment 2 of the present application provides a device for determining code coverage.
[0054] The specific structural diagram of the device is shown in Figure 2 As shown, it includes the following functional units 21-23: The use case identification acquisition unit 21 is used to obtain the use case identification pre-added to the request header of the test case request. The request is a request sent by the test case to the software under test to achieve the test purpose; the test case identifier is an identifier that uniquely represents the test case.
[0055] In a feasible implementation, the apparatus for determining code coverage in this embodiment further includes: a use case identification adding unit.
[0056] The use case identification adding unit is used to intercept the request issued based on the test case, and add the use case identification of the test case that issued the request in the request header of the intercepted request.
[0057] When this embodiment is applied to a scenario of performing user interface testing on the software under test, a use case identifier of the test case is added to a request header, including: adding a use case identifier to the request header of the running test case request through a preset browser plug-in (such as a Chrome browser plug-in).
[0058] In the scenario of user interface testing, if manual testing is performed, the use case identifier adding unit adds the use case identifier to the request header of the running test case request through a preset browser plug-in. Specifically, it includes: In response to a test operation clicked by a user through the browser plug-in, running a test case; The browser plug-in intercepts the request sent by the test case to the tested software for achieving the test purpose, and adds a use case identifier to the request header of the intercepted request.
[0059] In the scenario of user interface testing, if automated testing is performed, the use case identifier adding unit adds the use case identifier to the request header of each request of the running test case through a preset browser plug-in, specifically including: When initializing the automatic testing tool, load the preset browser plug-in; Use automated testing tools to simulate user click test operations; In response to the click test operation, the test case is run; The browser plug-in intercepts the request sent by the test case to the tested software for achieving the test purpose, and adds a use case identifier to the request header of the intercepted request.
[0060] The test code acquisition unit 22 is used to acquire, according to the use case identifier, from the test record the tested code that is triggered to run based on each request containing the use case identifier.
[0061] The code under test is at least part of the code of the software under test.
[0062] Test code acquisition unit, specifically used for: Based on the change of the state value of the embedded probe, all the tested codes run by the test are determined; the probe is used to indicate the position of each software code in the full amount of software code; the state value of the probe is used to characterize the execution status of the code at the position indicated by the probe during the running of the test case; According to the use case identifier, the tested code that is triggered to run based on each request containing the use case identifier is selected from the entire test code.
[0063] Wherein, based on the change of the state value of the embedded probe, all the tested codes run by the test are determined, including: obtaining all the embedded probes whose state values have changed, and taking the codes at the positions indicated by all the acquired embedded probes as all the test codes run by the test.
[0064] In one implementation of this embodiment, the device for determining code coverage also includes: storing the acquired use case identifier and the status value of the embedded probe in the form of a key-value pair; wherein the key in the key-value pair is the use case identifier of the test case, and the value in the key-value pair is the status value of the embedded probe corresponding to the use case identifier.
[0065] The coverage determination unit 23 is used to determine the code coverage of the test case represented by the use case identifier according to the ratio of the amount of the tested code to the total amount of the software code.
[0066] The device for determining the code coverage of the embodiment of the present application uniquely characterizes each test case by adding a use case identifier to the request header of each test case; obtains the tested code triggered by each request containing the use case identifier from the test record, and determines the test code corresponding to the use case identifier; thereby determining the test code covered by each test case, and further determining the code coverage of each test case. When the code of the object under test changes, it can provide data support for accurately selecting test cases for testing the changed code based on the test cases corresponding to the code before the change.
[0067] Based on the same inventive concept as the aforementioned embodiments of the present application, the embodiments of the present application also provide a computing device.
[0068] like Figure 3 As shown, the computing device includes: a memory 31 and a processor 32. The memory 31 can be configured to store various other data to support operations on the electronic device. Examples of these data include instructions for any application or method operating on the electronic device. The memory 31 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk or an optical disk.
[0069] The processor 32 is coupled to the memory 31 and is used to execute the computer program stored in the memory 31 to execute the method for determining code coverage described in the above embodiment.
[0070] When the processor 32 executes the computer program to perform the method for determining code coverage, each test case is uniquely characterized by adding a use case identifier in the request header of each test case; the test code corresponding to the use case identifier is determined by obtaining the tested code triggered by each request containing the use case identifier from the test record; thereby determining the test code covered by each test case, and then determining the code coverage of each test case. When the code of the object under test changes, the test case corresponding to the code before the change can provide data support for accurately selecting test cases for the test of the changed code.
[0071] When the processor 32 executes the computer program in the memory 31, in addition to the above functions, it can also realize other functions, which can be seen from the description of the previous embodiments for details.
[0072] Further, such as Figure 3 As shown, the computing device also includes: a display 34, a communication component 33, a power component 35, an audio component 36 and other components. Figure 3 Only some components are shown schematically, and it does not mean that the computing device only includes Figure 3 Components shown.
[0073] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a computer, the methods provided in the above embodiments can be implemented.
[0074] An embodiment of the present application also provides a computer program product, including a computer program, which implements the methods provided in the above embodiments when executed by a processor.
[0075] The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a processor, the methods provided in the above embodiments are implemented.
[0076] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.
[0077] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.
[0078] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims
1. A method for determining code coverage, characterized in that: include: Get the test case ID pre-added to the request header of the test case request; The request is a request sent by the test case to the software under test to achieve the test purpose; The test case identifier is an identifier that uniquely represents the test case; According to the use case identifier, the tested code that is triggered to run based on each request containing the use case identifier is obtained from the test record; The code under test is at least part of the code of the software under test; The code coverage of the test case represented by the use case identifier is determined according to the ratio of the amount of the tested code to the total amount of code of the software.
2. The method according to claim 1, characterized in that The method is applied to a scenario where a user interface test is performed on the software; the method further comprises: Use the preset browser plug-in to add a test case identifier to the request header of the running test case request.
3. The method according to claim 2, characterized in that When the user interface test is a manual test, adding a use case identifier to a request header of a running test case request through a preset browser plug-in includes: In response to a test operation clicked by a user through the browser plug-in, running a test case; The browser plug-in intercepts the request sent by the test case to the tested software for achieving the test purpose, and adds a use case identifier to the request header of the intercepted request.
4. The method according to claim 2, characterized in that When the user interface test is an automatic test, the method of adding a use case identifier to the request header of each request of the running test case through a preset browser plug-in includes: When initializing the automatic testing tool, load the preset browser plug-in; Use automated testing tools to simulate user click test operations; In response to the click test operation, the test case is run; The browser plug-in intercepts the request sent by the test case to the tested software for achieving the test purpose, and adds a use case identifier to the request header of the intercepted request.
5. The method according to claim 1, characterized in that According to the use case identifier, the tested code that is triggered and executed based on each request containing the use case identifier is obtained from the test record, including: Based on the change of the state value of the embedded probe, all the tested codes run by the test are determined; the probe is used to indicate the position of each software code in the full amount of software code; the state value of the probe is used to characterize the execution status of the code at the position indicated by the probe during the running of the test case; According to the use case identifier, the tested code that is triggered to run based on each request containing the use case identifier is selected from the entire test code.
6. The method according to claim 5, characterized in that The method of determining all test codes to be run based on the change of the state value of the embedded probe includes: All pre-embedded probes whose state values have changed are obtained, and the codes at the positions indicated by all the pre-embedded probes are used as all the test codes to be run by the test.
7. The method according to claim 5, characterized in that The method further comprises: The acquired use case identifier and the state value of the embedded probe are stored in the form of a key-value pair; The key in the key-value pair is the test case identifier of the test case, and the value in the key-value pair is the state value of the embedded probe corresponding to the test case identifier.
8. A device for determining code coverage, characterized in that: include: A use case identifier obtaining unit, used to obtain a use case identifier pre-added to a request header of a test case request; The request is a request sent by the test case to the software under test to achieve the test purpose; The test case identifier is an identifier that uniquely represents the test case; A test code acquisition unit, used to acquire, from the test record, the tested code triggered and run based on each request containing the use case identifier, according to the use case identifier; The code under test is at least part of the code of the software under test; The coverage determination unit is used to determine the code coverage of the test case represented by the use case identifier according to the ratio of the amount of the tested code to the total amount of code of the software.
9. A computing device, characterized in that include: Memory and processor, wherein: The memory is used to store computer programs; The processor is coupled to the memory and is used to execute the computer program stored in the memory to execute the method described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a computer, it can implement the method described in any one of claims 1 to 7.
11. A computer program product, characterized in that It includes a computer program, which, when executed by a processor, implements the method described in any one of claims 1 to 7.