Test quality evaluation method, system, device and medium based on code coverage

Abstract

This invention relates to the field of software testing technology, specifically disclosing a test quality assessment method, system, device, and medium based on code coverage. The invention obtains code change information, including changed lines of code and committers, from a version control system; deploys code coverage probes in the test environment to collect code coverage data during test execution; calculates incremental code coverage based on the change information and coverage data; and generates a test quality assessment report containing uncovered changed lines of code and their corresponding committers. This solves the problems of existing testing methods, such as difficulty in accurately grasping the actual coverage of code changes by test cases and the inability to intuitively identify uncovered code change areas, thereby improving the accuracy and comprehensiveness of pre-deployment test integrity assessment.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a test quality assessment method, system, device, and medium based on code coverage. Background Technology

[0002] During software system upgrades, test cases must be written for quality verification before code changes are deployed to the production environment. However, existing testing methods cannot guarantee that all business scenarios involved in code changes are fully executed. Testers struggle to accurately assess the actual coverage of code changes by test cases, leading to potential defects and omissions in uncovered code paths. Furthermore, the lack of quantifiable methods for evaluating code coverage makes it difficult to intuitively identify uncovered code change areas, hindering a comprehensive assessment of test completeness before deployment and increasing the risk of production environment failures.

[0003] Therefore, there is an urgent need to provide a technical solution to address the above problems. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a test quality assessment method, system, device, and medium based on code coverage.

[0005] Firstly, this invention provides a test quality assessment method based on code coverage, the technical solution of which is as follows: Obtain code change information for the target code version in the version control system. The code change information includes the lines of code that have been changed and the committer corresponding to each line of code that has been changed. By deploying a code coverage probe in the test environment, code coverage data of the target code version is collected during test execution. The code coverage data is used to identify whether each line of code is covered by the test execution. Based on the code change information and the code coverage data, the incremental code coverage of the target code version is determined. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines. Based on the incremental code coverage and the code change information, a test quality assessment report is generated. The test quality assessment report includes the uncovered changed code lines and the committers corresponding to the uncovered changed code lines.

[0006] The beneficial effects of the code coverage-based test quality assessment method of the present invention are as follows: The method of this invention obtains code change information, including changed lines of code and committers, from the version control system, deploys code coverage probes in the test environment to collect code coverage data during test execution, calculates incremental code coverage based on change information and coverage data, and generates a test quality assessment report containing uncovered changed lines of code and their corresponding committers. This solves the problems of existing testing methods that make it difficult to accurately grasp the actual coverage of code changes by test cases and cannot intuitively identify untested code change areas, thereby improving the accuracy and comprehensiveness of pre-deployment test integrity assessment.

[0007] Based on the above scheme, the test quality assessment method based on code coverage of the present invention can be further improved as follows.

[0008] In one alternative approach, the steps of obtaining code change information for the target code version within the version control system include: Access the local repository of the version control system that stores the target code version; Call the log interface of the local repository and set the file path to be analyzed, and obtain the commit history of the target code version under the file path from the local repository; Iterate through each commit object in the commit history, parse each commit object to extract commit metadata, including the committer; For each commit object, obtain the file snapshot corresponding to the commit object and the file snapshot corresponding to the previous commit object in the commit history from the local repository. Obtain the file content differences by comparing the file snapshots, and determine the lines of code that have changed under the file path based on the file content differences. The submitter in the submission metadata is identified as the submitter corresponding to the changed line of code, and the changed lines of code and their corresponding submitters are summarized to obtain the code change information.

[0009] The advantages of adopting the above optional method are as follows: by further accessing the local repository of the version control system, calling the log interface to obtain the commit history and parsing the commit objects, and comparing the file snapshots of adjacent commit objects to determine the changed code lines and committers, the problem of inaccurate extraction of information related to changed code lines and committers is solved, thereby improving the accuracy of code change information tracing.

[0010] In one alternative approach, the step of collecting code coverage data for the target code version during test execution using a code coverage probe deployed in a test environment includes: The code coverage probe is loaded when the test environment starts. The code coverage probe modifies bytecode and inserts recording instructions during class loading. Execute test cases for the target code version, and during test execution, use the recording instruction to mark the execution status of each line of code in real time; After the test execution is completed, the execution status data is exported from the code coverage probe, and the execution status data is used to generate the code coverage data. The code coverage data contains identification information indicating whether each line of code was covered by the test execution.

[0011] The advantages of adopting the above optional method are as follows: further loading the code coverage probe when the test environment starts, modifying the bytecode and inserting recording instructions to mark the code line execution status during class loading, and exporting the data after the test, which solves the problem of the difficulty in collecting code coverage status in real time and improves the real-time performance and completeness of code coverage data collection.

[0012] In one alternative approach, the step of determining the incremental code coverage of the target code version based on the code change information and the code coverage data includes: Extract the changed code lines corresponding to the target code version from the code change information, and extract the identifier information of whether each code line corresponding to the target code version has been covered by test execution from the code coverage data; The modified code lines are matched with the identification information to determine the code lines in the modified code lines that are covered by the test execution and the code lines in the modified code lines that are not covered by the test execution. The number of lines covered is obtained by counting the number of lines of code covered by the test execution among the changed lines of code, and the total number of changed lines of code is obtained by counting the total number of changed lines of code. The incremental code coverage of the target code version is determined based on the ratio of the number of covered lines to the total number of changed lines.

[0013] The advantages of adopting the above optional method are as follows: by further matching the changed code lines with the coverage identifier information, the covered and uncovered changed code lines are distinguished, and the incremental code coverage is determined by the ratio of the number of covered lines to the total number of changed lines. This solves the problem that the degree of change code coverage cannot be accurately quantified, and improves the accuracy of incremental code coverage assessment.

[0014] In one alternative approach, the step of generating a test quality assessment report based on the incremental code coverage and the code change information includes: Filter out the modified code lines that were not covered by the test execution from the code change information to obtain a set of uncovered code lines; Obtain the committer corresponding to each line of code in the set of uncovered lines of code from the code change information; The incremental code coverage, the set of uncovered code lines, and the committer corresponding to each code line are assembled according to a preset report template to generate the test quality assessment report.

[0015] The advantages of adopting the above optional method are: further filtering out the uncovered changed code lines from the code change information, obtaining the corresponding committers, and assembling them with the incremental coverage according to the template to generate an evaluation report, which solves the problem that the uncovered code lines and committer information cannot be presented intuitively, and improves the relevance and completeness of the test quality report generation.

[0016] In one alternative approach, it also includes: Obtain code coverage data from historical test tasks. If the current test task has the same project code as the historical test task and the code files have not changed, then establish an inheritance relationship between the current test task and the historical test task, and inherit the code coverage data of the historical test task to the current test task.

[0017] The advantages of adopting the above optional method are as follows: when the current test task and the historical test task have the same project code and the code files have not changed, an inheritance relationship is established, and the historical coverage data is inherited to the current test task. This solves the resource consumption problem caused by repeated testing of the same code and improves the test data reuse rate and test execution efficiency.

[0018] In one alternative approach, it also includes: The incremental code coverage is compared with a preset coverage threshold. When the incremental code coverage is lower than the preset coverage threshold, a release prohibition message is generated and the release process is blocked.

[0019] The beneficial effects of adopting the above optional method are as follows: by further comparing the incremental code coverage with the preset threshold, a release prohibition prompt is generated and the release process is blocked when the coverage is lower than the threshold, which solves the problem of code versions that do not meet the coverage standard being released by mistake, and improves the rigor and automation level of software release quality control.

[0020] Secondly, this invention provides a test quality assessment system based on code coverage, the technical solution of which is as follows: The acquisition module is used to acquire code change information of the target code version in the version control system. The code change information includes the code lines that have been changed and the committer corresponding to each changed code line. The data collection module is used to collect code coverage data of the target code version during test execution by a code coverage probe deployed in the test environment. The code coverage data is used to identify whether each line of code is covered by the test execution. The determination module is used to determine the incremental code coverage of the target code version based on the code change information and the code coverage data. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines. The generation module is used to generate a test quality assessment report based on the incremental code coverage and the code change information. The test quality assessment report includes the uncovered changed code lines and the submitters corresponding to the uncovered changed code lines.

[0021] The beneficial effects of the code coverage-based test quality assessment system of the present invention are as follows: The system of this invention obtains code change information, including changed lines of code and committers, from the version control system, deploys code coverage probes in the test environment to collect code coverage data during test execution, calculates incremental code coverage based on change information and coverage data, and generates a test quality assessment report containing uncovered changed lines of code and their corresponding committers. This solves the problems of existing testing methods that make it difficult to accurately grasp the actual coverage of code changes by test cases and cannot intuitively identify untested code change areas, thereby improving the accuracy and comprehensiveness of pre-deployment test integrity assessment.

[0022] Thirdly, the technical solution of an electronic device according to the present invention is as follows: It includes a memory, a processor, and a program stored in the memory and running on the processor, wherein the processor executes the program to implement the steps of the code coverage-based test quality assessment method of the present invention.

[0023] Fourthly, the technical solution of a computer-readable storage medium provided by the present invention is as follows: The computer-readable storage medium stores instructions that, when read, cause the computer-readable storage medium to perform the steps of the code coverage-based test quality assessment method of the present invention.

[0024] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0025] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1This is a flowchart illustrating an embodiment of a test quality assessment method based on code coverage according to the present invention. Figure 2 A schematic diagram of the architecture of an incremental code coverage platform; Figure 3 A schematic diagram illustrating the working principle of two instrumentation modes for code coverage probes; Figure 4 This is a schematic diagram of the version control system log parsing process; Figure 5 Example image for submitting metadata; Figure 6 Example image showing the calculation results of file content differences; Figure 7 Example image showing the output of formatted code change information; Figure 8 To connect to the coverage platform and see the version coverage trend chart; Figure 9 This is a diagram illustrating the coverage trend analysis. Figure 10 This is a schematic diagram of the quality score calculation model; Figure 11 This is a diagram illustrating the redesigned release process. Figure 12 This is a schematic diagram of the code coverage test project coverage interface. Figure 13 This is a schematic diagram of the code coverage file details coverage interface; Figure 14 A schematic diagram of the code submitter's interface for code coverage; Figure 15 A schematic diagram of the interface for identifying inheritance relationships; Figure 16 This is a flowchart of the inheritance process. Figure 17 A diagram illustrating the rules for breaking connections in inheritance relationships; Figure 18 This is a schematic diagram illustrating the process of merging dump files from multiple IP nodes. Figure 19 This is a schematic diagram of the interface for the requirements information module; Figure 20 This is a schematic diagram of an embodiment of a test quality assessment system based on code coverage according to the present invention; Figure 21 This is a schematic diagram of an embodiment of an electronic device according to the present invention. Detailed Implementation

[0026] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0027] Figure 1 This diagram illustrates a flowchart of an embodiment of a code coverage-based test quality assessment method provided by the present invention. This method can be executed by electronic devices such as terminal devices or servers. The terminal device can be any fixed or mobile terminal, such as user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, or wearable device. The server can be a single server or a server cluster consisting of multiple servers. Any electronic device can implement the code coverage-based test quality assessment method by having its processor call computer-readable instructions stored in its memory. Figure 1 As shown, it includes the following steps: S1. Obtain code change information of the target code version in the version control system. The code change information includes the lines of code that have been changed and the committer corresponding to each changed line of code.

[0028] In this context, the target code version refers to a specific software version identifier selected for testing and quality assessment within a version control system, typically corresponding to a code commit or release tag. For example, insurance company X, developing an online claims system, might use the code iteration version v2.1 submitted on January 1, 2026, as the target code version for this testing and assessment. A version control system is a tool used to record and manage the history of changes to software source code files, capable of tracking information such as the content, author, and time of each modification. For instance, insurance company X's development team might use version control system A to store the entire source code history of the online claims system.

[0029] Code change information refers to a detailed description of the modifications made to the target code version compared to the previous version, obtained from the version control system. This includes which lines of code were added, deleted, or modified, and the submitter of each modification. For example, version control system A might extract 15 lines of code from the online claims system v2.1, which modified the claims calculation module compared to v2.0. Of these, 10 lines were submitted by developer A, and 5 lines were submitted by developer B.

[0030] In this context, "changed lines of code" refers to every line of source code in the target code version that has changed compared to the previous version, including added, deleted, and modified lines. For example, the online claims system's fast claims function added 12 lines of code and modified 3 lines of existing logic; these 15 lines constitute the changed lines of code. "Modified lines of code" refers to all lines of code that have changed in the target code version, with the same meaning as "changed lines of code," and is used for subsequent calculations of incremental coverage. For example, the aforementioned 15 modified lines of code are the foundational data for subsequent calculations of incremental coverage. "Committer" refers to the developer's identity identifier, usually a username or email address, who performs the code commit operation in the version control system and records it in the commit metadata. For example, if developer A uses the username "developer_A" when committing code in version control system A, this username is the committer.

[0031] S2. By deploying a code coverage probe in the test environment, code coverage data of the target code version is collected during the test execution process. The code coverage data is used to identify whether each line of code is covered by the test execution.

[0032] The testing environment refers to an independent operating environment built for performing software testing, containing the system under test, testing tools, and related dependent services, isolated from the production environment. For example, Insurance Company X sets up a dedicated test server, deploys the online claims system version 2.1, and installs code coverage probe B to collect coverage data. A code coverage probe is a monitoring tool embedded in the program under test that collects code coverage information by recording the execution path during code execution. For instance, code coverage probe B is deployed in the online claims system's test environment, loaded when the system starts, and records in real time whether each line of code is executed.

[0033] The test execution process refers to the process of running test cases to verify software functionality, during which code coverage probes collect coverage data. For example, tester C executes test cases for the fast claims function, simulating user actions such as submitting claims and uploading documents, while code coverage probe B records the executed lines of code. Code coverage data refers to the raw data collected by the code coverage probes during test execution, used to identify which lines of code were executed. For example, the exec file exported by code coverage probe B contains marking information for all executed lines of code during the online claims system test.

[0034] In this context, "covered by test execution" refers to a line of code that has been executed at least once during the test. For example, if the newly added line 25 in the quick claims feature is executed during the test case execution, then that line of code is covered by test execution.

[0035] S3. Based on the code change information and the code coverage data, determine the incremental code coverage of the target code version. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines.

[0036] Incremental code coverage refers to the percentage of modified lines of code in a target code version that are executed in tests. It is used to measure the adequacy of testing newly added or modified code. For example, the online claims system v2.1 has 15 modified lines of code, of which 12 lines were executed in tests. Therefore, the incremental code coverage is 12 / 15 = 80%.

[0037] The number of lines of code covered by the test execution refers to the number of lines of code actually executed during the test execution process out of all changed lines of code in the target code version. For example, if 12 out of the aforementioned 15 changed lines of code are executed, then the number of lines of code covered by the test execution is 12. The total number of changed lines of code refers to the total number of all changed lines of code in the target code version. For example, the total number of changed lines of code in the online claims system v2.1 version is 15.

[0038] S4. Based on the incremental code coverage and the code change information, generate a test quality assessment report. The test quality assessment report includes the uncovered changed code lines and the submitters corresponding to the uncovered changed code lines.

[0039] The test quality assessment report refers to a document generated based on incremental code coverage and code change information. It includes the uncovered lines of changed code and their corresponding submitters, used to assist in assessing test completeness and tracing risks. For example, the report generated by the coverage platform shows that version v2.1 has 3 lines of code that were not covered by tests, submitted by developer A and developer B respectively, and the report is presented in chart form.

[0040] The technical solution of this embodiment obtains code change information, including changed lines of code and committers, from the version control system, deploys code coverage probes in the test environment to collect code coverage data during test execution, calculates incremental code coverage based on change information and coverage data, and generates a test quality assessment report containing uncovered changed lines of code and their corresponding committers. This solves the problem that existing testing methods are unable to accurately grasp the actual coverage of code changes by test cases and cannot intuitively identify untested code change areas, thereby improving the accuracy and comprehensiveness of pre-deployment test integrity assessment.

[0041] In one alternative approach, S1 specifically includes: Access the local repository where the target code version is stored in the version control system.

[0042] In this context, a local repository refers to a complete copy of the code repository stored by the version control system on the developer's local computer, containing all historical versions and metadata. For example, developer C clones the local repository of the version control system A for the online claims system on their computer to analyze code changes.

[0043] Call the log interface of the local repository and set the file path to be analyzed, and obtain the commit history of the target code version under the file path from the local repository.

[0044] The log interface refers to the application programming interface provided by the version control system for querying commit history. For example, the log interface of version control system A can be used to retrieve the commit history of a specified file path. The file path to be analyzed refers to the path of the source code file or directory whose changes need to be analyzed in the version control system. For example, when querying the change history of the claims calculation module in an online claims system, the file path could be set to src / main / java / com / example / ClaimCalculator.java.

[0045] In this context, commit history refers to a series of commit records arranged chronologically within a version control system, with each record corresponding to a code change. For example, the online claims system had 50 commits prior to version v2.1, constituting the commit history for that version.

[0046] Iterate through each commit object in the commit history, parse each commit object to extract commit metadata, including the committer.

[0047] In this context, a commit object refers to a data structure within a version control system that represents a commit. It includes a unique identifier for the commit, the author, the commit date, the commit message, and a pointer to a file snapshot. For example, each commit object in version control system A is a commit object, corresponding to a single code commit. Commit metadata refers to descriptive information stored in the commit object, including the committer, commit date, and commit message. For instance, a commit object might contain the committer developer_A, the commit date January 1, 2026, and the commit message "add fast claim feature".

[0048] For each commit object, obtain the file snapshot corresponding to the commit object and the file snapshot corresponding to the previous commit object in the commit history from the local repository. Obtain the file content differences by comparing the file snapshots, and determine the lines of code that have changed under the file path based on the file content differences.

[0049] A file snapshot refers to the complete record of all file contents made by the version control system at each commit, essentially representing the state of the code files at a specific moment. For example, when committing v2.1, version control system A generates a snapshot of all files, recording their contents at that time. File content differences refer to the detailed changes obtained by comparing two file snapshots line by line, including which lines were added, deleted, or modified. For example, comparing the ClaimCalculator.java files in versions v2.1 and v2.0 reveals that lines 20 through 25 were added, and line 30 was modified.

[0050] The submitter in the submission metadata is identified as the submitter corresponding to the changed line of code, and the changed lines of code and their corresponding submitters are summarized to obtain the code change information.

[0051] In the above optional methods, the commit history is further obtained by accessing the local repository of the version control system, calling the log interface and parsing the commit objects. The file snapshots of adjacent commit objects are compared to determine the changed code lines and the committers. This solves the problem of inaccurate extraction of information related to changed code lines and committers, and improves the accuracy of code change information tracing.

[0052] In one alternative approach, S2 specifically includes: The code coverage probe is loaded when the test environment starts. The code coverage probe modifies bytecode and inserts recording instructions during class loading.

[0053] The class loading process refers to the process by which the Java Virtual Machine (JVM) loads the bytecode file of a class into memory and performs parsing and initialization. For example, when an online claims system starts, the JVM loading the ClaimCalculator.class file is a class loading process. Modifying bytecode refers to dynamically changing the original bytecode content during class loading to insert additional instructions for monitoring purposes. For example, code coverage probe B modifies the bytecode of ClaimCalculator.class during class loading, inserting recording instructions before and after each line of code. Recording instructions are additional code fragments inserted into the bytecode by the code coverage probe to mark the current line of code as executed during program runtime. For example, the instructions inserted by code coverage probe B will update a boolean array when a line of code is executed, indicating that the line has been covered.

[0054] Execute test cases for the target code version, and during test execution, use the recording instruction to mark the execution status of each line of code in real time.

[0055] Test cases refer to a set of input data, execution steps, and expected results designed to verify specific software functions. For example, test case "TC001-Fast Claims-Normal Process" written by tester C includes steps such as entering the claim amount and uploading images, with the expected result being successful claim settlement.

[0056] After the test execution is completed, the execution status data is exported from the code coverage probe, and the execution status data is used to generate the code coverage data. The code coverage data contains identification information indicating whether each line of code was covered by the test execution.

[0057] Execution status data refers to intermediate data generated by recording instructions during test case execution, indicating which lines of code were triggered. For example, when executing TC001, the recording instruction marks lines 20, 21, and 22 of ClaimCalculator.java in memory as being executed. Identification information refers to markers in code coverage data used to indicate whether each line of code is covered, typically boolean values ​​or bitmaps. For example, code coverage data may contain a bit array, with each bit corresponding to a line of code, where 1 indicates coverage and 0 indicates no coverage.

[0058] In the above optional methods, a code coverage probe is further loaded when the test environment starts, bytecode is modified and recording instructions are inserted during class loading to mark the execution status of code lines, and data is exported after the test is completed. This solves the problem of the difficulty in collecting code coverage status in real time and improves the real-time performance and completeness of code coverage data collection.

[0059] In one alternative approach, S3 specifically includes: Extract the changed code lines corresponding to the target code version from the code change information, and extract the identifier information of whether each code line corresponding to the target code version has been covered by test execution from the code coverage data.

[0060] The modified code lines are matched with the identification information to determine the code lines in the modified code lines that are covered by the test execution and the code lines in the modified code lines that are not covered by the test execution.

[0061] The number of lines covered is obtained by counting the number of lines of code covered by the test execution in the changed code lines, and the total number of changed code lines is obtained by counting the total number of changed code lines.

[0062] The number of lines covered refers to the number of lines of code that are covered by the test execution out of all changed lines in the target code version. For example, if 12 out of the aforementioned 15 changed lines are covered, then the number of covered lines is 12. The total number of changed lines refers to the total number of all changed lines in the target code version. For example, the total number of changed lines in the online claims system v2.1 version is 15.

[0063] The incremental code coverage of the target code version is determined based on the ratio of the number of covered lines to the total number of changed lines.

[0064] In the above-mentioned optional methods, the incremental code coverage is further determined by matching the changed code lines with the coverage identifier information, distinguishing between covered and uncovered changed code lines, and calculating the ratio of the number of covered lines to the total number of changed lines. This solves the problem of the inability to accurately quantify the degree of changed code coverage and improves the accuracy of incremental code coverage assessment.

[0065] In one alternative approach, S4 specifically includes: The modified code lines that were not covered by the test execution were filtered out from the code change information to obtain a set of uncovered code lines.

[0066] The set of uncovered lines of code refers to the set of lines of code that were not covered by the test execution among all the changed lines of code in the target code version. For example, if 3 out of 15 changed lines of code are not covered, the line numbers of these 3 lines are 25, 31, and 42, which constitute the set of uncovered lines of code.

[0067] Obtain the committer corresponding to each line of code in the set of uncovered lines of code from the code change information.

[0068] The incremental code coverage, the set of uncovered code lines, and the committer corresponding to each code line are assembled according to a preset report template to generate the test quality assessment report.

[0069] In this context, a report template refers to a predefined format and structure for a test quality assessment report, including placeholders for titles, tables, and charts. For example, a coverage platform uses an HTML template, which reserves space for incremental coverage, a list of uncovered lines of code, and committer information.

[0070] Among the above optional methods, the missing changed code lines are further filtered from the code change information, the corresponding committers are obtained, and the incremental coverage is assembled with the template to generate an evaluation report. This solves the problem that the missing code lines and committer information cannot be presented intuitively, thereby improving the relevance and completeness of the test quality report generation.

[0071] In one alternative approach, it also includes: Obtain code coverage data from historical test tasks. If the current test task has the same project code as the historical test task and the code files have not changed, then establish an inheritance relationship between the current test task and the historical test task, and inherit the code coverage data of the historical test task to the current test task.

[0072] Historical test tasks refer to test tasks executed on the same software system at a previous point in time, and their code coverage data may be inherited. For example, the test task executed on January 1, 2026, for version v2.0 of the online claims system is a historical test task. Current test tasks refer to test tasks currently being executed for the target code version. For example, the current test executed for version v2.1 is a current test task.

[0073] In this context, "project code" refers to the collection of all source code files that constitute a software project, typically corresponding to a code repository. For example, all Java source files in an online claims system constitute the project code. "Inheritance relationship" refers to the association established between the current test task and historical test tasks, allowing the current task to utilize coverage data from historical tasks and avoid duplicate calculations. For instance, when the code files for v2.1 and v2.0 remain unchanged, the platform automatically establishes an inheritance relationship, passing the coverage data from v2.0 to v2.1.

[0074] Among the above optional methods, an inheritance relationship is further established when the current test task and the historical test task have the same project code and the code files have not changed. The historical coverage data is inherited to the current test task, which solves the resource consumption problem caused by repeated testing of the same code and improves the test data reuse rate and test execution efficiency.

[0075] In one alternative approach, it also includes: The incremental code coverage is compared with a preset coverage threshold. When the incremental code coverage is lower than the preset coverage threshold, a release prohibition message is generated and the release process is blocked.

[0076] The preset coverage threshold refers to the minimum acceptable percentage of incremental code coverage set for determining whether testing is sufficient. For example, if a company stipulates that incremental code coverage must reach at least 80% before a release, then 80% is the preset coverage threshold.

[0077] The "prohibit release" warning message refers to a system-generated warning message indicating a risk to the current version when incremental code coverage falls below a preset coverage threshold. For example, if v2.1's incremental coverage is 75%, the platform will display a message stating, "Incremental coverage is below 80%, it is recommended to conduct additional testing before releasing." "Blocking the release process" refers to using automated methods in continuous integration or release systems to prevent subsequent steps in the production environment deployment of a version. For example, if incremental coverage is insufficient, the continuous integration pipeline will automatically halt, ceasing subsequent tasks such as packaging and deployment.

[0078] Among the above optional methods, by further comparing the incremental code coverage with a preset threshold, a release prohibition prompt is generated and the release process is blocked when the coverage is lower than the threshold. This solves the problem of code versions that do not meet the coverage standard being mistakenly released, thereby improving the rigor and automation level of software release quality control.

[0079] In this embodiment, the incremental code coverage platform is built upon a code coverage probe and a version control system to evaluate the coverage of code changes during testing. Figure 2 As shown, the platform is deployed in a test environment. It collects coverage data from multiple server nodes through a code coverage probe, generates a dump file, and obtains code change information from the version control system, including code committers and commit branches. The dump file and code change information are merged and processed to calculate metrics such as incremental code coverage, requirement coverage, and file coverage.

[0080] The code coverage probe uses bytecode instrumentation technology to record the code execution status. Figure 3 This demonstrates the working principles of two instrumentation modes for code coverage probes. In On-the-fly mode, the code coverage probe agent is loaded via Java Virtual Machine parameters when the test environment starts. Before the class loader loads each class, the probe agent dynamically modifies the bytecode and inserts recording instructions. The Java Virtual Machine executes the instrumented class, and after the test execution, coverage data is collected to generate an exec file and output a visual report. In Offline mode, the compiled raw bytecode file first undergoes offline instrumentation preprocessing by the code coverage probe to generate instrumented bytecode files, and then the test cases or application are executed, similarly collecting coverage data and generating a report.

[0081] Version control system log parsing is a core component for obtaining code change information. For example... Figure 4As shown, the following operations are performed in a Java application using the version control system's application programming interface: First, the `Git.open` method is called, passing in the local repository path. This accesses the version control system object repository, returns a `Repository` instance, and opens the local repository storing the target code version. Next, the `git.log().addPath` method is called to set the file path to be analyzed and create a log command, retrieving the commit history from the version control system object repository for the specified file path. Each commit object in the commit history is traversed, and the following parsing is performed: The commit object is parsed to extract commit metadata, including author, commit time, and commit message; the corresponding file's tree object is obtained; the file content hash value is returned; and the file content differences between the current commit object and the previous commit object are calculated. After traversal, the results are processed and formatted, extracting information such as the number of changed lines and committer, and returning a structured data list to the Java application for subsequent coverage calculations.

[0082] Figure 5 This example demonstrates the commit metadata for a single commit in a version control system, including the commit identifier, committer, commit date, and commit description. Figure 6 It displays the calculation results of the differences in the file content, showing which specific lines of code were added, deleted, or modified. Figure 7 It displays the formatted code change information output, including the changed file path, the range of changed line numbers, and the corresponding committer.

[0083] The platform has achieved remarkable results in actual use. Figure 8 The chart shows the coverage trend after the platform was integrated, indicating that the coverage has steadily increased over time. Figure 9 The report presents a more detailed coverage trend analysis, displaying coverage changes across different dimensions. Through platform application, a total of 5 risk omission scenarios were identified in claims processing, as shown in Table 1. In October, issues were found including a missing Businessno when viewing historical calculation reports and the continued loss of more than ten ear tags after claim rejection. In November, issues were found including the lack of anonymized display in the reopened claims interface, the absence of display in non-group insurance scenarios, and the removal of redundant code.

[0084] Table 1: The platform's next phase of development will involve combining large-scale artificial intelligence models to output multi-dimensional quality scores. For example... Figure 10As shown, the platform will calculate test quality scores, development quality scores, and departmental requirement quality scores. Coverage scores are divided according to coverage ranges: 100% coverage earns 100 points, coverage greater than 80% earns 90 points, coverage between 60% and 80% earns 80 points, and coverage less than 60% earns 60 points. Test quality scores are calculated by weighting incremental coverage, scenario miss rate, and uncovered risk identification rate. The quality score equals incremental coverage multiplied by 40%, scenario miss rate multiplied by 30%, and uncovered risk identification rate multiplied by 30%. Development quality scores are calculated by weighting the defect rate per thousand lines of code and the invalid commit rate of uncovered code. The quality score equals the defect rate per thousand lines of code multiplied by 70%, and the invalid commit rate of uncovered code multiplied by 30%. Departmental quality scores are calculated by weighting incremental coverage scores, test quality scores, and development quality scores. Departmental quality scores equal incremental coverage scores multiplied by 40%, test quality scores multiplied by 30%, and development quality scores multiplied by 30%. In addition, the release process will be revamped, such as... Figure 11 As shown, a coverage check step is added to the release process, and a blocking mechanism is triggered when the incremental code coverage does not meet the standard.

[0085] Figure 12 The code coverage test project coverage interface is displayed, showing the overall coverage of each test task. Figure 13 The code coverage file details coverage interface displays the coverage status of each line at the code level, using different colors to mark covered and uncovered lines of code. Figure 14 The code coverage interface displays the committer information for each code file.

[0086] The code coverage branching framework clearly defines the commit guidelines. When developing directly on a development branch, commit logs must include a requirement identifier, description, and personalized information. Defect modification logs also include the requirement identifier and description. When creating branches based on requirement identifiers, the branch naming convention is requirement identifier plus personalized information, and commit logs include the requirement description plus personalized information. Defect modification logs include the requirement identifier, description, and personalized information. After a regular release, tags are created to mark version completion milestones. Each upgrade triggers a version tag, taking into account the version's requirement volume and overall coverage.

[0087] Code coverage inheritance addresses the issue of data reset. Coverage data within the same project and source code will be reset and re-accumulated when the project is redeployed. The platform implements task inheritance relationships. Task inheritance rules include: same project code and source code; the default task inheritance period is between last Saturday and this Friday; users can manually create task inheritance relationships for tasks that have not yet been inherited. When manually associating inherited tasks, only the newest tasks without inheritance relationships can be manually associated; only available tasks can be associated; file coverage inheritance only occurs if the code files between tasks remain unchanged; differences in code files between tasks will not result in inheritance. Figure 15 An interface displaying inheritance relationships was provided. Figure 16 This is a flowchart of the inheritance process. Figure 17 Supplementary rules for breaking inheritance relationships.

[0088] The code coverage compatibility enhancement for containerized multi-IP information collection supports multi-node coverage data merging. The original coverage calculation process did not support multi-IP node merging calculations. The enhancement adds information collection support for merging dump files from multiple IP nodes to the original calculation nodes, and also adds a temporary file cleanup node. For example... Figure 18 As shown, the modified process includes downloading dump files from multiple machine IPs remotely to the local machine, merging multiple dump files into a final exec file for coverage task calculation, and cleaning up the temporarily downloaded files. The changes include modifying the continuous integration tool to dynamically obtain multiple IPs while maintaining consistent ports, ensuring server-side compatibility with multi-IP storage, splitting dump task loading, merging dump files, and cleaning up temporary files.

[0089] Three processing scenarios were designed for multiple IP nodes. Scenario 1: When a task has two IP nodes running simultaneously, the backend service retrieves dump files from all IPs and merges them to produce the final dump file when both IPs are alive. Scenario 2: When a task has only one IP node running, the backend service uses the dump file corresponding to the alive IP as the final dump file when at least one IP is alive. Scenario 3: When a task has neither IP node running, the backend service skips retrieving the current dump file when neither IP is alive, and checks again in the next loop until an IP is alive before retrieving its corresponding dump file.

[0090] The code coverage requirements list adds a requirements information module to the coverage report. For example... Figure 19 As shown, the requirements information module is placed below the deployment information module, displaying information such as sequence, requirement name, and submitter.

[0091] In another embodiment of the code coverage-based test quality assessment method of the present invention, the following steps are specifically included: S10. Obtain code change information for the target code version in the version control system. The code change information includes the lines of code that have been changed and the committer for each line of code that has been changed. S20. By deploying code coverage probes in the test environment, code coverage data of the target code version is collected during the test execution process. The code coverage data is used to identify whether each line of code is covered by the test execution. S30. Based on the code change information and code coverage data, determine the incremental code coverage of the target code version. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines. S40. Based on the incremental code coverage and code change information, generate a test quality assessment report. The test quality assessment report includes the uncovered changed code lines and the committers of the uncovered changed code lines. S50. Obtain multiple dump files collected by the code coverage probe deployed on multiple IP nodes, detect the survival status of each IP node, pull the corresponding dump file from the surviving IP node, and merge multiple dump files to generate the final exec file as code coverage data. S60. Extract the requirement identifier corresponding to each changed line of code from the code change information, associate the requirement identifier with the uncovered changed line of code, add a requirement information module to the test quality assessment report, and display the requirement identifier, the uncovered changed line of code corresponding to the requirement identifier, and the corresponding submitter. S70. Obtain code coverage data of historical test tasks, determine whether the project code of the current test task is the same as that of the historical test task and whether the code files have not changed. If they are the same and have not changed, establish the inheritance relationship between the current test task and the historical test task, and inherit the code coverage data of the historical test task to the current test task. S80. Based on the comparison between incremental code coverage and preset coverage threshold, when the incremental code coverage is lower than the preset coverage threshold, generate a release prohibition prompt message and block the release process; S90. Calculate the coverage score based on incremental code coverage, determine the scenario miss rate based on the number of missed scenarios corresponding to the uncovered changed code lines, determine the uncovered risk identification rate based on the number of risks identified in the uncovered changed code lines, calculate the test quality score based on incremental code coverage, scenario miss rate, and uncovered risk identification rate, determine the defect rate per thousand lines of code based on the ratio of the number of code defects to the number of code lines, determine the uncovered code invalid commit rate based on the proportion of invalid commits in the uncovered code lines, calculate the development quality score based on the defect rate per thousand lines of code and the uncovered code invalid commit rate, and calculate the departmental quality score based on the coverage score, test quality score, and development quality score. Add the coverage score, test quality score, development quality score, and departmental quality score to the test quality assessment report.

[0092] This embodiment solves the problems of incompatibility of coverage data in multi-node deployments, disconnect between uncovered code and requirement information, waste of resources due to repeated testing of the same code, accidental release of low-coverage versions, and inability of a single indicator to comprehensively evaluate test quality by acquiring code change information including changed lines of code and submitters, collecting code coverage data and calculating incremental code coverage, merging dump files from multiple IP nodes, associating requirement identifiers with uncovered lines of code, establishing historical task inheritance relationships, setting preset coverage thresholds to block the release process, and calculating coverage score, test quality score, development quality score, and departmental quality score. It achieves completeness and accuracy of multi-node coverage data merging, traceability of uncovered code and requirement information, improved test data reuse and execution efficiency, automated control of release quality, and comprehensive multi-dimensional quantitative evaluation of test and development quality.

[0093] Figure 20 This diagram illustrates the structure of an embodiment of a code coverage-based test quality assessment system 200 provided by the present invention. Figure 20 As shown, the code coverage-based test quality assessment system 200 includes: The acquisition module 201 is used to acquire code change information of the target code version in the version control system. The code change information includes the code lines that have been changed and the committer corresponding to each changed code line. The acquisition module 202 is used to acquire code coverage data of the target code version during test execution by a code coverage probe deployed in the test environment. The code coverage data is used to identify whether each line of code is covered by the test execution. The determination module 203 is used to determine the incremental code coverage of the target code version based on the code change information and the code coverage data. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines. The generation module 204 is used to generate a test quality assessment report based on the incremental code coverage and the code change information. The test quality assessment report includes the uncovered changed code lines and the submitters corresponding to the uncovered changed code lines.

[0094] In one alternative embodiment, the acquisition module 201 is specifically used for: Access the local repository of the version control system that stores the target code version; Call the log interface of the local repository and set the file path to be analyzed, and obtain the commit history of the target code version under the file path from the local repository; Iterate through each commit object in the commit history, parse each commit object to extract commit metadata, including the committer; For each commit object, obtain the file snapshot corresponding to the commit object and the file snapshot corresponding to the previous commit object in the commit history from the local repository. Obtain the file content differences by comparing the file snapshots, and determine the lines of code that have changed under the file path based on the file content differences. The submitter in the submission metadata is identified as the submitter corresponding to the changed line of code, and the changed lines of code and their corresponding submitters are summarized to obtain the code change information.

[0095] In one alternative embodiment, the acquisition module 202 is specifically used for: The code coverage probe is loaded when the test environment starts. The code coverage probe modifies bytecode and inserts recording instructions during class loading. Execute test cases for the target code version, and during test execution, use the recording instruction to mark the execution status of each line of code in real time; After the test execution is completed, the execution status data is exported from the code coverage probe, and the execution status data is used to generate the code coverage data. The code coverage data contains identification information indicating whether each line of code was covered by the test execution.

[0096] In an alternative embodiment, the determining module 203 is specifically used for: Extract the changed code lines corresponding to the target code version from the code change information, and extract the identifier information of whether each code line corresponding to the target code version has been covered by test execution from the code coverage data; The modified code lines are matched with the identification information to determine the code lines in the modified code lines that are covered by the test execution and the code lines in the modified code lines that are not covered by the test execution. The number of lines covered is obtained by counting the number of lines of code covered by the test execution among the changed lines of code, and the total number of changed lines of code is obtained by counting the total number of changed lines of code. The incremental code coverage of the target code version is determined based on the ratio of the number of covered lines to the total number of changed lines.

[0097] In an alternative embodiment, the generation module 204 is specifically used for: Filter out the modified code lines that were not covered by the test execution from the code change information to obtain a set of uncovered code lines; Obtain the committer corresponding to each line of code in the set of uncovered lines of code from the code change information; The incremental code coverage, the set of uncovered code lines, and the committer corresponding to each code line are assembled according to a preset report template to generate the test quality assessment report.

[0098] In one alternative approach, it also includes: The inheritance module is used to obtain code coverage data of historical test tasks. If the current test task and the historical test task have the same project code and the code files have not changed, then the inheritance relationship between the current test task and the historical test task is established, and the code coverage data of the historical test task is inherited to the current test task.

[0099] In one alternative approach, it also includes: The comparison module is used to compare the incremental code coverage with a preset coverage threshold. When the incremental code coverage is lower than the preset coverage threshold, a release prohibition prompt message is generated and the release process is blocked.

[0100] It should be noted that the beneficial effects of the code coverage-based test quality assessment system 200 provided in the above embodiments are the same as those of the code coverage-based test quality assessment method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0101] The code coverage-based test quality assessment system 200 of the present invention can be a computer program (including program code) running on a computer device. For example, the code coverage-based test quality assessment system 200 of the present invention is an application software that can be used to execute the corresponding steps in the code coverage-based test quality assessment method of the present invention.

[0102] In some embodiments, the code coverage-based test quality assessment system 200 of the present invention can be implemented in a combination of hardware and software. As an example, the code coverage-based test quality assessment system 200 of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the code coverage-based test quality assessment method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0103] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0104] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned code coverage-based test quality assessment methods. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the code coverage-based test quality assessment method shown in any embodiment of the present invention by calling the computer program.

[0105] In one alternative embodiment, an electronic device is provided, such as Figure 21 As shown, Figure 21The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0106] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0107] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 21 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0108] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0109] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0110] Among them, electronic devices can also be terminal devices. A terminal device can be any terminal device that can install applications and access web pages through applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0111] It should be noted that, Figure 21 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0112] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described test quality assessment methods based on code coverage.

[0113] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0114] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the code coverage-based test quality assessment method described above.

[0115] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0116] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0117] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0118] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0119] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0120] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0121] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0122] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A test quality assessment method based on code coverage, characterized in that, include: Obtain code change information for the target code version in the version control system. The code change information includes the lines of code that have been changed and the committer corresponding to each line of code that has been changed. By deploying code coverage probes in the test environment, code coverage data of the target code version is collected during test execution. The code coverage data is used to identify whether each line of code is covered by the test execution. Based on the code change information and the code coverage data, the incremental code coverage of the target code version is determined. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines. Based on the incremental code coverage and the code change information, a test quality assessment report is generated. The test quality assessment report includes the uncovered changed code lines and the committers of the uncovered changed code lines.

2. The test quality assessment method based on code coverage according to claim 1, characterized in that, The steps to obtain code change information for the target code version in the version control system include: Access the local repository of the version control system that stores the target code version; Call the log interface of the local repository and set the file path to be analyzed, and obtain the commit history of the target code version under the file path from the local repository; Iterate through each commit object in the commit history, parse each commit object to extract commit metadata, including the committer; For each commit object, obtain the file snapshot corresponding to the commit object and the file snapshot corresponding to the previous commit object in the commit history from the local repository. Obtain the file content differences by comparing the file snapshots, and determine the lines of code that have changed under the file path based on the file content differences. The submitter in the submission metadata is identified as the submitter corresponding to the changed line of code, and the changed lines of code and their corresponding submitters are summarized to obtain the code change information.

3. The test quality assessment method based on code coverage according to claim 2, characterized in that, The steps of collecting code coverage data for the target code version during test execution using a code coverage probe deployed in the test environment include: The code coverage probe is loaded when the test environment starts. The code coverage probe modifies bytecode and inserts recording instructions during class loading. Execute test cases for the target code version, and during test execution, use the recording instruction to mark the execution status of each line of code in real time; After the test execution is completed, the execution status data is exported from the code coverage probe, and the execution status data is used to generate the code coverage data. The code coverage data contains identification information indicating whether each line of code was covered by the test execution.

4. The test quality assessment method based on code coverage according to claim 3, characterized in that, The step of determining the incremental code coverage of the target code version based on the code change information and the code coverage data includes: Extract the changed code lines corresponding to the target code version from the code change information, and extract the identifier information of whether each code line corresponding to the target code version has been covered by test execution from the code coverage data; The modified code lines are matched with the identification information to determine the code lines in the modified code lines that are covered by the test execution and the code lines in the modified code lines that are not covered by the test execution. The number of lines covered is obtained by counting the number of lines of code covered by the test execution among the changed lines of code, and the total number of changed lines of code is obtained by counting the total number of changed lines of code. The incremental code coverage of the target code version is determined based on the ratio of the number of covered lines to the total number of changed lines.

5. The test quality assessment method based on code coverage according to claim 4, characterized in that, The steps for generating a test quality assessment report based on the incremental code coverage and the code change information include: Filter out the modified code lines that were not covered by the test execution from the code change information to obtain a set of uncovered code lines; Obtain the committer corresponding to each line of code in the set of uncovered lines of code from the code change information; The incremental code coverage, the set of uncovered code lines, and the committer corresponding to each code line are assembled according to a preset report template to generate the test quality assessment report.

6. The test quality assessment method based on code coverage according to any one of claims 1 to 5, characterized in that, Also includes: Obtain code coverage data from historical test tasks. If the current test task has the same project code as the historical test task and the code files have not changed, then establish an inheritance relationship between the current test task and the historical test task, and inherit the code coverage data of the historical test task to the current test task.

7. The test quality assessment method based on code coverage according to claim 5, characterized in that, Also includes: The incremental code coverage is compared with a preset coverage threshold. When the incremental code coverage is lower than the preset coverage threshold, a release prohibition message is generated and the release process is blocked.

8. A test quality assessment system based on code coverage, characterized in that, include: The acquisition module is used to acquire code change information of the target code version in the version control system. The code change information includes the code lines that have been changed and the committer corresponding to each changed code line. The data collection module is used to collect code coverage data of the target code version during test execution by a code coverage probe deployed in the test environment. The code coverage data is used to identify whether each line of code is covered by the test execution. The determination module is used to determine the incremental code coverage of the target code version based on the code change information and the code coverage data. The incremental code coverage is used to characterize the proportion of the number of code lines covered by the test execution in the changed code lines to the total number of changed code lines. The generation module is used to generate a test quality assessment report based on the incremental code coverage and the code change information. The test quality assessment report includes the uncovered changed code lines and the submitters corresponding to the uncovered changed code lines.

9. An electronic device, characterized in that, The electronic device includes a processor coupled to a memory storing at least one computer program, which is loaded and executed by the processor to enable the electronic device to implement the code coverage-based test quality assessment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which, when executed by a processor, implements the code coverage-based test quality assessment method as described in any one of claims 1 to 7.

Images