Method and device for analyzing influence of code change on software test coverage

Abstract

This invention discloses a method and apparatus for analyzing the impact of code changes on software test coverage, relating to the field of software testing technology. The method includes: automatically acquiring code change information in response to a software testing request; tracing the call chain of the changed code based on a code call relationship graph to determine the affected traffic entry points and front-end pages, generating an impact scope list; dividing test cases into page test cases and interface test cases and adding structured tags; matching the identifiers in the impact scope list with the test case tags to obtain recommended test cases; comparing coverage, identifying uncovered impact points, generating a list of missing test cases, and prompting for their addition. This invention can comprehensively trace the impact scope starting from code changes, accurately recommend test cases to be executed, and proactively discover testing blind spots, effectively improving testing efficiency and coverage.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and apparatus for analyzing the impact of code changes on software test coverage. Background Technology

[0002] In software development, frequent changes to backend service code are commonplace. After each code change, accurately and efficiently determining the scope of the impact and developing appropriate testing strategies to ensure software quality is a significant challenge in the field of software testing.

[0003] Currently, the industry standard approach is to extract code change information using code difference analysis tools and then combine this information with historical test case execution records for related recommendations. Specifically, this method first obtains a set of code changes, parsing out the changed files, functions, or methods; then, it filters test cases from the test case management system that have covered these changed code blocks and recommends them to testers for regression testing.

[0004] However, the aforementioned existing technology has the following obvious drawbacks: (1) The scope of impact analysis is not comprehensive. This method can only analyze changes to the code block itself and cannot penetrate to the traffic entry points (such as HTTP interfaces, message queues MQ, remote procedure calls RPC services) and related front-end pages that are actually affected by the code changes, which may result in omissions in the test scope.

[0005] (2) Low accuracy of test case association. The recommendation of this method is based only on historical coverage relationship, without considering the actual impact of code changes and the precise matching of test case attributes, which can easily lead to redundant recommendations or test omissions.

[0006] (3) Inability to identify missing test cases. This method can only recommend existing test cases. For interfaces or pages affected by code changes but not yet covered by test cases, it cannot proactively discover and remind testers to supplement them, thus creating potential quality risks.

[0007] Therefore, there is an urgent need for a technical solution that can comprehensively and accurately analyze the impact of code changes and accurately assess the coverage of existing test cases in order to solve the above problems. Summary of the Invention

[0008] The present invention aims to solve the technical problems in the prior art, such as incomplete analysis of the impact scope of code changes, low accuracy of test case association, and inability to identify missing test cases.

[0009] One aspect of the present invention provides a method for analyzing the impact of code changes on software test coverage, comprising the following steps: In response to the submission of a software test request, automatically obtain the code change information corresponding to this software test request; Based on a pre-built code call relationship graph, the call chain of the modified code is determined, the traffic entry points affected by the code change are determined according to the call chain, and the affected front-end pages are determined according to a pre-built mapping table between traffic entry points and front-end pages, so as to generate a list of the scope of impact containing the affected traffic entry points and front-end pages. The test cases in the test case library are divided into page test cases and interface test cases, and structured tags are added to each test case; among them, the interface test case tag contains its corresponding traffic entry identifier, and the page test case tag contains its corresponding front-end page identifier. The traffic entry identifier and front-end page identifier in the impact scope list are matched with the traffic entry identifier in the interface test case tag and the front-end page identifier in the page test case tag, respectively. The test cases that match are used as recommended test cases. By comparing the label coverage of the impact scope list with that of the test cases in the test case library, traffic entry points or front-end pages that are not covered by any test case labels in the impact scope list are identified, a list of missing test cases is generated, and a prompt message is sent to testers to supplement the missing test cases.

[0010] In another aspect, the present invention provides an apparatus for analyzing the impact of code changes on software test coverage, comprising: The code acquisition module is used to respond to the submission of software test requests and automatically acquire code change information corresponding to the current software test request. The impact scope generation module is used to determine the call chain of the modified code based on a pre-built code call relationship graph, determine the traffic entry points affected by the code change according to the call chain, and determine the affected front-end pages according to a pre-built mapping table between traffic entry points and front-end pages, so as to generate an impact scope list containing the affected traffic entry points and front-end pages. The tag management module is used to divide the test cases in the test case library into page test cases and interface test cases, and add structured tags to each test case; among them, the interface test case tag contains its corresponding traffic entry identifier, and the page test case tag contains its corresponding front-end page identifier. The matching and recommendation module is used to match the traffic entry identifier and front-end page identifier in the impact range list with the traffic entry identifier in the interface test case tag and the front-end page identifier in the page test case tag, respectively, and use the test cases that match as recommended test cases; The missing test case generation module is used to identify traffic entry points or front-end pages in the impact scope list that are not covered by any test case tags by comparing the tag coverage of test cases in the impact scope list with that in the test case library, generate a missing test case list, and send a prompt message to testers to supplement the missing test cases.

[0011] The method and apparatus for analyzing the impact of code changes on software test coverage provided by this invention comprehensively determine the scope of impact of code changes by starting from backend code changes and tracing upstream along the call relationship to the frontend page and traffic entry point. Combined with a structured governance test case tag system for accurate matching, it can not only efficiently recommend test cases that need to be re-executed, but also proactively identify test coverage blind spots and remind them to supplement them, significantly improving the comprehensiveness, accuracy and efficiency of testing. Attached Figure Description

[0012] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating an embodiment of the method for analyzing the impact of code changes on software test coverage provided in this application. Figure 2 This is a schematic diagram of the structure of an analysis device for the impact of code changes on software test coverage provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] I. Key Technical Terms To facilitate an accurate understanding of the technical solution of this invention, several key technical terms involved in the application documents are first explained and defined in a unified manner.

[0015] Code change information: refers to the specific changes made in the code repository corresponding to this test version during the software development process compared to the previous stable version, including but not limited to newly added, modified or deleted classes, methods, functions and their file paths and service names.

[0016] Traffic entry point: refers to the entry point for external requests or messages to enter the backend service system, including but not limited to: Hypertext Transfer Protocol (HTTP) interface, Message Queue (MQ) topic and Remote Procedure Call (RPC) service.

[0017] Traffic entry identifier: Identification information used to uniquely identify a traffic entry point. For HTTP interfaces, the identifier is the request path; for MQ, the identifier is the topic name; for RPC services, the identifier is a combination of the service name and the method name.

[0018] Front-end page: refers to the user-facing interactive interface of a software system that runs in a browser or mobile client, and is usually accessed and located through a Uniform Resource Locator (URL).

[0019] Front-end page identifier: Identification information used to uniquely identify a front-end page, which is specifically represented as the page URL in this invention.

[0020] Code call graph: A graph data structure that describes the call relationships between program units within a software system. Specifically, it can include intra-service call graphs, which describe the call relationships between classes, methods, and functions within the same service; and inter-service call graphs, which describe the call relationships between different services generated through methods such as message queues (MQ) and reverse proxy (RPC).

[0021] Mapping table: This refers to a pre-built data table used to record the dependency relationships between traffic entry points and front-end pages. This table stores the mapping between HTTP API requests initiated by the front-end page and the API addresses they call.

[0022] Test case: A set of test inputs, execution conditions, and expected results designed to verify a specific function or scenario of software. In this invention, test cases are divided into two categories: page test cases and interface test cases.

[0023] Interface test cases: These are test cases that primarily verify the functionality, parameter validation, and exception handling of backend traffic entry points (HTTP interfaces, MQ topics, RPC service methods).

[0024] Page test cases: These are test cases that primarily verify front-end functions such as element display, interaction logic, page navigation, and data submission on the front-end page.

[0025] Structured tags: These are metadata information with clearly defined fields added to test cases, used to describe the test objects of the test cases in a machine-readable way. Tags for interface test cases include interface type tags and traffic ingress identifiers; tags for page test cases include the page URL and the traffic ingress identifiers it depends on.

[0026] Impact Scope List: This refers to a structured data list compiled by analyzing the code call chain, starting from the changed backend code, tracing upwards to the affected traffic entry points and frontend pages, and summarizing these affected objects.

[0027] II. Method Examples This embodiment provides a method for analyzing the impact of code changes on software test coverage. For example... Figure 1 As shown, the method mainly includes the following steps.

[0028] Step S101: In response to the submission of the software test request, automatically obtain the code change information corresponding to this software test request.

[0029] This step aims to automate the triggering of the testing process and the collection of basic data. After the developers complete the code development and submit a test request (i.e., a software test request), the system automatically receives the event through a WebHook or Application Programming Interface (API) provided by the code repository management platform (such as GitLab, GitHub, etc.) and triggers the execution of this method.

[0030] Specifically, the system calls the code repository's comparison interface to obtain code difference data between the current development branch and the test baseline branch (usually the code branch corresponding to the last stable release). This difference data can be output in the standard Git Diff text format, including the path of the changed files, the change type (added, modified, deleted), and the specific lines of change content. The system further uses code parsing tools (such as JavaParser for Java, or the corresponding abstract syntax tree parser for other languages) to perform structured parsing of the difference data, extracting structured information such as the service names involved in this code change, the complete class paths of the changes, and the signatures of the changed methods or functions, forming a set of code change information for this analysis. This information provides the most basic data source for tracing the call chain and locating the scope of impact in subsequent steps.

[0031] Step S102: Based on the pre-built code call relationship graph, determine the call chain of the changed code, determine the traffic entry points affected by the code change according to the call chain, and determine the affected front-end pages according to the pre-built mapping table between traffic entry points and front-end pages, so as to generate a list of the scope of impact containing the affected traffic entry points and front-end pages.

[0032] This step is one of the core innovations of this invention, aiming to solve the technical problem that existing technologies cannot trace the impact on front-end pages and traffic entry points from back-end code changes along the call relationships, resulting in a one-sided assessment of the scope of impact. The core idea of ​​this invention is to start from back-end code changes, trace upstream along the call relationships until the traffic entry points exposed by the system are located, and further penetrate to the front-end pages that depend on these interfaces, forming a complete end-to-end list of the scope of impact.

[0033] Specifically, this step further includes the following sub-steps: S1021: Based on static code analysis methods, analyze the classes, methods, and / or functions involved in code change information.

[0034] From the code change information obtained in step S101, the system identifies the specific service-specific program units involved in this change, that is, it clarifies which classes, methods, and / or functions have had their code logic altered. These identified program units are the starting point for subsequent call chain tracing.

[0035] S1022: Use the code call relationship graph to trace the call chain of the class, method and / or function upstream, identify the traffic entry point that directly or indirectly calls the modified code through the call chain, and extract the unique identification information of each traffic entry point.

[0036] This sub-step is a core component of cross-platform penetration analysis (i.e., starting from backend code changes and tracing upstream along the call relationships to the traffic entry point and frontend page). The system accesses a pre-built code call relationship graph stored in a graph database. This call relationship graph is constructed using static code analysis techniques and records the call relationships between methods within a service, as well as the call relationships between services generated through message queues (MQ) and RPC.

[0037] For each code-modified method or function identified in step S1021, the system executes an upward path search algorithm in the graph database, starting from the node representing that modified method or function, traversing all its direct and indirect callers. This complete path, starting from the modified code and ascending step by step to the system boundary, is the call chain. The endpoint of the call chain is the traffic entry point exposed to the outside world by the system, capable of responding to external requests.

[0038] When the tracing path reaches a method defined by an HTTP interface, the system parses the interface's annotations or configuration file to extract its request path, such as ` / api / v1 / order / process`. When the tracing path reaches a message queue (MQ) consumption processing method, the system identifies the topic it is listening to, such as `order.process.topic`. When the tracing path reaches a method provided by an RPC service, the system extracts its complete service name and method name combination, such as `com.example.order.rpc.Order rProcessRpcService#handleOrder`. The information extracted above constitutes the unique identifier for each traffic entry point.

[0039] This tracing mechanism ensures that even a minor code change within a low-level utility class, as long as it's on an external service link, can accurately pinpoint the affected traffic entry point. This guarantees the comprehensiveness and depth of the impact analysis, effectively avoiding the omission risks associated with existing technologies that only analyze the code block itself. Compared to existing technologies, this invention significantly improves the coverage of code change impact identification.

[0040] S1023: Based on the pre-built mapping table between traffic entry points and front-end pages, determine the affected front-end pages.

[0041] After identifying the affected HTTP interfaces, this sub-step further extends the impact to the front end. The system queries a pre-built "traffic entry point-page" mapping table. This mapping table is generated through static scanning of the front-end project code. Specifically, it parses the page files and script files in the front-end project to identify the interface addresses corresponding to the HTTP requests initiated by the pages, thereby establishing the association between the front-end page URLs and the back-end HTTP interface paths. For traffic entry points of MQ and RPC types, their association with the front-end pages is indirectly established through tracing the code call chain. That is, when a change in MQ or RPC affects an HTTP interface, this mapping table is used to further associate it with the relevant pages.

[0042] For each affected HTTP interface identified in step S1022, the system searches the mapping table for all front-end pages that depend on that interface and extracts the URLs of these pages as front-end page identifiers. For example, if the HTTP interface / api / v1 / order / process is depended on by the pages / pages / order / confirm and / pages / order / detail in the mapping table, then both of these pages are identified as affected front-end pages.

[0043] S1024: Generate a list of the impact areas, including affected traffic entry points and front-end pages.

[0044] The system aggregates all traffic entry points (including their types and unique identifiers) and all front-end pages (including their URLs) identified in steps S1022 and S1023, generating a structured, machine-readable list of impact areas. This list is organized by service, clearly outlining all test objects affected by the code change. This list provides complete and accurate input data for precise matching and missing data identification of subsequent test cases.

[0045] Step S103: Divide the test cases in the test case library into page test cases and interface test cases, and add structured tags to each test case; among them, the interface test case tag contains its corresponding traffic entry identifier, and the page test case tag contains its corresponding front-end page identifier.

[0046] This step aims to provide structured governance for test case assets to address the technical challenge of accurately associating test cases with their impact scope in existing technologies. The core of this step is establishing a standardized tagging system that enables machines to accurately understand and match the testing intent of test cases.

[0047] Specifically, this step further includes the following sub-steps: S1031: Add structured tags to the interface use case. The structured tags include interface type tags and traffic entry identifiers. The interface type tags include HTTP, MQ, or RPC.

[0048] For each interface test case, the tester adds two key tag fields to the test case based on the target interface they are actually testing: (1) Interface type tag. It is used to identify the type of interface being tested in this test case. Its value range can be an enumeration value: HTTP, MQ or RPC.

[0049] (2) Traffic entry identifier. This is used to identify which interface is being tested in this use case. Its value must strictly correspond to the unique identifier information of the traffic entry extracted in step S102. For example, if testing an HTTP interface, fill in its request path / api / v1 / order / process here; if testing MQ consumption logic, fill in its topic name order.process.topic here.

[0050] By combining these two tags, the system can accurately locate the traffic entry point covered by an interface use case, laying the foundation for subsequent accurate matching.

[0051] S1032: Add structured tags to the page use case, the structured tags including a page URL for representing the front-end page identifier and a back-end traffic entry identifier for representing the traffic entry on which the page depends.

[0052] For each page test case, the tester adds two key tag fields: (1) Page URL. This identifies the front-end page being tested in this test case. Its value is the page's access address, such as / pages / order / confirm. This field directly corresponds to the front-end page identifier identified in step S102.

[0053] (2) Backend Traffic Entry Identifier. This identifies the core backend traffic entry points on which the page functionality being tested depends. A page's normal functionality often relies on data support or operational feedback from one or more backend interfaces. For example, an order confirmation page might depend on the "Get Shopping Cart Items" and "Submit Order" interfaces. Testers must fill in the key backend traffic entry point identifiers this page depends on here. If multiple backend traffic entry points are relied upon, a list or separator can be used to record them.

[0054] This dual-label design enables page use cases to be matched not only directly through the page URL, but also indirectly when the backend traffic entry points they depend on are affected, thus achieving complete coverage of the front-end and back-end impact chain and solving the problem that page use cases are difficult to recommend accurately in existing technologies.

[0055] Step S104: Match the traffic entry identifier and front-end page identifier in the impact scope list with the traffic entry identifier in the interface test case tag and the front-end page identifier in the page test case tag, respectively, and use the test cases that match as recommended test cases.

[0056] The purpose of this step is to automatically select the regression test cases that should be prioritized for execution in this code change, based on the generated impact scope list and the managed test case tag system.

[0057] Specifically, this step further includes the following sub-steps: S1041: For each traffic entry point in the impact scope list, query the test case library to see if there is an interface test case that matches both the interface type label and the traffic entry point identifier.

[0058] The system iterates through each traffic entry point recorded in the impact scope list. For each traffic entry point, the system performs a precise query in the interface test case set of the test case library based on its type (HTTP, MQ, RPC) and unique identifier. The query conditions are: the interface type label equals the type of the current traffic entry point, and the traffic entry point identifier equals the unique identifier of the current traffic entry point.

[0059] If a matching test case is found, it means that there are already corresponding dedicated test cases for the affected traffic entry point, and these test cases will be marked and collected.

[0060] S1042: For each front-end page in the impact scope list, query the test case library to see if there is a page test case with a matching page URL, or query if there is a page test case whose backend traffic entry identifier in the page test case tag matches any traffic entry identifier in the impact scope list.

[0061] This sub-step involves matching page use cases, employing two parallel matching logics: (1) Direct Matching. The system queries the page test cases in the test case library, provided that the page URL tag value of the test case is equal to the front-end page identifier (i.e., page URL) in the current impact scope list. If the match is successful, it means that the page test case directly targets the affected page itself and must be recalled.

[0062] (2) Indirect matching. The system queries the page test cases in the test case library, provided that the backend traffic entry identifier value of the page test case is the same as any traffic entry identifier recorded in the impact scope list. If the match is successful, it means that the backend traffic entry on which the page test case depends has been affected by this code change, the page function is indirectly affected, and its corresponding page test case should also be included in the regression testing scope.

[0063] By combining these two methods, the system can comprehensively and without omission recall all page use cases related to the impact of the change.

[0064] S1043: Use matching test cases as recommended test cases.

[0065] The system aggregates and deduplicates all interface and page test cases retrieved in steps S1041 and S1042 (the same test case may meet multiple matching conditions simultaneously), and sorts them according to preset priority rules (such as historical execution pass rate, defect discovery rate, etc.), ultimately generating a recommended test case list. This list directly guides testers to accurately execute necessary regression tests, avoiding the high costs associated with full-scale testing.

[0066] Step S105: By comparing the label coverage of the test cases in the impact scope list with that in the test case library, identify the traffic entry points or front-end pages in the impact scope list that are not covered by any test case labels, generate a list of missing test cases, and send a prompt message to the testers to supplement the missing test cases.

[0067] This step aims to address the fundamental deficiency of existing technologies in identifying test coverage blind spots and proactively discover missing test assets. Specifically, this step further includes the following sub-steps: S1051: Traverse all traffic entry points and front-end pages in the list of affected areas.

[0068] The system reads each traffic entry point and each front-end page in the impact range list one by one, and uses them as test coverage targets to be checked.

[0069] S1052: For any traffic entry point, if there is no interface test case in the test case library that matches both the interface type label and the traffic entry point identifier, then the test case corresponding to that traffic entry point is determined to be missing.

[0070] For each traffic entry point, the system performs the exact same precise query as in step S1041. If no interface test case that meets the conditions is found in the test case library, it means that the affected traffic entry point has not been covered by any dedicated interface test case, and there is a significant testing blind spot. The system records the traffic entry point and its identification information as missing.

[0071] S1053: For any front-end page, if there is no page test case in the test case library that matches the page URL, and there is no page test case in the page test case tag that matches any traffic entry identifier in the impact scope list, then it is determined that the test case corresponding to the front-end page is missing.

[0072] For each front-end page, the system executes the same dual-matching logic as in step S1042. Only when both direct matching (via the page URL) and indirect matching (via the back-end traffic entry identifier it depends on) fail does the system determine that a test case for that front-end page is missing. This means that the current test case library contains neither a test case specifically for that page, nor a test case that indirectly covers the page's functionality due to the interface being affected; therefore, the impact of changes to that page cannot be verified by any existing test cases.

[0073] S1054: Integrate all test cases that are determined to be missing to generate the missing test case list.

[0074] The system summarizes all traffic entry points and front-end page information identified as missing in steps S1052 and S1053, generating a structured list of missing test cases. This list includes key information such as the type of missing impact point (e.g., traffic entry point or page), specific identifier, service to which it belongs, and suggested supplementary test scenarios.

[0075] S1055: Send a prompt message to the tester to supplement the missing test case.

[0076] The system automatically triggers a notification mechanism (such as sending emails or generating to-do tasks on the project management platform) to push the generated list of missing test cases to relevant testers, explicitly prompting them to supplement the test cases according to the list. This mechanism transforms passively waiting for testing into proactively guiding test design, effectively promoting the continuous improvement of test coverage. In practical applications, after adopting this solution, the test coverage of the software system has been significantly improved.

[0077] The method for analyzing the impact of code changes on software test coverage provided in this embodiment organically combines a series of technical means such as automated triggering, cross-platform penetration analysis, structured tag matching, and proactive missing identification to construct a complete and closed-loop code change impact analysis and test coverage evaluation system, which comprehensively improves the efficiency, accuracy, and completeness of software testing.

[0078] To make the technical solution of this invention easier to understand, the application process of the method of this invention in the actual workflow is fully explained below in conjunction with a specific software development and testing scenario.

[0079] The order service team at an internet company is conducting a routine feature iteration. The developers have modified the order processing logic, specifically as follows: Change 1: The calculation formula for coupon discounts has been modified in the calculateDiscount method of the OrderProcessService class.

[0080] Change 2: A new message consumption processing method for the MQ topic order.payment.success.topic has been added to the MessageConsumer class.

[0081] After completing the coding and self-testing, the R&D personnel submitted a test request for this requirement on the project management platform.

[0082] Step 1: Automatically obtain code change information.

[0083] The system listens for test submission events via GitLab's WebHook, automatically triggering the analysis process of this invention. The system calls GitLab's Compare API to compare the code differences between the current development branch feature / order-discount-v2 and the baseline branch master. Through parsing Git Diff and JavaParser static analysis, the system extracts the following code change information: Service name: order-service Change class and method 1: com.example.order.service.Order ProcessService.calculateDiscount (modified).

[0084] Change class and method 2: com.example.order.consumer.Message Consumer. consumePaymentSuccess (new).

[0085] Step 2: Generate a list of affected areas.

[0086] The system first traces upstream based on a pre-built code call relationship graph.

[0087] Tracing the `calculateDiscount` method: The graph database shows that the `calculateDiscount` method is called by the `createOrder` method of this service, and the `createOrder` method is the entry point method of the externally exposed HTTP interface ` / api / v1 / order / create`. Therefore, the system determines that the HTTP interface ` / api / v1 / order / create` is affected.

[0088] Tracing the `consumePaymentSuccess` method: By analyzing the MQ listener annotations on this method, the system directly identified its corresponding traffic entry point as the MQ topic `order.payment.success.topic`. Therefore, the system determined that this MQ topic was affected.

[0089] The system then queries the "interface-page" mapping table. The table shows that the HTTP interface / api / v1 / order / create is being called by the front-end pages / pages / order / checkout (order checkout page) and / pages / cart / index (shopping cart page). Therefore, the system determines that these two front-end pages are affected.

[0090] The final list of impact areas is shown below (in JSON format): json { "service_name": "order-service", "affected_interfaces": [ { "type": "HTTP", "identifier": " / api / v1 / order / create"}, { "type": "MQ", "identifier": "order.payment.success.topic"} ], "affected_pages": [ { "page_url": " / pages / order / checkout"}, { "page_url": " / pages / cart / index"} ] } Step 3: Test case association and matching.

[0091] The system queries the test case library that has completed structured governance.

[0092] Matching for the HTTP interface / api / v1 / order / create: The system found one interface use case (denoted as use case A), whose tag is interface type: HTTP, and traffic entry identifier is / api / v1 / order / create. Match successful.

[0093] Matching for the MQ topic order.payment.success.topic: The system found no matching use cases in the interface use cases.

[0094] Matching for page / pages / order / checkout: The system found one page use case (referred to as use case B), whose tag is the page URL: / pages / order / checkout, and the backend traffic entry identifier is / api / v1 / order / create. Match successful.

[0095] Matching for page / pages / cart / index: The system did not find any use cases that matched the page URL in the page use cases, nor did it find any use cases whose backend traffic entry identifier contained any interface identifier in the scope of impact list (such as / api / v1 / order / create).

[0096] Ultimately, test case A and test case B were included in the recommended test case list.

[0097] Step 4: Generate a list of missing test cases and provide a prompt.

[0098] The system compares the impact scope list with the coverage of existing use cases and performs a missing data check: Traffic entry MQ: order.payment.success.topic: No matching interface use case was found, and it was determined to be missing.

[0099] Front-end page / pages / cart / index: There are no directly matching page use cases, nor are there any indirectly matching page use cases, so it is determined to be missing.

[0100] The system integrates the above two items to generate a list of missing test cases.

[0101] The system automatically sends an email to the test manager responsible for this test submission. The email attachment contains a list of recommended test cases and a list of missing test cases. It also creates a pending task on the test management platform for supplementing test cases.

[0102] Through the above process, testers can immediately obtain accurate regression testing suggestions without manually analyzing the impact of code changes. They can also clearly see the testing blind spots in this iteration (i.e., the need to supplement MQ interface test cases and shopping cart page test cases). This not only significantly shortens test preparation time and avoids redundant full-scale testing, but also prevents online failures caused by insufficient test coverage from the source, significantly improving the quality and efficiency of software delivery.

[0103] III. Device Examples See Figure 2 Another embodiment of the present invention provides an analysis device 200 for the impact of code changes on software test coverage, including a code acquisition module 201, an impact range generation module 202, a tag management module 203, a matching recommendation module 204, and a missing item generation module 205. This analysis device 200 for the impact of code changes on software test coverage can execute the analysis method for the impact of code changes on software test coverage in the method embodiment.

[0104] Specifically, the analysis device 200 for the impact of code changes on software test coverage includes: The code acquisition module 201 is used to automatically acquire code change information corresponding to the current software test request in response to the submission of the software test request. The impact scope generation module 202 is used to determine the call chain of the changed code based on a pre-built code call relationship diagram, determine the traffic entry points affected by the code change according to the call chain, and determine the affected front-end pages according to a pre-built mapping table between traffic entry points and front-end pages, so as to generate an impact scope list containing the affected traffic entry points and front-end pages. The tag management module 203 is used to divide the test cases in the test case library into page test cases and interface test cases, and add structured tags to each test case; among them, the interface test case tag contains its corresponding traffic entry identifier, and the page test case tag contains its corresponding front-end page identifier. The matching and recommendation module 204 is used to match the traffic entry identifier and front-end page identifier in the impact range list with the traffic entry identifier in the interface use case label and the front-end page identifier in the page use case label, respectively, and use the test cases that match as recommended test cases. The missing test case generation module 205 is used to identify traffic entry points or front-end pages in the impact scope list that are not covered by any test case tags by comparing the tag coverage of the test cases in the impact scope list with that in the test case library, generate a missing test case list, and send a prompt message to the testers to supplement the missing test cases.

[0105] It should be noted that the analysis device 200 for the impact of code changes on software test coverage provided in this embodiment corresponds to the technical solutions that can be used to execute various method embodiments. Its implementation principle and technical effect are similar to the method, and will not be repeated here.

[0106] Figure 3 This is a schematic diagram of an electronic device 300 provided in another embodiment of the present invention. The electronic device 300 is used to implement the method for analyzing the impact of code changes on software test coverage in the method embodiment. The electronic device 300 in the embodiments of the present invention may include, but is not limited to, smartphones, tablet computers, PCs, laptops, etc. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0107] like Figure 3As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0108] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

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

Claims

1. A method for analyzing the impact of code changes on software test coverage, characterized in that, Includes the following steps: In response to the submission of a software test request, automatically obtain the code change information corresponding to this software test request; Based on a pre-built code call relationship graph, the call chain of the modified code is determined, the traffic entry points affected by the code change are determined according to the call chain, and the affected front-end pages are determined according to a pre-built mapping table between traffic entry points and front-end pages, so as to generate a list of the scope of impact containing the affected traffic entry points and front-end pages. The test cases in the test case library are divided into page test cases and interface test cases, and structured tags are added to each test case; among them, the interface test case tag contains its corresponding traffic entry identifier, and the page test case tag contains its corresponding front-end page identifier. The traffic entry identifier and front-end page identifier in the impact scope list are matched with the traffic entry identifier in the interface test case tag and the front-end page identifier in the page test case tag, respectively. The test cases that match are used as recommended test cases. By comparing the label coverage of the impact scope list with that of the test cases in the test case library, traffic entry points or front-end pages that are not covered by any test case labels in the impact scope list are identified, a list of missing test cases is generated, and a prompt message is sent to testers to supplement the missing test cases.

2. The method for analyzing the impact of code changes on software test coverage according to claim 1, characterized in that, The step of determining the call chain of the modified code based on a pre-built code call relationship graph, and determining the traffic entry points affected by the code change based on the call chain, includes: Based on static code analysis methods, the classes, methods, and / or functions involved in code change information are analyzed; By using the code call relationship graph, the call chain of the class, method and / or function is traced upstream. The traffic entry point that directly or indirectly calls the modified code is identified through the call chain, and the unique identification information of each traffic entry point is extracted.

3. The method for analyzing the impact of code changes on software test coverage according to claim 1, characterized in that, The step of adding structured tags to each test case includes: Add structured tags to the interface use cases. The structured tags include interface type tags and traffic entry identifiers, wherein the interface type tags include HTTP, MQ, or RPC. Add structured tags to the page use case, the structured tags including the page URL for representing the front-end page identifier, and the back-end traffic entry identifier for representing the traffic entry on which the page depends.

4. The method for analyzing the impact of code changes on software test coverage according to claim 3, characterized in that, The step of matching the traffic entry identifier and front-end page identifier in the impact scope list with the traffic entry identifier in the interface use case tag and the front-end page identifier in the page use case tag, respectively, includes: For each traffic entry point in the impact scope list, query the test case library to see if there is an interface test case that matches both the interface type label and the traffic entry point identifier. For each front-end page in the impact scope list, query the test case library to see if there is a page test case with a matching page URL, or query if there is a page test case whose backend traffic entry identifier in the page test case tag matches any traffic entry identifier in the impact scope list.

5. The method for analyzing the impact of code changes on software test coverage according to claim 3, characterized in that, The step of generating a list of missing test cases includes: Iterate through all traffic entry points and front-end pages in the list of affected areas; For any traffic entry point, if there is no interface test case in the test case library that matches both the interface type label and the traffic entry point identifier, then the test case corresponding to that traffic entry point is determined to be missing. For any front-end page, if there is no page test case in the test case library that matches the page URL, and there is no page test case in the page test case tag that matches any traffic entry identifier in the impact scope list, then the test case corresponding to the front-end page is determined to be missing. All test cases identified as missing are consolidated to generate the missing test case list.

6. An analysis apparatus for the impact of code changes on software test coverage, characterized in that, include: The code acquisition module is used to respond to the submission of software test requests and automatically acquire code change information corresponding to the current software test request. The impact scope generation module is used to determine the call chain of the modified code based on a pre-built code call relationship graph, determine the traffic entry points affected by the code change according to the call chain, and determine the affected front-end pages according to a pre-built mapping table between traffic entry points and front-end pages, so as to generate an impact scope list containing the affected traffic entry points and front-end pages. The tag management module is used to divide the test cases in the test case library into page test cases and interface test cases, and add structured tags to each test case; among them, the interface test case tag contains its corresponding traffic entry identifier, and the page test case tag contains its corresponding front-end page identifier. The matching and recommendation module is used to match the traffic entry identifier and front-end page identifier in the impact range list with the traffic entry identifier in the interface test case tag and the front-end page identifier in the page test case tag, respectively, and use the test cases that match as recommended test cases; The missing test case generation module is used to identify traffic entry points or front-end pages in the impact scope list that are not covered by any test case tags by comparing the tag coverage of test cases in the impact scope list with that in the test case library, generate a missing test case list, and send a prompt message to testers to supplement the missing test cases.

7. The apparatus for analyzing the impact of code changes on software test coverage according to claim 6, characterized in that, The influence range generation module is further used for: Based on static code analysis methods, the classes, methods, and / or functions involved in code change information are analyzed; By using the code call relationship graph, the call chain of the class, method and / or function is traced upstream. The traffic entry point that directly or indirectly calls the modified code is identified through the call chain, and the unique identification information of each traffic entry point is extracted.

8. The apparatus for analyzing the impact of code changes on software test coverage according to claim 6, characterized in that, The tag management module is further used for: Add structured tags to the interface use cases. The structured tags include interface type tags and traffic entry identifiers, wherein the interface type tags include HTTP, MQ, or RPC. Add structured tags to the page use case, the structured tags including the page URL for representing the front-end page identifier, and the back-end traffic entry identifier for representing the traffic entry on which the page depends.

9. The apparatus for analyzing the impact of code changes on software test coverage according to claim 8, characterized in that, The matching and recommendation module is further used for: For each traffic entry point in the impact scope list, query the test case library to see if there is an interface test case that matches both the interface type label and the traffic entry point identifier. For each front-end page in the impact scope list, query the test case library to see if there is a page test case with a matching page URL, or query if there is a page test case whose backend traffic entry identifier in the page test case tag matches any traffic entry identifier in the impact scope list.

10. The apparatus for analyzing the impact of code changes on software test coverage according to claim 8, characterized in that, The missing data generation module is further used for: Iterate through all traffic entry points and front-end pages in the list of affected areas; For any traffic entry point, if there is no interface test case in the test case library that matches both the interface type label and the traffic entry point identifier, then the test case corresponding to that traffic entry point is determined to be missing. For any front-end page, if there is no page test case in the test case library that matches the page URL, and there is no page test case in the page test case tag that matches any traffic entry identifier in the impact scope list, then the test case corresponding to the front-end page is determined to be missing. All test cases identified as missing are consolidated to generate the missing test case list.

Images