Interface automatic test method and system based on dependency graph topology arrangement and medium

Abstract

This invention discloses an automated interface testing method, system, and medium based on dependency graph topology orchestration. The method transforms interface definition data into unified interface nodes and generates dependency edge objects, forming a complete set of dependency relationships. In response to test tasks, it extracts dependency edges from the current execution chain to form a local dependency subgraph and generates an execution queue through topological sorting. A runtime context container is established, and nodes are executed sequentially. After each node is executed, response variables are extracted and updated to the context for subsequent request replacement and injection. When executing the main request, the business result is evaluated based on a success judgment expression. Execution trajectories are recorded by role, and a structured report with hierarchical display is output. This invention stores interface dependency relationships as objects and achieves the technical effects of queryable and auditable dependencies, traceable variable propagation, and interpretable test results through topological orchestration of local dependency subgraphs and unified management of runtime context.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an automated interface testing method, system, and medium based on dependency graph topology orchestration. Background Technology

[0002] The core of automated API testing relies on the accurate identification of dependencies between APIs and the correct orchestration of their execution order. In a microservice architecture, a complete business operation typically requires the sequential invocation of multiple APIs. Strict data transfer and execution triggering relationships exist between stages such as login authentication, data preparation, main business operations, and post-cleanup. The accuracy and stability of test results highly depend on whether dependencies are correctly resolved, variables are correctly propagated, and business success criteria are accurately determined.

[0003] Currently, the mainstream approach to automated testing in multi-interface scenarios is scripting or tool-based methods. This involves manually writing dependency logic in pytest pre-scripts, Postman preprocessing scripts, JMeter extractors, or custom hooks, and then having testers manually maintain environment variables, business object identifiers, and assertion conditions. This approach works when the number of interfaces is small, but it has the following significant drawbacks in large-scale interface governance and continuous regression scenarios:

[0004] (1) The dependencies are hidden in discrete scripts and lack a unified dependency graph model, which makes the dependencies unqueryable, unreusable, and unauditable; when the front-end interface structure changes, the downstream scripts are prone to failure and difficult to locate quickly.

[0005] (2) The execution order between interfaces in the existing scheme is determined by the script writing order or manual configuration. It lacks an automated topology orchestration mechanism oriented towards dependent edges, and is easily affected by dirty configuration and circular dependencies, resulting in incorrect execution order or execution interruption.

[0006] (3) Environment variables, upstream extracted fields, identity tokens and other variables are stored in different scopes (such as Postman's environment variables, global variables and local variables), lacking unified runtime context management, which can easily lead to variable loss, placeholder replacement errors and cross-use issues.

[0007] (4) Existing assertion mechanisms (such as patent CN117389908B) mainly rely on static assertions of HTTP status codes or response fields, which cannot cover the dynamic success determination requirements in complex business scenarios such as polling wait, asynchronous auditing, and resource compensation, resulting in a high misjudgment rate of test results;

[0008] (5) Existing reporting systems (such as patent CN115098389A) mainly display pass / fail results or original logs, lacking the ability to display structured hierarchical data by dependent role. When the preceding dependency fails, the main call fails, or the post-cleanup fails, it is impossible to quickly locate the failure link and the cause path, resulting in high troubleshooting costs.

[0009] In summary, interface automation testing technology has rigid requirements for the orchestration of dependencies, the traceability of variable propagation, and the interpretability of test results. However, existing scripting and tool-based solutions cannot cope with issues such as fragmented dependencies, chaotic variable propagation, and dynamic judgment in complex business scenarios. This makes it difficult to guarantee the stability and efficiency of large-scale regression testing, and better technical solutions are urgently needed to address these core pain points. Summary of the Invention

[0010] The purpose of this invention is to provide an automated interface testing method, system, and medium based on dependency graph topology orchestration, thereby solving all or one of the aforementioned problems in the prior art.

[0011] To solve the above-mentioned technical problems, the specific technical solution of the present invention is as follows:

[0012] On the one hand, the present invention provides an automated interface testing method based on dependency graph topology orchestration, comprising the following steps: converting interface definition data into unified interface nodes and persistently storing them, wherein the request body of the interface node contains replaceable placeholders; analyzing the metadata of the interface node based on a preset dependency discovery strategy, generating candidate dependency edges from upstream interface to downstream interface, standardizing the candidate dependency edges into dependency edge objects of a unified format, and all the dependency edge objects constituting a full dependency relationship set;

[0013] In response to the test task triggering operation, the target interface specified by the operation is determined as the main request node. The dependency edges required for the current execution chain are extracted from the full dependency set. Based on the differentiated execution strategy associated with the current test task, the extracted interface node definitions and dependencies are contextualized to form a local dependency subgraph within the current execution boundary. The interface nodes in the local dependency subgraph are topologically sorted to generate an ordered execution queue.

[0014] A runtime context container is established, and each pre-dependent interface node is executed sequentially according to the ordered execution queue. After each pre-dependent interface node is executed, variables are extracted from the response and updated to the runtime context container. Then, the placeholders in subsequent requests are replaced and injected with the updated runtime context.

[0015] After completing all the preceding dependent interface nodes, the main request node is executed. The business result is evaluated based on the success judgment expression corresponding to the main request node, and the subsequent steps are executed after the main request node is completed.

[0016] Record the execution trajectory information of each interface node according to the preset role type, assemble it into a structured test report that is displayed hierarchically according to the dependent roles, and output it.

[0017] As an improved approach, the differentiated execution strategy is used to locally adapt global interface definitions and global dependencies, enabling the same interface node to be reused in different business processes with differentiated parameters and runtime strategies; wherein, the implementation of the differentiated execution strategy includes suite-level coverage configuration or task-level coverage configuration.

[0018] As an improved approach, the dependency discovery strategy includes: flattening the request body, response body, and description information of each interface node into structured field paths, and generating the candidate dependency edges by combining at least one of value matching, inclusion matching, high-frequency identity field rules, CRUD semantic order, and version isolation rules; the high-frequency identity field rules include at least the identification rules for login status fields and authentication fields, and the metadata includes at least the request body structure, response body structure, and interface description information.

[0019] As an improved solution, the dependency edge object includes at least a dependency interface identifier, a dependency role, an extraction expression, an injection placeholder, a runtime strategy, and a post-trigger condition; the dependency role distinguishes between pre-dependencies and post-dependencies; and the preset role type is derived from the dependency roles in the dependency edge object.

[0020] As an improved solution, the success determination expression is pre-configured in the interface node. It is a business-level pass condition expression, distinct from HTTP status codes, used to determine whether the interface return result meets the business success criteria.

[0021] As an improved approach, the runtime context container includes at least environment variables, system variables, user input, identity token, polling status, and phased execution results; when updating the runtime context, the extracted results are merged with the existing variables in the runtime context container.

[0022] As an improved approach, when performing topological sorting on the interface nodes in the local dependency subgraph, the interface nodes are sorted according to the consumption relationship between the extracted fields and placeholders carried by the dependency edges; and the preset type attributes or cyclic characteristics of the dependency relationships of each interface node are identified, and the sorting results are preferentially executed or protectively adjusted; wherein, the preferential execution or protective adjustment specifically includes: when a login interface is detected, the login interface is preferentially sorted before other interfaces that depend on the login state; when a cyclic dependency is detected, degradation processing is performed and a recursive protection mechanism is triggered.

[0023] As an improved solution, the post-processing step includes triggering and executing a preset post-processing chain based on the post-triggering conditions in the dependent edge object. The post-processing chain is used to complete at least one of the following: verification, synchronization, recycling, or advancement of the business process. The post-processing chain consists of at least one post-dependent interface node, which includes a cleanup node, a compensation node, a polling wait node, or an audit auxiliary workflow node. The polling wait node controls the polling interval, polling count, and termination conditions according to a runtime strategy. The audit auxiliary workflow is an extended business execution chain triggered based on the business object identifier, external identity state, and database state after the main request node completes. The runtime strategy includes at least a failure blocking strategy, a warning-only-not-blocking strategy, a skip execution strategy, and a waiting-for-polling strategy.

[0024] On the other hand, the present invention also provides an interface automated testing system based on dependency graph topology orchestration, including: an interface asset modeling module, used to unify interface information into interface nodes for persistent storage;

[0025] The dependency analysis and standardization module is used to generate candidate dependency edges based on the interface nodes and normalize them into a unified dependency edge object.

[0026] The graph relationship persistence module is used to persistently store the interface nodes and the unified dependency edge objects;

[0027] The topology orchestration execution module is used to respond to test tasks, extract the corresponding local dependency subgraphs and overlay local coverage configurations, perform topology sorting on the local dependency subgraphs and drive each interface node to run in sequence;

[0028] The runtime context management module is used to maintain a unified set of variables when executing each node, and to query the corresponding value based on the placeholder to complete the request replacement;

[0029] The business judgment and strategy module is used to perform business success judgment on the returned result and control the execution strategy.

[0030] The interpretable report generation module is used to record execution trajectory information according to preset role types and output a layered test report.

[0031] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the interface automation testing method based on dependency graph topology orchestration.

[0032] The beneficial effects of the technical solution of this invention are:

[0033] 1. The interface automation testing method based on dependency graph topology orchestration described in this invention can achieve stable execution and accurate attribution of automated tests in multi-interface business scenarios. It effectively resists interference from fragmented dependency configurations, chaotic variable propagation, and distorted business judgments. It ensures that the test execution order strictly follows the dependency relationship, variables are accurately passed between interface nodes, and the cause of failure can be accurately located to the specific dependency link. It meets the long-term automated operation requirements of large-scale interface regression testing, scenario orchestration, and continuous integration scenarios, makes up for the deficiencies of existing technologies, and has high application value.

[0034] 2. The interface automated testing system based on dependency graph topology orchestration described in this invention can realize the interface automated testing method based on dependency graph topology orchestration described in this invention through the cooperation of system modules.

[0035] 3. The computer-readable storage medium of the present invention can enable the system modules to cooperate, thereby realizing the interface automated testing method based on dependency graph topology orchestration of the present invention. The computer-readable storage medium of the present invention effectively improves the operability of the interface automated testing method based on dependency graph topology orchestration. Attached Figure Description

[0036] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0037] Figure 1 This is a core flowchart of the intelligent interface automated testing based on dependency graph topology orchestration and runtime context management in an embodiment of the present invention;

[0038] Figure 2 This is a schematic diagram of the login page interface of the intelligent interface automated testing platform according to an embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of the homepage and functional features of the intelligent interface automated testing platform according to an embodiment of the present invention;

[0040] Figure 4 This is a schematic diagram of the test task management interface of the intelligent interface automated testing platform according to an embodiment of the present invention. Detailed Implementation

[0041] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.

[0042] In the description of this invention, it should be noted that the embodiments described in this invention are only some embodiments of this invention, not all embodiments; based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0043] The terms “comprising” and “having”, and any variations thereof, in the description, claims, and accompanying drawings herein are intended to cover a non-exclusive inclusion, such that a process, method, apparatus, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or device.

[0044] In the description of this invention, it should be noted that:

[0045] An API node is an interface object that uniformly stores the interface name, method, URL, request header, parameters, request body, response body, and business attributes.

[0046] Differentiated execution strategies are strategy mechanisms associated with test tasks for local adaptation of global interface definitions and global dependencies. In some embodiments, they are also referred to as local coverage configuration or suite coverage. Specific implementations may include suite-level coverage configuration, task-level coverage configuration, or rule-based dynamic adaptation strategies. In this invention, the above terms are used interchangeably and all refer to the same concept.

[0047] Dependency edges are structured configurations that describe the data transfer and execution triggering relationships between upstream and downstream interfaces, distinguishing different roles such as pre-dependencies and post-dependencies.

[0048] Field mapping is a set of rules used to describe the extraction of variables from upstream responses and their injection into downstream requests, employing either explicit extraction expressions or predefined identity field rules.

[0049] The runtime context is a set of variables maintained during a debugging, orchestration, or task execution, including at least environment variables, user input, extracted results, identity tokens, execution status, and intermediate artifacts.

[0050] Success determination expressions are business-level conditional expressions that differ from HTTP status codes, used to determine whether the interface return result meets the business success criteria.

[0051] Runtime policies are a set of policies that control behaviors such as execution waiting, polling, failure handling, skipping, or alerting.

[0052] Suite overriding is a mechanism that partially rewrites the global interface definition for the current orchestration suite or the current task, so that the same interface can be reused in different business processes, but the parameters and strategies can be differentiated.

[0053] A local dependency subgraph is a subset of dependencies formed by extracting the dependency edges required for the current execution chain from the full dependency set in response to the currently selected test case, orchestration suite, or test task, and then overlaying the local coverage configuration of the current suite or task.

[0054] The audit auxiliary workflow is a type of extended business execution chain that is triggered after the main request is completed, based on the business object identifier, external identity status, and database status.

[0055] Explainable reports are different from traditional reports that simply show whether a request passed or failed. They are structured reports that show the request trajectory, judgment conditions, polling process, and failure attribution according to roles such as pre-dependencies, main callers, post-dependencies, and audit links.

[0056] Example 1: This example provides an automated interface testing method based on dependency graph topology orchestration to solve the technical problems of hidden dependencies in scripts, chaotic variable propagation, and uninterpretable test results in multi-interface scenarios. Figure 1 As shown, it includes:

[0057] S100, Interface Asset Modeling Steps, including:

[0058] S101. Collect interface data: Convert the document parsing results, packet capture import results, or manual maintenance results into unified interface nodes. The interface node shall at least include the interface name, HTTP method, URL, request header, parameters, request body, response body, version, responsible person, dependency configuration, extraction configuration, post-configuration, runtime strategy, and success judgment expression. The interface node shall be persistently stored as the authoritative data source for subsequent dependency analysis and execution orchestration.

[0059] S102. Generate candidate dependency edges: Based on a pre-configured dependency discovery strategy, the metadata of each interface node is automatically analyzed to generate candidate dependency relationships from upstream to downstream interfaces. The metadata includes at least the request body structure, response body structure, and interface description information. Specifically, the stored request body, response body, and description information of each interface node can be flattened into structured field paths. The candidate dependency edges are generated by combining at least one of value matching, containment matching, high-frequency identity field rules, CRUD semantic order, and version isolation rules. The high-frequency identity field rules include at least the identification rules for login status fields and authentication fields. The candidate dependency relationships contain at least a portion of dependency information derived from legacy test scripts, manual historical configurations, or externally imported configurations.

[0060] S103. Standardize Dependency Configuration: Normalize historically inconsistent dependency configurations into unified dependency edge objects. Each dependency edge object includes at least a dependency interface identifier, dependency role, extraction expression, injection placeholder, runtime strategy, and post-trigger condition. The dependency role distinguishes between pre-dependencies and post-dependencies. All standardized dependency edge objects together constitute a full dependency set, serving as the data source for subsequent local dependency subgraph extraction.

[0061] S200, the steps of constructing local dependency subgraphs and topology orchestration include:

[0062] S201. Constructing a Local Dependency Subgraph: In response to test case selection, orchestration suite selection, or test task triggering operations, the target interface specified by the operation is determined as the main request node. Dependency edges required for the current execution chain are extracted from the full dependency relationships. Based on the differentiated execution strategy bound to the current test task, the extracted interface node definitions and dependencies are contextually adapted to form a local dependency subgraph within the current execution boundary. The differentiated execution strategy is used to locally adapt global interface definitions and global dependencies, allowing for differentiated parameters and runtime strategies when the same interface is reused in different business processes. Specific implementations of the differentiated execution strategy may include suite-level coverage configuration, task-level coverage configuration, or rule-based dynamic adaptation strategies.

[0063] S202. Perform topology orchestration: Based on the consumption relationship between the extracted fields and placeholders carried by the dependency edges, sort the interface nodes in the local dependency subgraph; on this basis, identify the preset type attributes of each interface node (such as specific type nodes that need to be executed first, such as login interfaces) or structural anomalies in the dependency relationship (such as circular dependencies), and dynamically apply priority execution or protective adjustments to the sorting results. For example, when a login interface is detected, the login interface is prioritized for execution before other interfaces that depend on the login state; when a circular dependency is detected, degradation processing is performed and a recursive protection mechanism is triggered.

[0064] S300, runtime context management and execution steps, including:

[0065] S301. Initialize runtime context: Before executing the current task, establish a unified runtime context container, which includes at least environment variables, system variables, user input, identity token, polling status, and phased execution results.

[0066] S302. Execute the preceding dependency nodes and update the context: Execute each preceding dependency interface node in sequence according to the topology orchestration result; after executing each preceding dependency interface node, extract variables from the response according to the extraction expression corresponding to the node, merge the extraction result with the environment variables, user input, identity token and system variables in the runtime context container, and then use the merged runtime context to replace and inject placeholders in subsequent requests.

[0067] S303. Execute the main request and make a business decision: After completing all the prerequisite dependent interface nodes, execute the main request and evaluate the business result based on the success decision expression corresponding to the main request, rather than just based on the HTTP status code; the success decision expression is used to describe the pass conditions at the business level.

[0068] S304. Execute post-processing steps: After the main request is completed, a preset post-processing chain is triggered and executed according to the post-dependency configuration to complete the closed-loop processing of the business process. The closed-loop processing includes at least one of the following: verification of business results, synchronization of status, resource reclamation, or advancement of business links. Specifically, the post-processing chain consists of at least one post-dependency interface node, which can be executed sequentially, including cleanup, compensation, polling wait, or audit auxiliary workflow; wherein, the polling wait controls the polling interval, polling count, and termination condition according to the runtime strategy; the audit auxiliary workflow is a type of extended business execution chain triggered after the main request is completed, based on the business object identifier, external identity status, and database status.

[0069] S305. In steps S302 to S304, the runtime strategy of each interface node includes at least a failure blocking strategy, an alarm-only strategy, a skip execution strategy, and a waiting polling strategy.

[0070] S400, the interpretable report generation steps include:

[0071] S401. Record request trajectory: Record the request information, response information, execution status, time consumption, polling summary, success judgment summary and failure attribution information of each interface node according to the roles of pre-dependency, main caller, post-dependency and audit auxiliary workflow.

[0072] S402. Generate a structured report: Assemble the information recorded in step S401 into a structured test report. The structured test report shall at least include the role label of each interface node, full request and response data, variable extraction and injection trajectory, polling process record, success determination criteria, and hierarchical display of failure attribution.

[0073] S403, External Notification and Feedback: Push test task results, report address, failure responsible person and suggestion information to the notification module, and write execution feedback back to the dependency governance and test asset management chain.

[0074] This embodiment, through the above steps, objectifies and structures the dependencies, field extraction rules, and runtime strategies that were originally hidden in the script. It replaces the global interface list with a local dependency subgraph as the topology orchestration input, and uniformly maintains the variable production, propagation, and consumption of the runtime context during execution, ultimately generating an interpretable report that is displayed hierarchically according to the execution role.

[0075] Example 2: This example provides an automated interface testing system based on dependency graph topology orchestration, used to implement the method described in Example 1. See [link to example]. Figures 2 to 4 ( Figures 2 to 4 (This diagram illustrates the platform interface that hosts this system.) The system includes:

[0076] The interface asset modeling module is used to unify the imported or maintained interface information into interface nodes for persistent storage; the interface node includes at least the interface name, HTTP method, URL, request header, parameters, request body, response body, version, responsible person, dependency configuration, extraction configuration, post-configuration, runtime strategy, and success judgment expression.

[0077] The dependency analysis and standardization module is used to analyze the metadata of the interface nodes based on a preset dependency discovery strategy, generate candidate dependency edges and field mapping relationships between interface nodes, and normalize candidate dependency configurations with inconsistent historical formats into a unified dependency edge object. The unified dependency edge object includes at least a dependency interface identifier, dependency role, extraction expression, injection placeholder, runtime strategy, and post-trigger condition. The metadata includes at least a request body structure, a response body structure, and interface description information. The dependency discovery strategy can be implemented based on at least one of the following: the title, path, field structure, value matching result, and preset high-frequency identity field rules of the interface nodes.

[0078] The graph relationship persistence and caching module is used to persistently store the interface nodes and the standardized unified dependency edge objects as authoritative sources in a relational database; write the incremental state during the execution process into the cache database; and write long-link dependencies and variable-length path relationships into the graph structure storage medium.

[0079] The topology orchestration execution module is used to respond to the currently selected test case, orchestration suite, or test task, and extract the corresponding local dependency subgraph from the graph relationship persistence and caching module based on the differentiated execution strategy associated with the current test task, and contextualize the interface node definitions and dependency relationships therein; perform topological sorting on the adapted local dependency subgraph according to the dependency edges and field consumption relationships to generate an execution queue, and identify the pre-set type attributes or structural abnormal characteristics of the dependency relationships of each interface node during the sorting process, apply priority execution or protective adjustment to the sorting results, and drive the interface nodes in the execution queue to run in sequence.

[0080] The runtime context management module is used to maintain a unified set of variables when the topology orchestration execution module executes each node. The set of variables includes at least environment variables, system variables, user input, upstream response extraction results, identity tokens, polling status, and phased execution results. The runtime context management module is also used to query the corresponding value from the set of variables based on the injection placeholder of the current node to complete the request replacement, and to record the propagation path of the variable between the producer node and the consumer node.

[0081] The business judgment and strategy module is used to perform preset business success judgment on the return results of the main request and each subsequent request; and according to the runtime strategy, control the polling wait, failure blocking, abnormal alarm and skip execution behavior during the execution process.

[0082] The post-processing chain execution module is used to trigger and execute a preset post-processing chain according to the post-triggering conditions after the main request is completed. The post-processing chain is used to complete at least one of the following: verification, synchronization, recycling, or advancement of the business process. The post-processing chain includes an audit auxiliary workflow submodule. The audit auxiliary workflow submodule is used to link the return result of the main request with the external identity status, database status, or external approval system when it is detected that the return result of the main request meets the preset triggering conditions, and perform audit status advancement or result completion operations.

[0083] The interpretable report generation module is used to record the request trajectory, response data, time consumption, extracted variables, number of polling, success judgment details and failure attribution information of each execution node according to the preset role type, and output a structured test report that is displayed hierarchically according to the dependent roles.

[0084] Example 3: This example provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the interface automation testing method based on dependency graph topology orchestration as described in any one of Examples 1 above.

[0085] Specifically, the computer program can be built into or loaded into the interface automation testing system based on dependency graph topology orchestration as described in Embodiment 2, in order to drive the collaborative work of the various modules in the system.

[0086] Furthermore, the computer-readable storage medium in this embodiment can be any combination of one or more readable storage media, wherein the readable storage medium includes an electrical, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.

[0087] Unlike existing technologies, the interface automation testing method, system, and medium based on dependency graph topology orchestration proposed in this application can realize the object-oriented and structured storage and topology orchestration execution of dependency relationships in interface automation testing. It effectively resists interference such as downstream script failure, variable loss, and assertion distortion caused by upstream interface changes in large-scale interface regression testing, ensuring the stability and correctness of the test execution chain. It meets the long-term stable operation requirements of enterprise-level interface governance, continuous integration, and high-frequency regression testing scenarios, makes up for the deficiencies of existing technologies, and has high application value.

[0088] It should be understood that in the various embodiments of this document, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0089] It should also be understood that, in the embodiments herein, the term "and / or" is merely a description of the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following associated objects have an "or" relationship.

[0090] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this document.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0092] In the embodiments provided herein, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0093] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described herein, depending on actual needs.

[0094] Furthermore, the functional units in the various embodiments of this document can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0095] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this paper, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this paper. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for interface automated testing based on dependency graph topology orchestration, characterized in that, Includes the following steps: The interface definition data is transformed into a unified interface node and persistently stored. The request body of the interface node contains replaceable placeholders. Based on a preset dependency discovery strategy, the metadata of the interface nodes is analyzed to generate candidate dependency edges from the upstream interface to the downstream interface. The candidate dependency edges are standardized into dependency edge objects in a unified format, and all the dependency edge objects constitute a full set of dependency relationships. In response to the test task triggering operation, the target interface specified by the operation is determined as the main request node. The dependency edges required for the current execution chain are extracted from the full dependency set. Based on the differentiated execution strategy associated with the current test task, the extracted interface node definitions and dependencies are contextualized to form a local dependency subgraph within the current execution boundary. The interface nodes in the local dependency subgraph are topologically sorted to generate an ordered execution queue. A runtime context container is established, and each pre-dependent interface node is executed sequentially according to the ordered execution queue. After each pre-dependent interface node is executed, variables are extracted from the response and updated to the runtime context container. Then, the placeholders in subsequent requests are replaced and injected with the updated runtime context. After completing all the preceding dependent interface nodes, the main request node is executed. The business result is evaluated based on the success judgment expression corresponding to the main request node, and the subsequent steps are executed after the main request node is completed. Record the execution trajectory information of each interface node according to the preset role type, assemble it into a structured test report that is displayed hierarchically according to the dependent roles, and output it.

2. The method for interface automated testing based on a dependency graph topology arrangement according to claim 1, characterized in that: The differentiated execution strategy is used to locally adapt global interface definitions and global dependencies, so that the same interface node can be reused in different business processes with differentiated parameters and runtime strategies; wherein, the implementation of the differentiated execution strategy includes suite-level coverage configuration or task-level coverage configuration.

3. The interface automated testing method based on dependency graph topology orchestration according to claim 1, characterized in that: The dependency discovery strategy includes: flattening the request body, response body, and description information of each interface node into structured field paths, and generating the candidate dependency edges by combining at least one of value matching, inclusion matching, high-frequency identity field rules, CRUD semantic order, and version isolation rules; the high-frequency identity field rules include at least the identification rules for login status fields and authentication fields, and the metadata includes at least the request body structure, response body structure, and interface description information.

4. The interface automated testing method based on dependency graph topology orchestration according to claim 1, characterized in that: The dependency edge object includes at least a dependency interface identifier, a dependency role, an extraction expression, an injection placeholder, a runtime strategy, and a post-trigger condition. The dependency roles distinguish between pre-dependencies and post-dependencies; the preset role types are derived from the dependency roles in the dependency edge objects.

5. The interface automated testing method based on dependency graph topology orchestration according to claim 1, characterized in that: The success determination expression is pre-configured in the interface node. It is a business-level pass condition expression that is different from the HTTP status code and is used to determine whether the interface return result meets the business success criteria.

6. The interface automated testing method based on dependency graph topology orchestration according to claim 1, characterized in that: The runtime context container contains at least environment variables, system variables, user input, identity tokens, polling status, and phased execution results; when updating the runtime context, the extracted results are merged with the existing variables in the runtime context container.

7. The interface automated testing method based on dependency graph topology orchestration according to claim 1, characterized in that: When performing topological sorting on each interface node in the local dependency subgraph, the interface nodes are sorted according to the consumption relationship between the extracted fields and placeholders carried by the dependency edges; and the preset type attributes or cyclic characteristics of the dependency relationship of each interface node are identified, and the sorting results are preferentially executed or protectively adjusted; wherein, the preferential execution or protective adjustment specifically includes: when a login interface is detected, the login interface is preferentially sorted before other interfaces that depend on the login state; when a circular dependency is detected, degradation processing is performed and a recursive protection mechanism is triggered.

8. The interface automated testing method based on dependency graph topology orchestration according to claim 7, characterized in that: The post-processing steps include triggering and executing a preset post-processing chain based on the post-triggering conditions in the dependent edge object. The post-processing chain is used to complete at least one of the following: verification, synchronization, recycling, or advancement of the business process. The post-processing chain consists of at least one post-dependent interface node, which includes a cleanup node, a compensation node, a polling wait node, or an audit auxiliary workflow node. The polling wait node controls the polling interval, polling count, and termination conditions according to a runtime strategy. The audit auxiliary workflow is an extended business execution chain triggered based on the business object identifier, external identity state, and database state after the main request node completes. The runtime strategy includes at least a failure blocking strategy, a warning-only-not-blocking strategy, a skip execution strategy, and a waiting-for-polling strategy.

9. An automated interface testing system based on dependency graph topology orchestration, characterized in that, include: The interface asset modeling module is used to unify interface information into interface nodes for persistent storage. The dependency analysis and standardization module is used to generate candidate dependency edges based on the interface nodes and normalize them into a unified dependency edge object. The graph relationship persistence module is used to persistently store the interface nodes and the unified dependency edge objects; The topology orchestration execution module is used to respond to test tasks, extract the corresponding local dependency subgraphs and overlay local coverage configurations, perform topology sorting on the local dependency subgraphs and drive each interface node to run in sequence; The runtime context management module is used to maintain a unified set of variables when executing each node, and to query the corresponding value based on the placeholder to complete the request replacement; The business judgment and strategy module is used to perform business success judgment on the returned result and control the execution strategy. The interpretable report generation module is used to record execution trajectory information according to preset role types and output a layered test report.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the interface automation testing method based on dependency graph topology orchestration as described in any one of claims 1 to 8.

Images