Incremental code coverage rate determination method and device, equipment and storage medium

Abstract

The invention discloses an incremental code coverage rate determination method and device, equipment and a storage medium. The method comprises the following steps: in response to an incremental coverage rate determination request, obtaining service code information and coverage rate determination demand information submitted by a target user based on a front-end interface; determining a target service code according to the service code information, and determining at least one code change block according to the target service code; determining demand information and service code information according to the coverage rate, selecting a target code change block from the code change blocks, and determining a coverage rate code block corresponding to the target code change block; determining a target incremental coverage rate according to a first code block line corresponding to the coverage rate code block and a second code block line corresponding to the target code change block; and feeding back the target incremental coverage rate to the target user through the front-end interface. According to the technical scheme, the determination accuracy of the incremental code coverage rate is ensured, and meanwhile, the determination efficiency and flexibility of the incremental code coverage rate are considered.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular, to an incremental code coverage determination method, apparatus, device, and storage medium. Background Art

[0002] Incremental code coverage is a more practical coverage information derived from code coverage. During the normal iteration of a product, one often cares more about whether the newly added and modified parts of the code of an application service version are covered. If the incremental coverage is high, it can indicate that the functional testing of this version is comprehensive; if the incremental coverage is low, it can indicate that the functional testing of this version is lacking.

[0003] The life cycle of common frameworks for calculating incremental coverage or generating coverage reports is the same as the life cycle of the service application, that is, coverage collection starts when the project starts and ends when the project ends. However, in reality, a project may be released and tested dozens of times a day, and a test version may be iterated hundreds of times, and the number of finally obtained coverage reports is also hundreds. The existing incremental coverage calculation method is to summarize and merge the incremental coverage in hundreds of coverage reports to obtain the final incremental code coverage.

[0004] However, the above logic of summarizing and merging a large number of coverage reports is very complex, resulting in low flexibility and efficiency in determining incremental code coverage. Therefore, there is an urgent need to propose an incremental code coverage determination method that can ensure the accuracy of incremental code coverage while taking into account the determination efficiency of incremental code coverage and improving the determination flexibility of incremental code coverage. Summary of the Invention

[0005] The present invention provides an incremental code coverage determination method, apparatus, device, and storage medium to ensure the accuracy of incremental code coverage determination while taking into account the determination efficiency of incremental code coverage and improving the determination flexibility of incremental code coverage.

[0006] According to one aspect of the present invention, an incremental code coverage determination method is provided, and the method includes:

[0007] In response to an incremental coverage determination request, obtain service code information and coverage determination requirement information submitted by a target user based on a front-end interface;

[0008] Determine target service code according to the service code information, and determine at least one code change block according to the target service code;

[0009] Determine the requirement information and the service code information according to the coverage rate, select a target code change block from each of the code change blocks, and determine a coverage rate code block corresponding to the target code change block;

[0010] Determine a target incremental coverage rate according to a first code block line corresponding to the coverage rate code block and a second code block line corresponding to the target code change block;

[0011] Feed back the target incremental coverage rate to the target user through the front-end interface.

[0012] According to another aspect of the present invention, there is provided an incremental code coverage rate determination device, the device includes:

[0013] A request response module, configured to, in response to an incremental coverage rate determination request, obtain service code information and coverage rate determination requirement information submitted by a target user based on a front-end interface;

[0014] A code change block determination module, configured to determine a target service code according to the service code information, and determine at least one code change block according to the target service code;

[0015] A coverage code block determination module, configured to select a target code change block from each of the code change blocks according to the coverage rate determination requirement information and the service code information, and determine a coverage rate code block corresponding to the target code change block;

[0016] An incremental coverage rate determination module, configured to determine a target incremental coverage rate according to a first code block line corresponding to the coverage rate code block and a second code block line corresponding to the target code change block;

[0017] An incremental coverage rate feedback module, configured to feed back the target incremental coverage rate to the target user through the front-end interface.

[0018] According to another aspect of the present invention, there is provided an electronic device, the electronic device includes:

[0019] At least one processor; and

[0020] A memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the incremental code coverage rate determination method according to any embodiment of the present invention.

[0022] According to another aspect of the present invention, there is provided a computer-readable storage medium storing computer instructions for causing a processor to implement the incremental code coverage determination method according to any embodiment of the present invention when executed.

[0023] In the process of determining the incremental code coverage, the above technical solution selects the target code change block and determines the code block required for testing coverage by aggregating the coverage determination requirement information and service code information of the target users, and determines the incremental code coverage based on the target code change block and the coverage code block. In the whole determination process, not all the coverage data is used, but only the coverage data and code change blocks that meet the self-test requirements are determined, which reduces the determination efficiency of the incremental code coverage. The calculation process does not involve complex merging of a large amount of coverage data, but determines the incremental code coverage in combination with the actual functional test requirements, ensuring the accuracy of the incremental code coverage determination while taking into account the determination efficiency of the incremental code coverage, and improving the determination flexibility of the incremental code coverage.

[0024] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present invention, nor is it used to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. Brief Description of the Drawings

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0026] Figure 1A is a flowchart of an incremental code coverage determination method according to Embodiment 1 of the present invention;

[0027] Figure 1B is a schematic diagram of the process of project test iteration of an application service according to Embodiment 1 of the present invention;

[0028] Figure 2 is a flowchart of an incremental code coverage determination method according to Embodiment 2 of the present invention;

[0029] Figure 3 is a flowchart of an incremental code coverage determination method according to Embodiment 3 of the present invention;

[0030] Figure 4 is a schematic structural diagram of an incremental code coverage determination device according to Embodiment 4 of the present invention;

[0031] Figure 5 It is a schematic structural diagram of an electronic device for implementing the incremental code coverage determination method of the embodiments of the present invention. Specific embodiments

[0032] In order to enable those skilled in the art to better understand the solution of the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0033] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present invention described here can be implemented in an order other than those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily need to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0034] Embodiment 1

[0035] Figure 1A It is a flowchart of an incremental code coverage determination method provided in Embodiment 1 of the present invention. This embodiment is applicable to the situation of calculating the incremental code coverage of service codes within the scope of functional testing to be performed during the development iteration of an application service project. This method can be executed by an incremental code coverage determination device, which can be implemented in the form of hardware and / or software, and the incremental code coverage determination device can be configured in an electronic device, for example, it can be configured in a server. As Figure 1A shown, this method is applied to the server and includes:

[0036] S110. In response to an incremental coverage determination request, obtain service code information and coverage determination requirement information submitted by a target user based on a front-end interface.

[0037] S120. Determine target service codes according to the service code information, and determine at least one code change block according to the target service codes.

[0038] S130. Determine the requirement information and service code information according to the coverage rate, select the target code change block from each code change block, and determine the coverage rate code block corresponding to the target code change block.

[0039] S140. Determine the target incremental coverage rate according to the first code block line corresponding to the coverage rate code block and the second code block line corresponding to the target code change block.

[0040] S150. Feedback the target incremental coverage rate to the target user through the front-end interface.

[0041] It should be noted that the incremental code coverage rate can indicate whether the newly added and modified parts of the code in a version of an application service during the development process are covered, and this is used as a basis to judge the test effect of this version iteration. If the incremental code coverage rate is high, it means that the functional test of this version is comprehensive; if the incremental code coverage rate is low, it means that the functional test of this version is not comprehensive.

[0042] The existing calculation rule for the incremental code coverage rate is the ratio of the number of executed code lines to the number of modified code lines. It should be noted that the life cycle of the existing coverage report generation framework is the same as that of the service application, that is, the collection of coverage data starts when the project starts and ends when the project ends, and a coverage collection corresponding to this version will be generated every time the service application project undergoes a version iteration. However, during the iteration cycle of the entire service application project, the code run after each release is often different. Therefore, the coverage data after each release is generated based on the code of different versions, and the coverage data obtained from the tests after each release is inconsistent.

[0043] When a user selects to determine the incremental coverage rate of the service application code for a certain release, usually the coverage data obtained from the test of this release and the coverage data obtained from the tests of historical releases are merged to obtain the incremental code coverage rate. However, in reality, a service application may be released dozens of times a day, and the coverage data to be merged may be hundreds. The difficulty of merging based on hundreds of data is large, and the merging efficiency is very low.

[0044] Usually, during the process of detecting the comprehensiveness of functional tests based on the incremental code coverage rate, the key points to be concerned about are which functions among all the functions developed by the application service within a certain time period are tested and which functions are not tested. However, among several coverage reports, it is impossible to accurately locate the truly required coverage report and the coverage data to be used based on the functional test requirements. The results obtained only through the complex merging method of the existing coverage reports are often not the results that testers are concerned about, and there is a deviation from their expected test requirements.

[0045] Among them, the incremental coverage determination request can be a request for determining the incremental code coverage of an application service, which can be initiated by a target user based on a front-end interface. The target user can be relevant personnel with an incremental code coverage request or an incremental code coverage requirement, such as a functional tester, etc.

[0046] The service code information may include the service code identifier selected by the target user. It should be noted that since the incremental coverage is a relative quantity, that is, the incremental code coverage within a certain time range or within a certain release or submission range, the service code identifier included in the service code information can represent the calculation range of the incremental coverage selected by the target user.

[0047] Furthermore, as Figure 1B shown in the schematic diagram of the process of project testing iteration of the application service. Among them, the first row is the submission timeline, which represents the submission order of relevant technical personnel on Git (a distributed version control system) from left to right. Among them, the numbers represent submission identifiers (IDs), which are used to represent the uniqueness of the submission in the Git system. That is, in the actual time order, relevant technical personnel pushed 1 to 8 code submissions. The second row represents the versions of the application service, that is, the project release of the application service was carried out at the 3rd submission, and the version number was V1.0; the project release of the application service was carried out at the 5th submission, and the version number was V1.1; and the project release of the application service was carried out at the 7th submission, and the version number was V1.2. Among them, the gray color represents the release submission, that is, the project was packaged and released at this submission; the white color represents only the submission without release. The third row identifies the coverage data set collected for the corresponding version, and the collection method can be to collect the coverage data using an existing framework. That is, the coverage data set 1 was collected at the V1.0 version; the coverage data set 2 was collected at the V1.1 version; and the coverage data set 3 was collected at the V1.2 version.

[0048] The target user can specify the test range, such as performing a comprehensive function test between the service code of the 2nd submission and the service code of the 5th submission. The information corresponding to the test range specified by the target user can be included in the service code information. For example, the service code information includes the service code identifier of the 2nd submission and the service code identifier of the 5th submission.

[0049] Among them, the coverage determination requirement information can be the test requirement for the incremental code coverage of the target user, such as the incremental code method coverage, incremental code class coverage, and incremental code package coverage that the target user expects to test, etc.

[0050] The service code identifier corresponding to the test range specified by the target user can be obtained from the service code information; the service code corresponding to the target service identifier is determined as the target service code. According to the target service code, at least one code change block is determined. It should be noted that when the target user specifies the test range, two service code identifiers need to be determined, so as to determine a test range based on the two service code identifiers. For example, based on the above Figure 1B , when the target user wants to perform a comprehensive function test between the service code submitted for the second time and the service code submitted for the fifth time, the service code identifier of the service code submitted for the second time and the service code identifier of the service code submitted for the fifth time need to be submitted.

[0051] In an alternative embodiment, the target service code includes a first service code and a second service code; wherein, the first service code is to submit an unpublished code or a published code; the second service code is only to submit a published code, and the code submission time of the second service code is not earlier than that of the first service code; correspondingly, according to the target service code, determining at least one code change block includes: performing code difference analysis on the first service code and the second service code to obtain code difference information between the first service code and the second service code; determining at least one code change block according to the code difference information.

[0052] It should be noted that in the process of selecting the test range in the present invention, the range starting point can be to submit a published code or an unpublished code, while the range ending point can only be selected to submit a published code. Among them, the first service code is the service code corresponding to the service code identifier of the range starting point; the second service code is the service code corresponding to the service code identifier of the range ending point. For example, continuing the above example, if the target user expects to perform a comprehensive function test between the service code submitted for the second time and the service code submitted for the fifth time, then the first service code is the service code submitted for the second time; the second service code is the service code submitted for the fifth time. Among them, the service code submitted for the second time is an unpublished code; the service code submitted for the fifth time is a published code.

[0053] Among them, the code submission time of the second service code is not earlier than that of the first service code, that is, the first service code and the second service code can be the same. For example, the test range determined by the target user is only a certain submitted published code, such as Figure 1B , the input of the target user can be and only be that the service code submitted for the fifth time is a published code.

[0054] If the first service code is the same as the second service code, update the first service code or the second service code to the first service code, and update the historical service code corresponding to the first service code or the second service code in the previous submission count cycle to the second service code. For example, if the first service code or the second service code is the service code of the 5th submission, then use the service code of the 5th submission as the first service code, and the corresponding historical service code is the service code of the 4th submission, and use the service code of the 4th submission as the second service code.

[0055] Perform code difference analysis between the first service code and the second service code to obtain the code difference information between the first service code and the second service code. Specifically, a Diff (difference comparison) operation can be performed between the first service code and the second service code to generate code difference information. Among them, the Diff operation can be implemented based on the longest common subsequence algorithm (LCS, Longest Common Subsequence) or the Git logical mechanism. Implementing based on the Git logic can specifically include file path comparison, file type identification, line-level hash calculation, and difference block generation, etc. Among them, the code difference information is used to describe the modified content information between the first service code and the second service code. For example, the code difference information can include file change information and code block change information, etc. Among them, the file change information can include the file path to which the changed code line belongs; the code block change information can include the line information to which the changed code block belongs, etc.

[0056] By parsing the code difference information, at least one code change block where the first service code and the second service code have changed can be determined. A code change block is a code line where the first service code and the second service code have changed, and a code block composed of consecutive changed code lines is a code change block. Different code change blocks may belong to the same or different methods, classes, and files.

[0057] According to the coverage requirement information, select a target code change block from at least one changed code block. For example, the coverage requirement information can specify the information of the code block, method, or class that wants to be tested, and select the code change block related to the code block, method, or class that wants to be tested from the code change blocks as the target code change block. Determine the coverage data under the test version corresponding to the target code change block, and determine the coverage code block related to the target code change block from the coverage data.

[0058] Take the ratio between the first code block line corresponding to the coverage code block and the second code block line corresponding to the target code change block as the target incremental coverage rate, and feedback the target incremental coverage rate to the target user through the front-end interface.

[0059] In the technical solution of the embodiment of the present invention, the requirement information is determined by obtaining the service code information and the coverage rate submitted by the target user based on the front-end interface; according to the service code information, the target service code is determined, and according to the target service code, at least one code change block is determined; according to the coverage rate, the requirement information and the service code information, the target code change block is selected from each code change block, and the coverage rate code block corresponding to the target code change block is determined; according to the first code block line corresponding to the coverage rate code block and the second code block line corresponding to the target code change block, the target incremental coverage rate is determined; and the target incremental coverage rate is fed back to the target user through the front-end interface. In the process of determining the incremental code coverage rate, the above technical solution determines the requirement information and the service code information by collecting the coverage rate of the target user, selects the target code change block and determines the coverage rate code block required for testing, and determines the incremental code coverage rate based on the target code change block and the coverage rate code block. In the whole determination process, not all coverage rate data is used, but only the coverage rate data and code change blocks that meet the own test requirements are determined, which reduces the determination efficiency of the incremental code coverage rate. The calculation process does not perform complex merging on a large amount of coverage rate data, but determines the incremental code coverage rate in combination with the actual functional test requirements, ensuring the accuracy of the determination of the incremental code coverage rate while taking into account the determination efficiency of the incremental code coverage rate, and improving the determination flexibility of the incremental code coverage rate.

[0060] Embodiment 2

[0061] Figure 2 FIG. is a flowchart of a method for determining incremental code coverage rate provided by Embodiment 2 of the present invention. On the basis of the above technical solutions, this embodiment is optimized and improved.

[0062] Further, the step of "determining the requirement information and the service code information according to the coverage rate, selecting the target code change block from each code change block, and determining the coverage rate code block corresponding to the target code change block" is refined into "determining the requirement information according to the coverage rate, selecting the target code change block from each code change block, and determining the code change block operation object corresponding to the target code change block; determining the target code submission identifier according to the code submission record corresponding to the code change block operation object; based on the target code submission identifier and the service code information, selecting the target coverage rate data set from at least one coverage rate data set; selecting the target coverage rate data associated with the code change block operation object from the target coverage rate data set, and performing data merging on the target coverage rate data to obtain the coverage rate code block." to improve the determination method of the coverage rate code block.

[0063] Refine the step of "determining the target incremental coverage rate based on the first code block lines corresponding to the coverage rate code block and the second code block lines corresponding to the target code change block" into "determining the intersection code block lines between the first code block lines corresponding to the coverage rate code block and the second code block lines corresponding to the target code change block; determining the ratio between the intersection code block lines and the second code block lines as the target incremental coverage rate." to improve the determination method of the target incremental coverage rate.

[0064] It should be noted that for the parts not detailed in the embodiments of the present invention, reference can be made to the descriptions of other embodiments. As Figure 2 shown, the method includes the following specific steps:

[0065] S210. In response to the incremental coverage rate determination request, obtain the service code information and coverage rate determination requirement information submitted by the target user based on the front-end interface.

[0066] S220. Determine the target service code according to the service code information, and determine at least one code change block according to the target service code.

[0067] S230. Select the target code change block from each code change block according to the coverage rate determination requirement information, and determine the code change block operation object corresponding to the target code change block.

[0068] Among them, the coverage rate determination requirement information may include the test requirements of the target user. For example, it may be the incremental method coverage rate, incremental class coverage rate, or incremental package coverage rate expected to be calculated, etc. Different requirements correspond to different data required for calculation.

[0069] Exemplarily, if it is determined based on the coverage rate determination requirement information that the target user expects to calculate the incremental method coverage rate and the method identifier to be tested is specifically stated, then select the code change block corresponding to the corresponding method identifier from the code change blocks as the target code change block. If the specific method identifier is not stated, then all code change blocks are used as the target code change blocks. The method code block to which the target code change block belongs is used as the code change block operation object. The number of target code change blocks can be one or more. For example, for any target code change block m, the code location is from line 200 to line 210. If the method containing the code from line 200 to line 210 is method M, then method M is used as the code change block operation object of the target code change block m.

[0070] For another example, if the target user expects to calculate the incremental class coverage rate and specifically specifies the class identifier to be tested, then the code change block corresponding to the corresponding class identifier is selected from the code change blocks as the target code change block. If no specific class identifier is specified, all code change blocks are used as the target code change blocks. The class code block to which the target code change block belongs is used as the code change block operation object. The number of target code change blocks can be one or more. For example, for any target code change block, the line numbers of its code are from line 200 to line 210. If the class containing the code from line 200 to line 210 is class M, then class M is used as the code change block operation object of the target code change block m. It should be noted that a class may contain one or more target code change blocks. For example, if the target code change block m and the target code change block n belong to the same class M, then the target code change blocks corresponding to the code change block operation object M are n and m.

[0071] S240. Determine the target code submission identifier according to the code submission record corresponding to the code change block operation object.

[0072] Among them, the code submission record can be obtained by extracting through the blame command of the Git system. The code submission record may include the submission records of each line of code corresponding to the code change block operation, including submission time information, submission identifier information, etc.

[0073] In an alternative embodiment, determining the target code submission identifier according to the code submission record corresponding to the code change block operation object includes: selecting target submission records that meet the preset submission time judgment condition from the code submission record, and determining the code submission identifier corresponding to the target submission record as the target code submission identifier.

[0074] Among them, the preset submission time judgment condition may specifically be to judge whether the code is the latest code submission time.

[0075] In a specific embodiment, if the code behavior corresponding to the code change block operation object is from line 150 to line 200, the obtained code commit record includes the commit time information and the code commit identification information corresponding to each line of code from line 150 to line 200. The code commit identification information is used to represent the uniqueness of the code commit identification (ID). For example, lines 150 to 155 are from the commit of "a43783cc" at 09:30 on January 22, 2025; lines 160 to 170 are from the commit of "a43785cc" at 10:30 on January 22, 2025. Among them, "a43783cc" and "a43785cc" are code commit identifications. Therefore, the target commit record that meets the latest code commit time is the commit of lines 160 to 170 from "a43785cc" at 10:30 on January 22, 2025. Correspondingly, "a43785cc" is used as the target code commit identification. According to this target code commit identification, the specific commit cycle of the code change operation object can be determined. For example, the last commit cycle is the 4th commit.

[0076] S250. Select a target coverage data set from at least one coverage data set according to the target code commit identification and based on the service code information.

[0077] It should be noted that since a coverage data report for the current version is generated each time the application service releases a project, for any application service, different versions correspond to different coverage data reports, and the coverage data reports of each version can form the coverage data set of the application service. It can be understood that there is no coverage data report that can measure the function test scope within the scope concerned or expected by the target user for function testing. Usually, only the coverage data reports within this scope can be merged. However, not all of the coverage data reports involved in these reports are relevant to the purpose of this function test. Therefore, further screening of the coverage data is required.

[0078] In an alternative embodiment, selecting a target coverage data set from at least one coverage data set according to the target code commit identification and based on the service code information includes: selecting at least one reference coverage data set from at least one coverage data set according to the service identification in the service code information; the coverage data set includes at least one reference coverage data set corresponding to the service code that has been released in the commit; the reference coverage data set includes the coverage data corresponding to the service code that has been released in the commit; and selecting the target coverage data set from each reference coverage data set according to the service code commit identification to which the target service code in the service code information belongs and based on the target code commit identification.

[0079] Among them, the coverage data sets or coverage data reports corresponding to different application service items can be pre-associated and stored in a pre-constructed database. Specifically, the application service identifier corresponding to the application service can be associated and stored with the coverage data sets under different submission versions of the application service. That is, one application service identifier corresponds to multiple coverage data sets, and each coverage data set belongs to a different submission version of the application service.

[0080] According to the service identifier in the service code information, the coverage data set of the service application corresponding to the service identifier can be located from the database, and the located coverage data set is used as the reference coverage data set. For any reference coverage data set, the reference coverage data set is the coverage data set obtained by calculating the service code in the corresponding submission and released test cycle of the service application. The reference coverage data set includes the coverage data corresponding to the submitted and released service code.

[0081] According to the service code submission identifier and the target code submission identifier of the second service code in the target service code in the service code information, the target coverage data set is selected from each reference coverage data set.

[0082] For example, the reference coverage data sets include the reference coverage data set corresponding to the V1.0 version submitted for the second time of the service application, the reference coverage data set corresponding to the V1.1 version submitted for the fourth time, the reference coverage data set corresponding to the V1.2 version submitted for the seventh time, and the reference coverage data set corresponding to the V1.3 version submitted for the eighth time. Among them, the target service code includes the first service code and the second service code, and according to the service code identifier of the first service code, it can be determined that the first service code belongs to the service code submitted for the third time, and according to the service code identifier of the second service code, it can be determined that the second service code belongs to the service code submitted for the eighth time. If the service code corresponding to the target code submission identifier is the service code submitted for the fifth time, the target coverage data set is the reference coverage data set corresponding to the V1.2 version submitted for the seventh time and the reference coverage data set corresponding to the V1.3 version submitted for the eighth time.

[0083] S260. Select the target coverage data associated with the code change block operation object from the target coverage data set, and perform data merging on the target coverage data to obtain the coverage code block.

[0084] For example, the operation object of the code change block is a method object, and the corresponding code lines are from line 100 to line 150. The target coverage data set includes set A, set B, and set C. Among them, for set C, for any target coverage data set, determine the target coverage data related to lines 100 to 150. For example, according to set A, it can be determined that the target coverage data is that the code lines from 110 to 140 are executed once; according to set B, it can be determined that the target coverage data is that the code lines from 120 to 140 are executed twice; according to set C, it can be determined that the target coverage data is that the code lines from 120 to 130 are executed once. By merging the target coverage data in set A, set B, and set C, the coverage code block can be obtained as the code lines from 110 to 140. Among them, the number of times a specific line of code is executed can be used as additional data for the final target incremental coverage rate.

[0085] S270. Determine the intersection code block lines between the first code block lines corresponding to the coverage code block and the second code block lines corresponding to the target code change block.

[0086] Exemplarily, if the first code block lines corresponding to the coverage code block are the code lines from 110 to 140, and the second code block lines corresponding to the target code change block are the code lines from 120 to 130, then the intersection code block lines are the code lines from 120 to 130.

[0087] S280. Determine the ratio between the intersection code block lines and the second code block lines as the target incremental coverage rate.

[0088] Exemplarily, if the intersection code block lines are the code lines from 120 to 130, and the second code block lines are the code lines from 120 to 130, then the ratio between the intersection code block lines and the second code block lines is 100%, that is, the target incremental coverage rate is 100%. If the intersection code block lines are the code lines from 120 to 125, and the second code block lines are the code lines from 120 to 130, then the ratio between the intersection code block lines and the second code block lines is 50%, that is, the target incremental coverage rate is 50%.

[0089] S290. Feedback the target incremental coverage rate to the target user through the front-end interface.

[0090] The technical solution of this embodiment determines the requirement information according to the coverage rate, selects the target code change block from each code change block, and determines the code change block operation object corresponding to the target code change block; determines the target code submission identifier according to the code submission record corresponding to the code change block operation object; selects the target coverage rate data set from at least one coverage rate data set based on the service code information according to the target code submission identifier; selects the target coverage rate data associated with the code change block operation object from the target coverage rate data set, and performs data merging on the target coverage rate data to obtain the coverage rate code block. The above technical solution does not obtain the coverage rate code block by simply merging the coverage rate data reports involved in the test scope, but first filters the coverage rate data, selects the coverage rate data related to the test scope, and merges the filtered coverage rate data to determine the coverage rate code block. The above method improves the screening accuracy and screening efficiency of the coverage rate code block. In addition, by determining the intersection code block line between the first code block line corresponding to the coverage rate code block and the second code block line corresponding to the target code change block, and determining the ratio between the intersection code block line and the second code block line as the target incremental coverage rate, the determination accuracy of the incremental coverage rate is improved, so that the incremental coverage rate can more accurately represent the comprehensiveness and accuracy of the functional test of the expected functional test scope.

[0091] It should be noted that the coverage rate data set obtained during the selection process of the coverage rate data is pre-stored in the database and can be directly obtained subsequently. Therefore, on the basis of the above solution, this embodiment also provides a generation method for the coverage rate data set. The generation method of the coverage rate data set is as follows:

[0092] When the service application project is started, the Agent program starts to run, reads the environment information of the environment to which the service application project belongs, determines the instance identifier and service identifier corresponding to the service application project, and uploads the environment information, instance identifier and service identifier to the server; the Agent program performs enhancement processing on the project bytecode of the service application project, obtains the code execution information of the service application project, and determines the coverage rate data according to the code execution information; when the preset data upload cycle judgment condition is met, uploads the coverage rate data to the server for the server to generate a coverage rate data set of the coverage rate data under different data upload cycles, and associates and stores the coverage rate data set with its corresponding environment information, instance identifier and service identifier.

[0093] Specifically, pre-configure the Maven plug-in in the application service project, and add the version information of the project in the current release cycle to the manifest file of the JAR package. Among them, the version information may include the branch ID, commit ID, repository ID, group ID, etc. of the project where the service application is located. Among them, the manifest file is the carrier of the JAR package metadata, and can be read by the Agent through the Package.getPackage().getImplementationVersion() method later.

[0094] When the application service project runs, mount the agent (JAVA Agent technology). The Agent will start together with the project as a server application and run in the same JVM. When the Agent starts, it reads the environment information or machine information of the project to which the service application belongs, as well as the version information in the manifest file, and generates an instance ID for the running project. This instance ID can represent the uniqueness of the running application service project. The Agent uploads the environment information, instance identifier, and service identifier to the server.

[0095] Among them, the upload cycle judgment condition can be preset according to actual needs. For example, it can be to upload information when a preset timing time or preset time is met.

[0096] The Agent enhances the project bytecode, which can also be called the instrumentation technology, obtains the code execution information executed by the project of the running application service, and determines the coverage rate data according to the code execution information. The Agent can regularly push the coverage rate information to the server application through the http interface and finally store it in the pre-constructed ElasticSerarch database for query use. The server generates a coverage rate data set of the coverage rate data under different data upload cycles, and associates and stores the coverage rate data set with its corresponding environment information, instance identifier, and service identifier.

[0097] Embodiment 3

[0098] Based on the above embodiment, this embodiment also provides a preferred example. This embodiment includes two parts, namely the coverage rate data collection part and the incremental code coverage rate calculation part.

[0099] The determination process for the coverage rate collection part is as follows:

[0100] Step a, configure the Maven plug-in in the application service project, and add the version information of the project released in the current cycle to the manifest file of the Jar package.

[0101] Step b: When the project runs, mount the Agent (Java Agent technology). The Agent, as a server - side application, starts together with the project and runs in the same JVM.

[0102] Step c: When the Agent starts, it reads the project's environment information or machine information, as well as the version information in the manifest file, and uses the version information and machine information as the instance ID of the project running this time.

[0103] The project running at this time is called an instance, and its unique identifier is the instance ID (instanceid).

[0104] Step d: The Agent enhances the project bytecode to obtain the line - by - line information of the code executed by the running project.

[0105] The above - mentioned technology for enhancing project bytecode can also be called bytecode instrumentation technology.

[0106] Step e: Subsequently, the Agent will regularly push the calculated coverage information to our server - side application through the http interface and finally store it in the ElasticSerarch database for query use.

[0107] It should be noted that in addition to the coverage data, the Agent also pushes the instance ID, environment information, service identifier, etc. And when uploading the coverage data, the Agent can upload it regularly or immediately after obtaining the coverage data. The coverage data uploaded by the Agent can be class - level coverage data, and this class - level coverage data can include specific coverage information, such as specific line numbers of code and the execution times corresponding to the corresponding line numbers of code.

[0108] For the calculation process of incremental code coverage, this embodiment is described by taking a specific example. As Figure 3 shown in the flowchart of a method for determining incremental code coverage. This example takes Figure 1B the schematic diagram of the project test iteration of the application service shown as an example. The method includes the following steps:

[0109] S1: The target user submits service code information and coverage determination requirement information on the front - end page. According to the service code information, the first service code and the second service code are determined.

[0110] Specifically, assume that the service code information submitted by the target user on the front - end page is commit2 and commit7. As Figure 1BAs shown in the figure, commit2 corresponds to the second submission of the service application, and commit7 corresponds to the seventh submission of the service application. The seventh submission is a released submission, and the corresponding version number is V1.2. Assume that the coverage calculation requirement corresponding to the coverage determination requirement information of the target user is to calculate the incremental method coverage. Assume that the service code corresponding to commit2 is the first service code, and the service code corresponding to commit7 is the second service code.

[0111] S2. Calculate the difference between the first service code and the second service code to obtain code difference information, and determine at least one code change block based on the code difference information.

[0112] By calculating the difference between the first service code and the second service code, it is possible to determine which files, which classes, which methods, and which lines have been modified during the entire period from commit2 to commit7. All the modification information is reflected in the code difference information. Therefore, at least one code change block can be determined based on the code difference information. A code change block can be the code change interval in a class file. For example, if code is added / modified on lines 200 - 210 of a certain class file, then lines 200 - 210 are a code change block. The number of code change blocks in a class file can be one or more, and the number of class files with changes can also be one or more.

[0113] S3. Select target code change blocks from each code change block according to the coverage determination requirement information, and determine the code change block operation objects corresponding to the target code change blocks.

[0114] Since the coverage calculation requirement of the target user determined according to the above coverage determination requirement information is to calculate the incremental method coverage, the method objects to which each code change block belongs are determined. For example, if the determined code change blocks include code change block a, code change block b, and code change block c, the method to which code change block a belongs is method A, the method to which code change block b belongs is method B, and the method to which code change block c belongs is method C. If the specific method to be calculated is not clearly indicated in the coverage determination requirement information, then by default, the incremental method coverage calculation is performed on all the determined methods, and all code change blocks are used as target code change blocks. The method object to which the target code change itself belongs is the code change block operation object, that is, method A, method B, and method C.

[0115] S4. Select the record with the latest submission time from the code submission records as the target submission record, and determine the code submission identifier corresponding to the target submission record as the target code submission identifier.

[0116] For any of the code change block operation objects determined above, for example, taking Method B as an example, through the existing query function, such as the blame command function of Git, determine the code commit records of the code lines in Method B. The code commit record may include the commit time of the code line and the code commit identifier. According to the commit time of each code line, determine the code line of the last valid commit, and use the code commit identifier of this code line as the target code commit identifier; according to the target code commit identifier, determine the corresponding number of commits. Suppose the last commit of Method B is the 4th commit, then it can be stated that the function and implementation of Method B remain completely unchanged from the 4th commit to the 7th commit. The last commit of the code can be understood as a commit that has an actual functional impact on the code.

[0117] It should be noted here that the purpose of taking the last commit is as follows: The last commit can determine from which commit the last modification of this Method B comes, and at the same time can also indirectly indicate that from the last commit (the 4th commit) to the present (the 7th commit corresponding to commit c), the functional implementation of Method B has not changed at all. And it is generally considered that if the implementation of a method remains completely unchanged (none of the lines have changed), no matter how the external conditions change, the function implemented by this method remains unchanged. Therefore, if the implementation of a method is unchanged, at this time, no matter how the entire project is iterated, the coverage data for this method is valid.

[0118] S5. Select a target coverage data set from at least one coverage data set according to the target code commit identifier and the service code identifier of the second service code.

[0119] Continuing from the previous time, according to the target code commit identifier, it can be determined that the latest commit of Method B is the 4th commit. The commit corresponding to the service code identifier of the second service code is the 7th commit. As Figure 1B shown, it can be determined that the coverage data sets involved from the 4th commit to the 7th commit include Coverage Data Set 2 and Coverage Data Set 3. The implementation of Method B has not changed during the period from the 4th commit to the 7th commit. Then, the coverage data for Method B recorded in Coverage Data Set 2 and Coverage Data Set 3 are both valid coverage data for Method B. Therefore, the target coverage data set is Coverage Data Set 2 and Coverage Data Set 3.

[0120] S6. Select the target coverage data associated with the code change block operation object from the target coverage data set, and perform data merging on the target coverage data to obtain a coverage code block.

[0121] Specifically, continuing with the above example, for coverage data set 2 or coverage data set 3, select the target coverage data related to method B from the corresponding coverage data set. For example, if the code lines corresponding to method B are from line 150 to line 200, then the coverage data related to lines 150 to 200 in the corresponding coverage data set is used as the target coverage data. For example, it is recorded in coverage data set 2 that the code lines from 160 to 170 are executed 2 times, and it is recorded in coverage data set 3 that the code lines from 150 to 180 are executed 1 time. Then, the two target coverage data are merged, and it can be obtained that the coverage code block is from 150 to 180. In addition, the additional information can also be obtained: the code lines from 150 to 160 are executed 1 time; the code lines from 160 to 170 are executed 3 times; the code lines from 170 to 180 are executed 1 time.

[0122] S7. Determine the target incremental coverage rate according to the code block lines corresponding to the coverage code block and the code block lines corresponding to the target code change block.

[0123]

[0124] Continuing with the above example, if the code lines of the coverage code block are from line 150 to line 180, and the code lines of the changed code block are from line 160 to line 170, then the intersection of the code lines of the coverage code block and the code lines of the target code change block is from line 160 to line 170, and the target incremental coverage rate is 100%.

[0125] Similarly, based on the same above method, the incremental class coverage rate, incremental package coverage rate or incremental file coverage rate, etc. can also be determined.

[0126] In the conventional method of calculating incremental coverage rate, often only the coverage data when the current application is running (coverage data set 3 corresponding to version V1.2 under the 7th submission times) is taken to calculate the coverage rate. This approach will cause the test statistics in the old version to be not counted. That is, it has been tested in version V1.0 and this function has not changed, but it is not calculated when calculating the incremental coverage rate in version V1.3. In this way, it is impossible to accurately count the coverage rate of all functions in the entire version iteration.

[0127] However, in the method of calculating incremental coverage rate of the present invention, the test coverage data is more accurately located, not only the coverage data when running. Because there is often a part of valid data in the historical coverage data. That is, from the time when the method does not change (coverage calculation is accurate to the class level), all subsequent coverage data can represent the effective test of this method. That is, to make the entire incremental coverage rate more accurate and the coverage rate higher. To prevent the situation that the function has been tested but it is said that it has not been measured.

[0128] Furthermore, during the process of calculating the incremental code coverage rate of the present invention, it can be visually reflected in the form of code coloring, so that the target user can easily locate the changed code blocks. During the whole process, whether it is the changed code block lines or the changed classes and methods, code coloring can be performed, which is convenient for the target user to accurately locate in a visual way.

[0129] Embodiment 4

[0130] Figure 4 FIG. is a schematic structural diagram of an incremental code coverage rate determination device provided in Embodiment 4 of the present invention. An incremental code coverage rate determination device provided in an embodiment of the present invention is applicable to the situation of calculating the incremental code coverage rate of service codes within the range of expected functional testing during the development iteration process of an application service project. The incremental code coverage rate determination device can be implemented in the form of hardware and / or software, such as Figure 4 shown, the device specifically includes: a request response module 401, a code change block determination module 402, a covered code block determination module 403, an incremental coverage rate determination module 404, and an incremental coverage rate feedback module 405. Among them,

[0131] The request response module 401 is configured to, in response to an incremental coverage rate determination request, obtain service code information and coverage rate determination requirement information submitted by a target user based on a front-end interface;

[0132] The code change block determination module 402 is configured to determine target service codes according to the service code information, and determine at least one code change block according to the target service codes;

[0133] The covered code block determination module 403 is configured to select a target code change block from each of the code change blocks according to the coverage rate determination requirement information and the service code information, and determine a covered code block corresponding to the target code change block;

[0134] The incremental coverage rate determination module 404 is configured to determine a target incremental coverage rate according to a first code block line corresponding to the covered code block and a second code block line corresponding to the target code change block;

[0135] The incremental coverage rate feedback module 405 is configured to feedback the target incremental coverage rate to the target user through the front-end interface.

[0136] In the process of determining the incremental code coverage rate, the above technical solution determines the coverage rate determination requirement information and service code information of the target users, selects the target code change blocks and determines the coverage rate code blocks required for testing, and determines the incremental code coverage rate based on the target code change blocks and the coverage rate code blocks. In the whole determination process, not all the coverage rate data is used, but only the coverage rate data and code change blocks that meet the own test requirements are determined, which reduces the determination efficiency of the incremental code coverage rate. The calculation process does not perform complex merging of a large amount of coverage rate data, but determines the incremental code coverage rate in combination with the actual functional test requirements, ensuring the accuracy of the determination of the incremental code coverage rate while taking into account the determination efficiency of the incremental code coverage rate, and improving the determination flexibility of the incremental code coverage rate.

[0137] Optionally, the coverage code block determination module 403 includes:

[0138] A target code block determination unit, configured to select a target code change block from each of the code change blocks according to the coverage rate determination requirement information, and determine a code change block operation object corresponding to the target code change block;

[0139] A target submission identifier determination unit, configured to determine a target code submission identifier according to a code submission record corresponding to the code change block operation object;

[0140] A target set determination unit, configured to select a target coverage rate data set from at least one coverage rate data set based on the service code information according to the target code submission identifier;

[0141] A target coverage rate data selection unit, configured to select target coverage rate data associated with the code change block operation object from the target coverage rate data set, and perform data merging on the target coverage rate data to obtain a coverage rate code block.

[0142] Optionally, the target submission identifier determination unit is specifically configured to:

[0143] Select a target submission record that meets a preset submission time judgment condition from the code submission record, and determine the code submission identifier corresponding to the target submission record as the target code submission identifier.

[0144] Optionally, the target set determination unit is specifically configured to:

[0145] Select at least one reference coverage rate data set from at least one coverage rate data set according to the service identifier in the service code information; the coverage rate data set includes at least one reference coverage rate data set corresponding to a submitted and released service code; the reference coverage rate data set includes coverage rate data corresponding to a submitted and released service code;

[0146] Based on the service code submission identifier to which the target service code in the service code information belongs, select a target coverage data set from each of the reference coverage data sets based on the target code submission identifier.

[0147] Optionally, the target service code includes a first service code and a second service code; the first service code is for submitting non-released code or released code; the second service code is only for submitting released code, and the code submission time of the second service code is not earlier than that of the first service code; correspondingly, the code change block determination module 402 is specifically configured to:

[0148] Perform code difference analysis on the first service code and the second service code to obtain code difference information between the first service code and the second service code;

[0149] Determine at least one code change block according to the code difference information.

[0150] Optionally, the incremental coverage determination module 404 is specifically configured to:

[0151] Determine the intersection code block lines between the first code block lines corresponding to the coverage code block and the second code block lines corresponding to the target code change block;

[0152] Determine the ratio between the intersection code block lines and the second code block lines as the target incremental coverage.

[0153] Optionally, the generation method of the coverage data set is as follows:

[0154] When the service application project is started, the Agent program starts to run and reads the environment information of the environment to which the service application project belongs, and determines the instance identifier and service identifier corresponding to the service application project, and uploads the environment information, instance identifier and service identifier to the server;

[0155] The Agent program performs enhancement processing on the project bytecode of the service application project, obtains the code execution information of the service application project, and determines the coverage data according to the code execution information;

[0156] When the preset data upload period judgment condition is met, upload the coverage data to the server for the server to generate a coverage data set of the coverage data under different data upload periods, and associate and store the coverage data set with its corresponding environment information, instance identifier and service identifier.

[0157] The incremental code coverage determination device provided by the embodiments of the present invention can execute the incremental code coverage determination method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects for executing the method.

[0158] Embodiment 5

[0159] Figure 5 FIG. shows a schematic structural diagram of an electronic device 50 that can be used to implement the embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as, for example, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as, for example, personal digital processors, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0160] As Figure 5 shown, the electronic device 50 includes at least one processor 51, and a memory communicatively connected to the at least one processor 51, such as a read-only memory (ROM) 52, a random access memory (RAM) 53, etc. Among them, the memory stores a computer program executable by the at least one processor, and the processor 51 can execute various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 52 or the computer program loaded from the storage unit 58 into the random access memory (RAM) 53. In the RAM 53, various programs and data required for the operation of the electronic device 50 can also be stored. The processor 51, the ROM 52, and the RAM 53 are connected to each other through a bus 54. The input / output (I / O) interface 55 is also connected to the bus 54.

[0161] A plurality of components in the electronic device 50 are connected to the I / O interface 55, including: an input unit 56, such as a keyboard, a mouse, etc.; an output unit 57, such as various types of displays, speakers, etc.; a storage unit 58, such as a magnetic disk, an optical disk, etc.; and a communication unit 59, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 59 allows the electronic device 50 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0162] The processor 51 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 51 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The processor 51 executes the various methods and processes described above, such as the incremental code coverage determination method.

[0163] In some embodiments, the incremental code coverage determination method can be implemented as a computer program tangibly embodied in a computer-readable storage medium, such as the storage unit 58. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 50 via the ROM 52 and / or the communication unit 59. When the computer program is loaded into the RAM 53 and executed by the processor 51, one or more steps of the incremental code coverage determination method described above can be executed. Alternatively, in other embodiments, the processor 51 can be configured to execute the incremental code coverage determination method by any other suitable means (e.g., by means of firmware).

[0164] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a dedicated or general-purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0165] The computer programs for implementing the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to the processors of general-purpose computers, special-purpose computers, or other programmable data processing devices such that the computer programs, when executed by the processors, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on the machine, partially on the machine, as an independent software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0166] In the context of the present invention, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination of the foregoing. Alternatively, the computer-readable storage medium can be a machine-readable signal medium. More specific examples of the machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0167] To provide for interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, speech input, or tactile input).

[0168] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0169] A computing system may include a client and a server. The client and the server are generally far away from each other and usually interact via a communication network. The relationship between the client and the server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or a cloud host, which is a host product in the cloud computing service system, solving the defects of difficult management and weak business scalability existing in traditional physical hosts and VPS services.

[0170] It should be understood that various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps recited in the present invention can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved, and no limitation is imposed herein.

[0171] The above specific embodiments do not constitute a limitation on the protection scope of the present invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. An incremental code coverage determination method, characterized in that Applied to the server side, including: In response to an incremental coverage rate determination request, obtain service code information and coverage rate determination requirement information submitted by a target user based on a front-end interface; Determine target service code according to the service code information, and determine at least one code change block according to the target service code; Select a target code change block from each of the code change blocks according to the coverage rate determination requirement information and the service code information, and determine a coverage rate code block corresponding to the target code change block; Determine a target incremental coverage rate according to a first code block line corresponding to the coverage rate code block and a second code block line corresponding to the target code change block; Feed back the target incremental coverage rate to the target user through the front-end interface.

2. The method according to claim 1, wherein The step of selecting a target code change block from each of the code change blocks according to the coverage rate determination requirement information and the service code information, and determining a coverage rate code block corresponding to the target code change block includes: Select a target code change block from each of the code change blocks according to the coverage rate determination requirement information, and determine a code change block operation object corresponding to the target code change block; Determine a target code submission identifier according to a code submission record corresponding to the code change block operation object; Select a target coverage rate data set from at least one coverage rate data set based on the service code information according to the target code submission identifier; Select target coverage rate data associated with the code change block operation object from the target coverage rate data set, and perform data merging on the target coverage rate data to obtain a coverage rate code block.

3. The method according to claim 2, wherein The step of determining a target code submission identifier according to a code submission record corresponding to the code change block operation object includes: Select a target submission record that meets a preset submission time judgment condition from the code submission record, and determine the code submission identifier corresponding to the target submission record as the target code submission identifier.

4. The method according to claim 2, wherein The step of selecting a target coverage rate data set from at least one coverage rate data set based on the service code information according to the target code submission identifier includes: Select at least one reference coverage rate data set from at least one coverage rate data set according to a service identifier in the service code information; the coverage rate data set includes at least one reference coverage rate data set corresponding to a service code with a submitted and released version; the reference coverage rate data set includes coverage rate data corresponding to a service code with a submitted and released version; Select a target coverage rate data set from each of the reference coverage rate data sets based on the target code submission identifier according to a service code submission identifier to which the target service code belongs in the service code information.

5. The method according to claim 1, characterized in that, The target service code includes a first service code and a second service code; the first service code is a code with an unsubmitted and unreleased version or a code with a submitted and released version; The second service code is only a code with a submitted and released version, and the code submission time of the second service code is not earlier than that of the first service code; correspondingly, the step of determining at least one code change block according to the target service code includes: Perform code difference analysis on the first service code and the second service code to obtain code difference information between the first service code and the second service code; Determine at least one code change block according to the code difference information.

6. The method according to claim 1, wherein The determining the target incremental coverage rate according to the first code block line corresponding to the coverage rate code block and the second code block line corresponding to the target code change block includes: Determine the intersection code block lines between the first code block line corresponding to the coverage rate code block and the second code block line corresponding to the target code change block; Determine the ratio between the intersection code block lines and the second code block lines as the target incremental coverage rate.

7. The method according to claim 2, wherein The generation method of the coverage rate data set is as follows: When the service application project starts, the proxy program starts to run and reads the environment information of the environment to which the service application project belongs, and determines the instance identifier and service identifier corresponding to the service application project, and uploads the environment information, instance identifier and service identifier to the server; The proxy program performs enhancement processing on the project bytecode of the service application project, obtains the code execution information of the service application project, and determines the coverage rate data according to the code execution information; When the preset data upload cycle judgment condition is met, upload the coverage rate data to the server for the server to generate a coverage rate data set of the coverage rate data under different data upload cycles, and associate and store the coverage rate data set with its corresponding environment information, instance identifier and service identifier.

8. An incremental code coverage determination device, characterized in that Configured on the server, including: A request response module, configured to obtain service code information and coverage rate determination requirement information submitted by a target user based on a front-end interface in response to an incremental coverage rate determination request; A code change block determination module, configured to determine a target service code according to the service code information, and determine at least one code change block according to the target service code; A covered code block determination module, configured to select a target code change block from each of the code change blocks according to the coverage rate determination requirement information and the service code information, and determine the coverage rate code block corresponding to the target code change block; An incremental coverage rate determination module, configured to determine a target incremental coverage rate according to the first code block line corresponding to the coverage rate code block and the second code block line corresponding to the target code change block; An incremental coverage rate feedback module, configured to feedback the target incremental coverage rate to the target user through the front-end interface.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and when the computer program is executed by the at least one processor, the at least one processor is enabled to execute the incremental code coverage rate determination method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for enabling a processor to execute the incremental code coverage rate determination method according to any one of claims 1-7 when executed.

Images