A method for inheritable coverage delta generation oriented to system snapshot timeline

Abstract

The application discloses a kind of inheritable coverage increment generation methods for system snapshot timeline, parse target version source code to generate static coverage denominator;Collect the effective system snapshot corresponding to current report request and generate current snapshot timeline, current tracking identifier set and current snapshot fingerprint;Read candidate historical report;Determine relationship mode;Inconsistent mode directly inherits historical report, in only append mode, inherit historical coverage fact and only process the tracking identifier corresponding to new snapshot, in rearrangement deletion mode, execute full-amount recalculation to current all tracking identifiers;When current submission is different from historical report submission, judge migration or cancel inheritance based on the intersection of submission difference mapping and method static effective line number set;For the tracking identifier set that needs to be processed in this round and the method of canceling inheritance, execute coverage aggregation;Merge static coverage denominator, migrated historical coverage fact and new coverage fact, output coverage report, the present application can be added to the existing version control system and Trace system without major changes in architecture.

Description

Technical Field

[0001] This invention belongs to the field of code coverage analysis, specifically relating to an inheritable coverage increment generation method for system snapshot timelines. Background Technology

[0002] Each time a coverage report is generated, the system needs to re-aggregate the trace data associated with all currently valid snapshots. The problem is that often, compared to the previous generation, this generation only adds two or three new snapshots at the end, while the historical traces are actually exactly the same as the previous one. However, the system still scans them from the beginning, and the report generation time increases linearly with the number of historical traces.

[0003] Another problem is coverage inheritance across commits. If the commit corresponding to this report is different from the last one (the code has changed), directly using the previous coverage result might incorrectly mark the modified methods as "covered." However, if there is no inheritance at all, the unmodified methods will be cleared before the current trace is reached, thus affecting the coverage trend. Figure 1 It's hard to explain why it fell down and bounced back.

[0004] There is also a more subtle situation: the order of snapshots has changed, for example, one was deleted, another was inserted, or the positions of two snapshots were swapped. In this case, if prefix matching is still used to determine "same as last time", it will result in incorrect inheritance.

[0005] To summarize the issues: adding only a new snapshot and then recalculating the entire dataset is wasteful; inheritance is inaccurate when the commit changes; inheritance is risky when the snapshot order is unstable; and the report doesn't clearly show which data is inherited and which is newly calculated.

[0006] This invention aims to: first, compare the relationship between the current snapshot timeline and the historical report timeline—whether they are identical, appended at the end, or have been rearranged and deleted—and then decide whether to directly inherit, process only the newly added parts, or recalculate the entire dataset. If the commit also changes, it further determines at the method granularity which methods have been modified and need to be recalculated, and which haven't been modified and can be covered by historical data. The final report simultaneously outputs the overall coverage, incremental coverage, and method reuse ratio, allowing the reader to understand the reasons behind the numerical changes. Summary of the Invention

[0007] To achieve the above objectives, the technical solution of the present invention is as follows: A method for generating inheritable incremental coverage for system snapshot timelines, characterized in that it includes: parsing the source code of the target version to generate a static coverage denominator; collecting valid system snapshots corresponding to the current report request and generating the current snapshot timeline, the current tracking identifier set, and the current snapshot fingerprint; reading the historical snapshot timeline, the historical tracking identifier set, the historical snapshot fingerprint, and the historical coverage facts of candidate historical reports; determining the relationship mode based on whether the historical snapshot fingerprint is the same as the current snapshot fingerprint and whether the historical snapshot timeline is a prefix of the current snapshot timeline; directly inheriting the historical report in the fully consistent mode, inheriting the historical coverage facts and processing only the tracking identifiers corresponding to the newly added snapshots in the append-only mode, and performing a full recalculation of all current tracking identifiers in the rearrangement and deletion mode; when the current commit is different from the historical report commit, determining migration or cancellation of inheritance based on the intersection of the commit difference mapping and the static valid line number set of the method; performing coverage aggregation on the tracking identifier set to be processed in this round and the method for canceling inheritance; merging the static coverage denominator, the migrated historical coverage facts, and the newly added coverage facts, and outputting a coverage report.

[0008] Preferably, the snapshot timeline is arranged in ascending order of snapshot effective time, and if the effective times are the same, it is sorted by snapshot identifier.

[0009] Preferably, the snapshot fingerprint is obtained by hashing the snapshot identifier and the snapshot effective time.

[0010] Preferably, the condition for determining the append-only mode is that the historical snapshot timeline is equal to the prefix sequence of the current snapshot timeline.

[0011] Preferably, the difference map is submitted with the class name as the key and the set of line numbers in that class that have changed as the value.

[0012] Preferably, the unique identity of a method is determined by the class name, method name, and method descriptor.

[0013] Preferably, the coverage report includes at least the number of snapshots, the number of actual traces processed in this round, the total number of rows, the total number of covered rows, the total number of incremental rows, the number of incremental covered rows, and the proportion of method-level historical results reused.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. In scenarios where only a new snapshot is added, the large number of historical traces do not need to be rescanned. Only the traces associated with the newly added snapshot are processed, and the report generation time no longer increases linearly with the amount of historical data.

[0015] 2. Cases where the snapshot order has been modified (deleted, rearranged, or inserted in the middle) can be identified. In such cases, instead of risking inheritance, a full recalculation is performed to avoid calculation errors.

[0016] 3. When the commit changes, judge at the method granularity: recalculate for modified methods, and move the historical coverage over for methods that have not been modified. The coverage will not fluctuate significantly due to the commit change.

[0017] 4. The report also provides the overall coverage rate, incremental coverage rate, and method reuse rate, so that readers can understand how these figures are derived, which ones are inherited, and which ones are newly calculated.

[0018] 5. The data structure and decision rules of the entire solution are relatively clear, and adding it to the existing version control system and trace system does not require major changes to the architecture. Attached Figure Description

[0019] Figure 1 This is a flowchart of the method; Figure 2 This is a snapshot relationship pattern determination diagram for the present invention; Figure 3 To submit a difference-driven migration graph; Figure 4 To cover the implementation of merged output diagrams; Figure 5 Example graphs for outputting coverage reports. Detailed Implementation

[0020] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Example

[0021] Variable and field descriptions • Timeline represents a sequence of snapshot identifiers arranged in ascending order of effectiveTime.

[0022] • snapshotFingerprint represents a timeline fingerprint generated from a snapshot identifier and an effective time.

[0023] • traceIdsToProcess represents the set of traces that need to be read and aggregated in this round.

[0024] • DiffMap represents a commit diff map, recording class names to a set of change line numbers.

[0025] The totalLineNumbers parameter represents the set of statically valid line numbers.

[0026] • coveredLineNumbers represents the set of covered line numbers.

[0027] • coveredBranchIds represents the set of covered branch identifiers.

[0028] • methodReuseRatio represents the percentage of historical results reused at the method level.

[0029] • A snapshot timeline is defined as: Timeline = [snapshotId1, snapshotId2, ..., snapshotIdN].

[0030] • Snapshot fingerprint is defined as: snapshotFingerprint = hash(snapshotId1:effectiveTime1|...|snapshotIdN:effectiveTimeN).

[0031] The structure of this solution consists of the following components. 1. Relationship Schema Determination Rules The system reads the oldTimeline and oldFingerprint of the candidate historical reports, as well as the newTimeline and newFingerprint of the current report request, and determines the results according to the following rules: if oldFingerprint == newFingerprint: mode = MODE_SAME elif newTimeline[0:len(oldTimeline)] == oldTimeline: mode = MODE_APPEND_ONLY Else: mode = MODE_REORDER_OR_DELETE

[0032] 2. Methods and Steps S1. Parse the source code of the target version and generate a static overriding denominator consisting of classes, methods, valid line numbers, number of branches, and complexity.

[0033] S2. Collect valid system snapshots corresponding to the current report request, and generate newTimeline, current Trace set and newFingerprint in ascending order of effectiveTime; if the times are the same, sort by snapshotId.

[0034] S3. Select candidate historical reports from historical reports of the same application, version, and report type, and read oldTimeline, historical Trace collection, oldFingerprint, and historical coverage facts.

[0035] S4. Determine the relationship mode as MODE_SAME, MODE_APPEND_ONLY, or MODE_REORDER_OR_DELETE based on fingerprint equality and prefix relationship.

[0036] S5. When the mode is MODE_SAME, the historical report is directly inherited; when the mode is MODE_APPEND_ONLY, the historical overwrite facts are inherited, and the Trace corresponding to the new snapshot is recorded in traceIdsToProcess; when the mode is MODE_REORDER_OR_DELETE, all current Traces are recorded in traceIdsToProcess and a full recalculation is performed.

[0037] S6. If the current commit differs from historical commit reports, obtain the DiffMap and calculate it for each method: intersectLines = totalLineNumbers ∩ DiffMap[className] If intersectLines is empty, then migrate the history of this method, coveredLineNumbers and coveredBranchIds; if it is not empty, then cancel the inheritance of this method and enter the re-aggregation scope.

[0038] S7. Aggregate only the runtime coverage records corresponding to traceIdsToProcess and the method that cancels inheritance, and merge the execution line number into coveredLineNumbers and the branch execution facts into coveredBranchIds.

[0039] S8. Merge static coverage denominators, inherit coverage facts, add new coverage facts, and recalculate coverage facts, and output a coverage report, which should include at least snapshotCount, traceProcessed, totalLines, coveredLines, incTotalLines, incCoveredLines, methodReuseRatio, and relation schema.

[0040] 3. System Modules Specific Implementation

[0041] Example: A request to generate an order application report is as follows:

[0042] The system determines that the historical timeline is a prefix of the current timeline, therefore: mode = MODE_APPEND_ONLY traceIdsToProcess = traces(S109) ∪ traces(S110) traceProcessed = 32 Since the commit changed from commitA to commitB, read the diff map:

[0043] Method-level transfer decisions are as follows:

[0044] Example of a final report summary: { "reportType": "FULL", "mode": "MODE_APPEND_ONLY", "snapshotCount": 10, "traceProcessed": 32, "totalLines": 18400, "coveredLines": 13240, "incTotalLines": 980, "incCoveredLines": 712, "methodReuseRatio": "5798 / 5860" } In this embodiment, the system reduces the number of traces processed from 268 to 32, approximately 11.9%, and avoids the incorrect inheritance of historical overwrite facts by changed methods through method-level difference migration.

[0045] It should be noted that the above content merely illustrates the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. For those skilled in the art, various improvements and modifications can be made without departing from the principle of the present invention, and all such improvements and modifications fall within the scope of protection of the claims of the present invention.

Claims

1. A method for generating inheritable coverage increments for system snapshot timelines, characterized in that, include: Parse the target version's source code to generate a static overriding denominator; Collect valid system snapshots corresponding to the current report request and generate the current snapshot timeline, the current tracking identifier set, and the current snapshot fingerprint; Read the historical snapshot timeline, historical tracking identifier set, historical snapshot fingerprint, and historical coverage facts of the candidate historical report; The relationship pattern is determined based on whether the historical snapshot fingerprint is the same as the current snapshot fingerprint, and whether the historical snapshot timeline is a prefix of the current snapshot timeline; In fully consistent mode, historical reports are directly inherited; in append-only mode, historical overwrite facts are inherited and only the tracking identifiers corresponding to newly added snapshots are processed; in rearranged deletion mode, a full recalculation is performed on all current tracking identifiers. When the current commit differs from the historical commit, the migration or cancellation of inheritance is determined based on the intersection of the commit difference mapping and the set of static valid line numbers of the method. Perform overlay aggregation on the set of tracking identifiers to be processed in this round and the method for canceling inheritance; Merge the static coverage denominator, migrated historical coverage facts, and newly added coverage facts to output a coverage report.

2. The method according to claim 1, characterized in that, The snapshot timeline is arranged in ascending order of snapshot effective time, and if the effective times are the same, it is sorted by snapshot identifier.

3. The method according to claim 1, characterized in that, The snapshot fingerprint is obtained by hashing the snapshot identifier and the snapshot effective time.

4. The method according to claim 1, characterized in that, The condition for determining the append-only mode is that the historical snapshot timeline is equal to the prefix sequence of the current snapshot timeline.

5. The method according to claim 1, characterized in that, Submit a difference map with the class name as the key and the set of line numbers in that class that have changed as the value.

6. The method according to claim 1, characterized in that, A method's unique identity is determined by its class name, method name, and method descriptor.

7. The method according to claim 1, characterized in that, The coverage report should include at least the number of snapshots, the number of traces actually processed in this round, the total number of rows, the total number of covered rows, the total number of incremental rows, the number of incremental covered rows, and the percentage of historical results reused at the method level.

Images