Regression test method and device based on interface, server and storage medium
By constructing an interface dependency graph and listening for change events, the problem of not being able to perceive runtime interface call dependencies in existing technologies is solved, and a precise regression testing process is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KYLIN CORP
- Filing Date
- 2026-01-16
- Publication Date
- 2026-04-28
AI Technical Summary
Existing technologies rely on static interface definitions and cannot perceive dynamic and complex interface call dependencies at runtime, resulting in inaccurate regression testing scope.
By acquiring the system's interface definition information and inter-interface call traffic information, an interface dependency graph is constructed. Interface change events are monitored, target interfaces and change information are identified, and it is determined whether the change is a structural change. When a structural change occurs, the dependency graph is traversed starting from the target interface, and test cases are matched to perform regression testing.
It enables dynamic perception and accurate analysis of the impact range of interface structural changes, and realizes an efficient automated testing process.
Smart Images
Figure CN121935155A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of testing technology, and in particular to an interface-based regression testing method, apparatus, server, and storage medium. Background Technology
[0002] With the widespread adoption of microservice architecture, modern applications typically consist of dozens or even hundreds of independent services that collaborate with each other through complex API call networks. In this distributed environment, any change to any interface can propagate and amplify along the dependency chain, triggering an unpredictable system-level "avalanche effect" that poses a serious challenge to overall stability.
[0003] Currently, most existing technologies rely on a single data source for impact analysis. For example, tools based on static interface definition documents can present core information such as the interface's request method, parameter types, return value structure, and error code definitions, becoming an important basis for development teams to design interfaces, integrate front-end and back-end, and conduct automated testing.
[0004] However, existing technical solutions have significant drawbacks. Their fundamental limitation lies in their complete reliance on fixed interface documentation defined during development, which makes them unable to reflect complex dynamic calling relationships at runtime. Summary of the Invention
[0005] This invention provides an interface-based regression testing method, apparatus, server, and storage medium to solve the technical problem that existing technologies, which rely entirely on static interface definitions, cannot perceive dynamic and complex interface call dependencies at runtime, resulting in inaccurate regression testing scope.
[0006] In a first aspect, embodiments of the present invention provide an interface-based regression testing method, comprising: Obtain the system's interface definition information and inter-interface call traffic information; Based on the interface definition information and the inter-interface call traffic information, construct an interface dependency graph; Listen for interface change events, and when the change event occurs, identify the target interface that has been changed and the change information; Based on the change information and preset rules, determine whether the change is a structural change. A structural change is a change that would cause interface compatibility to be compromised. When the change is a structural change, starting from the target interface, the interface dependency graph is traversed to find the dependent interfaces related to the target interface; Match the test cases for the dependent interfaces, and perform regression testing based on the test cases.
[0007] Secondly, embodiments of the present invention also provide an interface-based regression testing device, comprising: The acquisition module is used to acquire system interface definition information and inter-interface call traffic information; The construction module is used to construct an interface dependency graph based on the interface definition information and the call traffic information between interfaces; The identification module is used to listen for interface change events and, when the change event occurs, identify the target interface that has been changed and the change information. The judgment module is used to determine whether the change is a structural change based on the change information and preset rules. The structural change is a change that will cause interface compatibility to be broken. The traversal module is used to traverse the interface dependency graph starting from the target interface when the change is a structural change, and find the dependent interfaces related to the target interface. The matching module is used to match test cases for the dependent interfaces and perform regression testing based on the test cases.
[0008] Thirdly, embodiments of the present invention also provide a server, comprising: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the interface-based regression testing method provided in the above embodiments.
[0009] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the interface-based regression testing method provided in the above embodiments.
[0010] This invention provides an interface-based regression testing method, apparatus, server, and storage medium. The method acquires system interface definition information and inter-interface call traffic information; constructs an interface dependency graph based on the interface definition information and inter-interface call traffic information; monitors interface change events; when a change event occurs, it identifies the target interface and change information; based on the change information and preset rules, it determines whether the change is a structural change, which is a change that would break interface compatibility; when the change is a structural change, it traverses the interface dependency graph starting from the target interface to find dependent interfaces related to the target interface; matches test cases for the dependent interfaces, and performs regression testing based on the test cases. By constructing an interface dependency graph and monitoring change events, it achieves dynamic perception and impact range analysis of interface structural changes, thereby realizing a precise and efficient automated testing process. Attached Figure Description
[0011] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.
[0012] Figure 1 This is a flowchart of an interface-based regression test provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the interface dependency graph construction method based on interfaces provided in Embodiment 1 of the present invention. Figure 3 This is a flowchart illustrating the identification of changed target interfaces and change information in the interface-based regression testing method provided in Embodiment 1 of the present invention. Figure 4 This is a schematic diagram of the interface-based regression testing device provided in Embodiment 2 of the present invention; Figure 5 This is a structural diagram of the server provided in Embodiment 3 of the present invention. Detailed Implementation
[0013] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.
[0014] Example 1 Figure 1 This is a flowchart of interface-based regression testing provided in Embodiment 1 of the present invention. This embodiment is applicable to scenarios where the impact of interface changes is accurately identified and regression testing is performed. Specifically, it includes the following steps: Step 110: Obtain the system's interface definition information and inter-interface call traffic information.
[0015] In a microservice architecture system, there are numerous service interfaces with diverse functions. These interfaces are interconnected and collaborate through a complex network of calls, forming dynamic and highly coupled dependencies. To accurately analyze the impact of interface changes, it is first necessary to comprehensively obtain two types of core information describing the system.
[0016] Interface definition information is the static blueprint and contract of an interface, typically derived from system design documents, API description files, or service registries. This type of information explicitly specifies the interface's path, request method, input parameter structure and type, return value format, and possible error codes, among other contractual details.
[0017] Inter-interface call traffic information reflects the dynamic interaction of the system during actual runtime. It is obtained by collecting and analyzing information such as actual inter-service call logs, link tracing data from application performance monitoring tools, or network traffic mirroring. This data reveals runtime metrics such as which interfaces (callers) actually called which other interfaces (callees) within a specific time period, thus realistically depicting the dependency graph of how interfaces are actually called, and is an important supplement to static definitions.
[0018] For example, interface definition information of a system can be obtained by parsing the interface documentation through an open API. This method can be divided into two forms: active polling and passive reception. Active polling is a periodic synchronization mechanism based on a pull model. The caller actively sends requests to the open API at preset time intervals to query the interface documentation of the target project. Active polling can be further subdivided into full synchronization and incremental synchronization. Full synchronization retrieves the complete definition of all interfaces each time, which is simple to implement but has a large overhead. Incremental synchronization, by passing parameters such as timestamps or version numbers, only retrieves interface data that has changed since the last query, significantly improving synchronization efficiency. The advantage of the polling method is its universality and controllability, applicable to all environments that support open APIs. However, its real-time synchronization depends on the polling frequency, has a certain delay, and frequent calls may bring additional server load. Passive reception is based on a push model, usually implemented by configuring a Webhook. After a receiving address is preset in the API management tool, when an interface undergoes a change event such as creation, update, or deletion, the tool will automatically send an HTTP POST request to that address, with the payload containing detailed information about the change. This method achieves true near real-time synchronization, consumes low server resources, and can immediately detect changes. Both polling and webhooking can obtain complete static definition information of the interface, including its path, method, request / response parameter structure, sample data, and descriptions. Furthermore, the two methods can be combined, using webhooking as the primary channel for real-time triggering and low-frequency polling as a fallback mechanism to periodically verify data consistency, thereby building a highly efficient and robust interface definition synchronization system.
[0019] For example, inter-interface call traffic information can be obtained through a data collector in the application runtime environment. This can be implemented in two ways. One is to embed an APM (Application Performance Monitoring) agent (such as probes from SkyWalking or Pinpoint) into the application service. The agent runs non-intrusive or low-intrusively within the application process, automatically intercepting and collecting detailed information for each cross-service interface call, including the service identifiers of the caller and callee, interface path, timestamp, response status, and latency, and reporting this information to the analysis backend. The other approach is based on a service mesh data plane (such as the Envoy proxy in Istio). By subscribing to detailed access logs and metrics generated by sidecar proxies like Envoy, all inter-service API call traffic flowing through the mesh can be collected uniformly in an infrastructure-layer bypass manner.
[0020] Step 120: Construct an interface dependency graph based on the interface definition information and the inter-interface call traffic information.
[0021] Interface dependency graphs essentially merge and visualize a system's static contracts and dynamic behavior. By combining static data from API management tools (such as interface paths and request / response structures) with dynamic data from tracing or logs (such as the source, target, frequency, and performance of actual calls), they construct a map reflecting the true call chains and dependency strengths between services. Their core value lies in transforming discrete, hidden system relationships into global, explicit knowledge. They not only reveal explicit dependencies between interfaces but also uncover implicit or circular dependencies that are not documented, providing crucial insights for system architecture governance, fault location, change impact analysis, and performance optimization. For example, in architecture governance, this graph can identify architectural smells and vulnerable links; when a fault occurs, the root cause can be quickly located and the scope of impact assessed; and before implementing changes, all callers can be accurately identified to mitigate risks. Therefore, interface dependency graphs are a crucial cornerstone for achieving observability and continuous architectural evolution in modern distributed systems.
[0022] Figure 2 This is a flowchart illustrating the construction of an interface dependency graph in the interface-based regression testing method described in Embodiment 1 of the present invention. Figure 2 The construction of the interface dependency graph may include the following steps: Step 210: Generate interface nodes based on the interface definition information.
[0023] For example, interface nodes can be generated based on the interface definition information obtained in step 110. Step 210 essentially transforms the static, textual interface contract into basic logical units that can be identified, associated, and computed in the knowledge graph. Each interface node is a data entity containing a set of key attributes directly derived from the interface definition. These attributes typically include the interface's unique identifier (e.g., ID), complete request path, HTTP method (GET, POST, etc.), the name of the service or module to which it belongs, and optional metadata such as interface description and version. The significance of generating nodes lies in establishing a coordinate origin for subsequent dependency analysis. All dependencies in the knowledge graph will be drawn with these nodes as the starting or ending point. In this way, interfaces scattered throughout the document can be systematically mapped to entities in the knowledge graph.
[0024] Step 220: Based on the inter-interface call traffic information, parse the call relationship data of the interface nodes.
[0025] For example, based on the inter-interface call traffic information obtained in step 110, the call relationship data of the interface nodes can be parsed. The core task of step 220 is to clean, merge, and map the massive and discrete raw call logs or link tracing data collected in real time, thereby extracting structured information that can clearly describe the actual interaction relationship between interface nodes. Specifically, the parsing process will identify key fields in each call record, such as the caller service identifier, the specific interface path (Endpoint) of the callee, the HTTP method, the call timestamp, and the response result, and accurately match and associate them with the static interface nodes generated in step 210.
[0026] Step 230: Query the graph database to see if the interface node exists. If the interface node does not exist, create the interface node in the graph database.
[0027] Graph databases are non-relational databases specifically designed for storing and querying networks of relationships between entities. Using graphs as their basic data structure, graph databases abstract entities as nodes and relationships between entities as edges, allowing both to possess rich attributes. This data model is highly compatible with the needs of constructing interface dependency graphs because graph databases can intuitively and efficiently represent entities such as interfaces and services, as well as the complex call and membership relationships between them. This makes queries such as finding all upstream dependencies of a given interface or analyzing call chains between services exceptionally direct and fast.
[0028] Optionally, the operation in step 230 of this embodiment can be completed using the MERGE command in the graph database. The MERGE command is not a simple two-step process of querying and then judging, but a declarative statement whose atomicity and efficiency are guaranteed by the database engine. For example, MERGE (i:Interface {id: 'POST / api / v1 / orders'}) ON CREATE SET i.service = 'order-service'. When the database engine executes this command, it first performs an index search in the graph based on the node label (:Interface) and key attribute (id). If a matching node is found, it directly returns the existing node; if not found, it automatically creates a new node with the defined attributes. This addresses the issues of duplicate creation or race conditions that may occur during concurrent data writing.
[0029] Step 240: Query the graph database to see if there is a call relationship between the interface nodes. If there is no call relationship, construct a call relationship edge based on the call relationship data.
[0030] Optionally, step 240 can be implemented as follows: First, the system has already ensured the existence of the two corresponding Interface nodes in the database based on the caller's interface ID ($caller_interface_id) and the callee's interface ID ($callee_interface_id). Next, by executing a query like MERGE (caller)-[r:CALLS]->(callee), the database engine attempts to precisely find a specific relationship edge of type CALLS in the graph, pointing from the caller node to the callee node. If this edge does not exist, the graph database creates it and executes the ONCREATE clause (e.g., initializing the call count to 1 and recording the current timestamp in the last_called attribute). If this edge already exists, the database locates the existing relationship and executes the ON MATCH clause (e.g., incrementing the count attribute by 1 and updating the last_called timestamp). This mechanism ensures that dynamic metrics such as call frequency and last call time can be accurately and efficiently aggregated on the relationship edges, so that the dependency graph can not only reflect the static who calls whom, but also dynamically characterize the intensity and activity of the calls.
[0031] Step 250: Construct an interface dependency graph based on the interface node and the call relationship edge.
[0032] For example, step 250 is the process of integrating the processed static and dynamic data into a complete knowledge graph. Interface nodes contain the static definition and attribution information of the interfaces, forming the entity foundation of the graph; while call relationship edges record the dynamic, quantified call interactions between nodes. By associating and combining these two, an interface dependency graph is constructed.
[0033] Step 130: Listen for interface change events. When the change event occurs, identify the target interface that has been changed and the change information.
[0034] Figure 3 This is a flowchart illustrating the identification of changed target interfaces and change information in the interface-based regression testing method described in Embodiment 1 of the present invention. Figure 3 The process of identifying the changed target interface and change information may include the following steps: Step 310: Listen for interface change events. When the change event occurs, obtain the interface definition file before the change and the interface definition file after the change.
[0035] Step 320: Perform a difference analysis on the interface definition file before and after the change to identify the target interface and change information that have been changed.
[0036] In a microservice architecture, interfaces are the core contracts for internal and external interactions within the system. As business requirements iterate and the system architecture evolves, interface changes are inevitable, such as adding new functional endpoints, modifying request / response structures, deprecating old parameters, or adjusting URL paths. If these changes are not captured and managed promptly and accurately, they can easily lead to service failures in downstream callers, incomplete test coverage, or outdated documentation, thereby causing system integration errors and stability risks.
[0037] Optionally, listening for API change events can be implemented in two ways: First, by configuring a webhook for the code repository (e.g., Git) to listen for push events on relevant branches. When an event is triggered, the `git diff` command can be used to compare the differences between the current and previous commits of a specific API definition file (e.g., a Swagger file), directly obtaining standardized line-level changes. This naturally creates a comparison view before and after the change. Second, by subscribing to a webhook of an API management tool (e.g., Apifox), when an API documentation update event is triggered, the open API is synchronously called to obtain the complete definition documents (usually in JSON format) of the previous and current latest versions of the API managed by the system. This method accurately identifies the specific API (target API) that has undergone changes and extracts detailed change information, including the change type (addition, modification, deletion), change location (e.g., API path, request parameters, response body fields), and the specific content of the changes. This provides precise input for subsequent dependency impact analysis and test case generation.
[0038] Step 140: Based on the change information and preset rules, determine whether the change is a structural change, wherein the structural change is a change that would cause interface compatibility to be compromised.
[0039] For example, in this embodiment, structural changes refer to fundamental modifications that break the existing contract of the interface and impair backward compatibility for clients. These changes typically directly affect the data structure and mandatory conventions of the interface's requests or responses, preventing callers that haven't been updated from interacting or parsing data correctly. Examples include deleting or renaming existing request / response fields, modifying the data type of fields (e.g., changing strings to integers), making previously optional parameters mandatory, or changing the interface's HTTP method or base URL path. Conversely, non-structural changes refer to enhancements or adjustments made without breaking the existing contract. These changes are transparent to existing callers and do not cause service interruptions or functional abnormalities. Examples of non-structural changes include adding optional request parameters to the interface, adding new fields to the response body, expanding the value range of enumeration types, optimizing the interface's descriptive text or examples, and refactoring the internal implementation logic without changing the semantics.
[0040] For example, step 140 can be implemented as follows: First, identify the interface change type based on the change information from step 130, such as "deleting a request field," "modifying a field type," "adding a response field," or "modifying the interface description." Then, match each change type against a pre-defined rule base, which explicitly specifies which types are structural changes that would break compatibility. For example, the rule base defines structural changes such as "deleting required request parameters," "adding parameter constraints (e.g., changing optional to required)," "modifying the data type of parameters (e.g., changing string to integer)," and "deleting or renaming existing response fields." The system automatically performs this matching judgment, labeling each change with a Boolean value and a specific enumeration value. Finally, the system summarizes all analysis results and generates a standardized structured change report. This report clearly lists the target interface, change type, destructive judgment, detailed description, and code snippets before and after the change for each change, providing accurate and actionable basis for subsequent dependency impact analysis, notification release, and version decisions.
[0041] Step 150: When the change is a structural change, starting from the target interface, traverse the interface dependency graph to find the dependent interfaces related to the target interface.
[0042] In graph databases, traversal refers to the process of systematically accessing all or part of the nodes and relationships in a graph according to specific rules or algorithms. It is the core operation for extracting valuable information from the graph structure. Unlike table queries in relational databases, graph traversal queries along the relationship paths between nodes, efficiently revealing complex direct or indirect connections between data points. For example, starting from a specific interface node, a depth-first or breadth-first traversal can be performed along the CALLS relationship to discover all its direct and indirect downstream dependencies, thereby drawing a complete call chain.
[0043] Optionally, after determining a structural change in step 140, a graph traversal query is performed on the interface dependency graph constructed in step 120, starting with the target interface that has undergone the structural change (e.g., User Service::GET / api / v1 / users / {id}). This can be accomplished by sending predefined traversal statements to a graph database (such as Neo4j), specifically using two strategies: First, a direct dependency analysis strategy, using the MATCH (affected)-[:CALLS]->(changed) query to accurately identify all first-level downstream interfaces that directly call the target interface; second, a more comprehensive multi-level dependency analysis, using a variable-length path query like MATCH path = (affected)-[:CALLS*1..5]->(changed), which, through recursive searching, can discover all far-end upstream interfaces that indirectly depend on the target interface from layer 1 to layer N (e.g., layer 5). After the traversal is complete, the database returns all matching relationship paths, and the system then extracts and summarizes the interface nodes at the end of the paths, thereby accurately determining a complete list of affected interfaces. This automated traversal process maps isolated interface changes into a chain of impacts throughout the entire system call network.
[0044] Step 160: Match the test cases of the dependent interfaces and perform regression testing based on the test cases.
[0045] A test case is the smallest unit of execution in software testing activities. It is a set of predefined conditions, inputs, execution steps, and expected results used to verify whether a specific function or requirement works as expected. In the context of interface testing, a typical test case precisely describes how a specific API endpoint is invoked, including the request method, URL, request headers, request parameters, or request body data, and explicitly specifies under what conditions the response status code, response headers, and response body structure should be returned. Its core value lies in transforming abstract interface contracts into concrete checks that can be automatically executed and repeatedly verified.
[0046] Regression testing involves re-executing existing test cases after software modifications to ensure that these changes do not introduce new defects or break existing, unmodified functionality. Its fundamental purpose is to maintain the normal operation of the software and prevent global functional degradation caused by local changes. In a microservice architecture, due to the complex dependency network between services, a structural change to an interface can trigger seemingly unrelated functional anomalies on remote endpoints through the call chain, making regression testing both crucial and extremely challenging.
[0047] For example, after determining the dependent interfaces related to the target interface in step 150, all test cases specifically used to verify the functionality of the dependent interfaces can be retrieved and filtered from a central test case library (such as Apifox's test management module) based on a preset "interface-test case" mapping relationship. This process ensures the high accuracy of the test set. Then, this automatically generated accurate regression test set can be submitted and triggered for automated execution via command-line tools or by calling the API of a continuous integration platform (such as Jenkins). The test execution engine (such as Apifox CLI, PostmanCollection Runner, or a test framework integrated in CI) will run these test cases and collect the results. Finally, through a closed-loop process, highly targeted regression testing for interface changes is completed. Regression testing accurately locates downstream dependencies affected by upstream structural changes and selects the corresponding test case set for verification, thereby achieving regression verification.
[0048] This embodiment acquires the system's interface definition information and inter-interface call traffic information; constructs an interface dependency graph based on the interface definition information and inter-interface call traffic information; monitors interface change events, and when a change event occurs, identifies the target interface and change information; determines whether the change is a structural change based on the change information and preset rules, where a structural change is one that would break interface compatibility; when the change is a structural change, traverses the interface dependency graph starting from the target interface to find dependent interfaces related to the target interface; matches test cases for the dependent interfaces, and performs regression testing based on the test cases. By constructing an interface dependency graph and monitoring change events, dynamic perception and impact analysis of interface structural changes are achieved, thereby realizing a precise and efficient automated testing process.
[0049] Example 2 Figure 4 This is a schematic diagram of the interface-based regression testing device provided in Embodiment 2 of the present invention, as shown below. Figure 4 As shown, the device includes: The acquisition module 410 is used to acquire the system's interface definition information and inter-interface call flow information; Module 420 is used to construct an interface dependency graph based on the interface definition information and the call flow information between interfaces; The identification module 430 is used to listen for interface change events and identify the target interface and change information when the change event occurs. The judgment module 440 is used to determine whether the change is a structural change based on the change information and preset rules, wherein the structural change is a change that will cause interface compatibility to be broken. The traversal module 450 is used to traverse the interface dependency graph starting from the target interface when the change is a structural change, and find the dependent interfaces related to the target interface. The matching module 460 is used to match the test cases of the dependent interface and perform regression testing based on the test cases.
[0050] The interface-based regression testing device provided in this embodiment acquires the system's interface definition information and inter-interface call traffic information; constructs an interface dependency graph based on the interface definition information and inter-interface call traffic information; monitors interface change events, and when a change event occurs, identifies the target interface and change information; determines whether the change is a structural change based on the change information and preset rules, where a structural change is a change that would break interface compatibility; when the change is a structural change, it traverses the interface dependency graph starting from the target interface to find dependent interfaces related to the target interface; matches test cases for the dependent interfaces, and performs regression testing based on the test cases. By constructing an interface dependency graph and monitoring change events, it achieves dynamic perception and impact range analysis of interface structural changes, thereby realizing a precise and efficient automated testing process.
[0051] Based on the above embodiments, the building module includes: An interface node generation unit is used to generate interface nodes based on the interface definition information. The call relationship data parsing unit is used to parse the call relationship data of the interface nodes based on the call traffic information between the interfaces; An interface node determination unit is used to query whether the interface node exists in the graph database, and if the interface node does not exist, to create the interface node in the graph database. The call relationship determination unit is used to query the graph database to see if there is a call relationship between the interface nodes. If there is no call relationship, a call relationship edge is constructed based on the call relationship data. The graph construction unit is used to construct an interface dependency graph based on the interface nodes and the call relationship edges.
[0052] Based on the above embodiments, the identification module includes: The interface definition file acquisition unit is used to listen for interface change events and, when the change event occurs, acquire the interface definition file before the change and the interface definition file after the change. The interface change identification unit is used to perform difference analysis on the interface definition file before the change and the interface definition file after the change, and to identify the target interface and change information that have been changed.
[0053] Based on the above embodiments, the determination module includes: The change type identification unit is used to identify the interface change type based on the change information; The preset rule matching unit is used to determine whether the change is a structural change based on whether the interface change type is within the preset rules. The preset rules include deleting required request parameters, adding constraints to request parameters, modifying the data type of parameters, and deleting or renaming response fields.
[0054] The interface-based regression testing device provided in this embodiment of the invention can execute the interface-based regression testing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0055] Example 3 Figure 5 This is a schematic diagram of the structure of a server provided in Embodiment 3 of the present invention. Figure 5 A block diagram is shown of an exemplary server 12 suitable for implementing embodiments of the present invention. Figure 5 The server 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.
[0056] like Figure 5 As shown, server 12 is presented in the form of a general-purpose computing server. The components of server 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).
[0057] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.
[0058] Server 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by server 12, including volatile and non-volatile media, removable and non-removable media.
[0059] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Server 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.
[0060] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.
[0061] Server 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing server, display 24, etc.), and with one or more servers that enable users to interact with server 12, and / or with any server (e.g., network card, modem, etc.) that enables server 12 to communicate with one or more other computing servers. This communication can be performed via input / output (I / O) interface 22. Furthermore, server 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of server 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with server 12, including but not limited to: microcode, server drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0062] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the interface-based regression testing method provided in the embodiments of the present invention.
[0063] Example 4 Embodiment 4 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the interface-based regression testing methods provided in the above embodiments.
[0064] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0065] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.
[0066] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0067] Computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0068] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.
Claims
1. An interface-based regression testing method, characterized in that, include: Obtain the system's interface definition information and inter-interface call traffic information; Based on the interface definition information and the inter-interface call traffic information, construct an interface dependency graph; Listen for interface change events, and when the change event occurs, identify the target interface that has been changed and the change information; Based on the change information and preset rules, determine whether the change is a structural change. A structural change is a change that would cause interface compatibility to be compromised. When the change is a structural change, starting from the target interface, the interface dependency graph is traversed to find the dependent interfaces related to the target interface; Match the test cases for the dependent interfaces, and perform regression testing based on the test cases.
2. The method according to claim 1, characterized in that, The step of constructing an interface dependency graph based on the interface definition information and the inter-interface call traffic information includes: Based on the interface definition information, an interface node is generated; Based on the call traffic information between the interfaces, the call relationship data of the interface nodes is parsed. The system queries the graph database to see if the interface node exists. If the interface node does not exist, it is created in the graph database. The system queries the graph database to determine if a call relationship exists between the interface nodes. If no call relationship exists, a call relationship edge is constructed based on the call relationship data. Based on the interface nodes and the call relationship edges, construct an interface dependency graph.
3. The method according to claim 1, characterized in that, The monitoring interface change event, when the change event occurs, identifies the target interface that has changed and the change information, including: Listen for interface change events, and when the change event occurs, obtain the interface definition file before the change and the interface definition file after the change; A difference analysis was performed on the interface definition file before and after the change to identify the target interface and change information that were changed.
4. The method according to claim 1, characterized in that, The acquisition of system interface definition information and inter-interface call traffic information includes: By parsing the interface documentation and data collectors in the application runtime environment through the open API, we can obtain the system's interface definition information and the call traffic information between interfaces.
5. The method according to claim 1, characterized in that, The monitoring interface change event includes: Listen for API change events through push events from the code repository; or Listen for interface change events through the synchronization events of the API management tool.
6. The method according to claim 1, characterized in that, Based on the change information and preset rules, determine whether the change is a structural change, including: Based on the change information, identify the type of interface change; Based on whether the interface change type is within the preset rules, it is determined whether the change is a structural change. The preset rules include deleting required request parameters, adding constraints to request parameters, modifying the data type of parameters, and deleting or renaming response fields.
7. The method according to claim 1, characterized in that, The interface dependency graph is traversed to find the dependent interfaces related to the target interface, including: A breadth-first search is performed on the interface dependency graph to find the dependent interfaces related to the target interface.
8. An interface-based regression testing device, characterized in that, include: The acquisition module is used to acquire system interface definition information and inter-interface call traffic information; The construction module is used to construct an interface dependency graph based on the interface definition information and the call traffic information between interfaces; The identification module is used to listen for interface change events and identify the target interface and change information when the change event occurs. The judgment module is used to determine whether the change is a structural change based on the change information and preset rules. The structural change is a change that will cause interface compatibility to be broken. The traversal module is used to traverse the interface dependency graph starting from the target interface when the change is a structural change, and find the dependent interfaces related to the target interface. The matching module is used to match test cases for the dependent interfaces and perform regression testing based on the test cases.
9. A server, characterized in that, The server includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the interface-based regression testing method as described in any one of claims 1-7.
10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the interface-based regression testing method as described in any one of claims 1-7.