Interface testing method and terminal

Abstract

The application provides an interface test method and a terminal. A routing rule input by a user is received, and a configuration model is constructed based on the routing rule. When an interface test task is started, a first interface to be tested in the interface test task is taken as a current interface to be tested. A service identifier of the current interface to be tested is extracted, routing decision is made based on the service identifier using the configuration model, and a target environment of the current interface to be tested is obtained. An isolated execution context of the target environment is created, interface test of the current interface to be tested is performed in the isolated execution context, and test results are recorded. Whether there is a next interface to be tested in the interface test task is judged. If yes, the next interface to be tested is taken as the current interface to be tested, routing decision and interface test are performed again, and the interface test of all the interfaces to be tested in the interface test task is completed until the interface test is completed. The structured management of the routing rule and the isolated execution of the interface test can be realized, and the reliability and execution efficiency of the interface test are improved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to interface testing methods and terminals. Background Technology

[0002] Currently, in the field of interface testing, common routing configuration schemes are mainly divided into two categories: one is a system-level or network-level proxy scheme, which forwards requests by modifying the operating system's Hosts file or using network proxy tools (such as Fiddler and Charles); the other is an environment variable-based configuration scheme, which dynamically specifies the target address in the test script through environment variables. However, existing schemes lack the ability to structurally model the topology of multi-domain name systems, resulting in the following technical problems: fragmented configuration management, unable to uniformly manage the mapping relationship between multiple services and test environments in a declarative manner; rigid routing decisions, unable to automatically route to the corresponding test environment based on the service to which the interface belongs, requiring manual specification one by one; insufficient environment isolation, test traffic interferes with each other when executed across environments, lacking session and protocol layer isolation mechanisms; and lack of lifecycle management, temporary routing rules and network resources generated during the test cannot be automatically cleaned up, resulting in environment remnants. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an interface testing method and terminal that can realize structured unified management of multiple services and testing environments and isolated execution of interface tests, thereby effectively improving the reliability and execution efficiency of interface tests.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: An interface testing method, comprising: Receive routing rules input by the user and construct a configuration model based on the routing rules; When an interface test task is started, the first interface to be tested in the interface test task is taken as the current interface to be tested; Extract the service identifier of the current interface to be tested, and use the configuration model to make a routing decision based on the service identifier to obtain the target environment of the current interface to be tested; Create an isolated execution context for the target environment, execute the interface test of the current interface to be tested in the isolated execution context, and record the test results; Determine if there is a next interface to be tested in the interface testing task. If so, take the next interface to be tested as the current interface to be tested, and re-perform routing decisions and interface testing until all interfaces to be tested in the interface testing task have completed interface testing.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An interface testing terminal includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement the various steps of the interface testing method described above.

[0006] The beneficial effects of this invention are as follows: By receiving routing rules input by the user and constructing a configuration model, the centralized and structured configuration of routing rules is achieved, laying the foundation for unified management of the mapping relationship between multiple services and the test environment; when an interface test task starts, the first interface to be tested is obtained as the current interface, ensuring the orderly progress of the test process; the service identifier of the current interface to be tested is extracted and routing decisions are made based on the configuration model to determine the target environment, which can dynamically match the target environment according to the service, eliminating the need for manual specification and improving test efficiency; an isolated execution context for the target environment is created, and interface tests are executed and results are recorded in the isolated environment, avoiding mutual interference and environmental influence between tests and ensuring the accuracy of test results; it determines whether there is a next interface to be tested and repeatedly executes routing decisions and interface tests until all are completed, realizing fully automated testing and improving the reliability and execution efficiency of interface testing. Attached Figure Description

[0007] Figure 1 This is a flowchart of an interface testing method according to an embodiment of the present invention; Figure 2 This is another flowchart of an interface testing method according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating the construction of the configuration model in an embodiment of the present invention; Figure 4 This is a schematic diagram of an interface testing terminal according to an embodiment of the present invention. Detailed Implementation

[0008] Definitions:

[0009] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0010] In existing technologies, to route interface requests from different services to a specified test environment, existing solutions mainly fall into two categories: one is a system-level or network-level proxy solution that forwards requests by modifying the operating system's Hosts file or using network proxy tools; the other is a configuration solution that dynamically specifies the target address in the test script through environment variables. However, existing solutions lack the ability to structurally model the mapping relationships between multiple services and multiple environments, leading to problems such as fragmented configuration management, reliance on manual intervention for routing decisions, and mutual interference between cross-environment tests, which affect the reliability, maintainability, and execution efficiency of automated interface testing.

[0011] To at least address the aforementioned issues, a configuration model is constructed by receiving routing rules input by the user. When an interface testing task starts, each interface to be tested is processed sequentially, including: extracting the service identifier of the current interface to be tested; matching the corresponding target environment in the configuration model based on the service identifier; creating an isolated execution context for the matched target environment; executing the interface test in the isolated execution context and recording the results, until all interfaces to be tested have completed the interface test. In this way, structured and unified management of multiple services and test environments and automatic routing and isolated execution of interface tests can be achieved, effectively improving the reliability and execution efficiency of interface testing.

[0012] The following describes an interface testing method of this invention in detail. Please refer to [link / reference]. Figure 1 The method 100 includes steps 101 to 105: Step 101: Receive the routing rules input by the user and construct a configuration model based on the routing rules.

[0013] Specifically, users input routing rules in the following JSON format through the configuration interface: {"aq": "192.168.xx.xx:443","reg": "regapi.xxx.99.com_ip_192.168.xx.xx","default": "192.168.xx.xxx"}. Here, the keys "aq" and "reg" are predefined service identifiers used to uniquely identify the service module to which the interface belongs. The "default" key defines the default routing policy; when the service identifier of the interface to be tested does not match a corresponding entry in the rules, it will be routed to the target environment specified by this key. After receiving the user-input routing rules, the system performs format validation and network connectivity checks, converting them into an internal data structure, namely the configuration model. This model mainly includes: a service identifier-target environment mapping table that supports fast lookup, used to record the mapping relationship from service identifiers to target environment addresses; and a default routing policy flag, used to indicate whether the default routing policy is enabled. In this way, environment mapping management is achieved at the service level, laying the foundation for subsequent service-based differentiated routing.

[0014] Step 102: When the interface test task is started, the first interface to be tested in the interface test task is taken as the current interface to be tested.

[0015] Specifically, please refer to Figure 2 An interface testing task refers to a complete interface testing task containing multiple interfaces to be tested. When an interface testing task starts, the task resource manager is initialized, identified by the task ID. This resource manager is responsible for maintaining all configuration models and execution context instances for this task, providing a unified context retrieval interface to the outside world. Retrieving the first interface to be tested from the interface testing task as the current interface to be tested ensures the orderly start of the interface testing process and consistent access to global resources.

[0016] Step 103: Extract the service identifier of the current interface to be tested, and use the configuration model to make a routing decision based on the service identifier to obtain the target environment of the current interface to be tested.

[0017] Specifically, please refer to Figure 2 By extracting the service identifier of the interface to be tested, a two-level routing decision is performed based on the service identifier using a configuration model, including precise route matching and default route decision, to obtain the target environment of the interface to be tested, thereby improving the automation and flexibility of routing decision.

[0018] Step 104: Create an isolated execution context for the target environment, execute the interface test of the current interface to be tested in the isolated execution context, and record the test results.

[0019] Specifically, please refer to Figure 2 By creating and maintaining an isolated execution context for each independent target environment, including network connection isolation, session state isolation, and protocol configuration isolation, and executing interface tests of the current interface to be tested in the isolated execution context, the test traffic is ensured to be completely independent, providing accurate environment attribution information for subsequent result analysis and problem localization.

[0020] Step 105: Determine whether there is a next interface to be tested in the interface testing task. If so, take the next interface to be tested as the current interface to be tested, and re-perform routing decisions and interface testing until all interfaces to be tested in the interface testing task have completed interface testing.

[0021] Specifically, please refer to Figure 2After the test results for the current interface to be tested are recorded, the system checks if there is another interface to be tested that has not yet been executed in the interface test task queue. If so, it automatically sets the next interface to be tested as the new current interface to be tested and returns to step 103 to re-execute the processes of service identifier extraction, routing decision, isolation execution context creation, and interface testing. This loop continues until all interfaces to be tested in the task queue have been processed. In this way, the automated serial execution of interface test tasks is achieved, and batch testing of all interfaces can be completed without manual intervention.

[0022] Please refer to Figure 3 In one embodiment of the present invention, step 101 includes step 1011: Step 1011: Perform format verification and network connectivity verification on the routing rules. When both the format verification and the network connectivity verification pass, convert the routing rules into a service identifier-target environment mapping table and a default routing policy flag to obtain a configuration model.

[0023] Specifically, the routing rules input by the user are format-validated to ensure the JSON structure is valid and each target address conforms to the predefined format rules, and network connectivity is checked. After both format and network connectivity checks pass, the rules are parsed into an internal data structure, constructing a configuration model containing a service identifier-target environment mapping table and default routing policy flags. During parsing, differentiated processing is performed based on the target address's format type: for the "IP:port" format (e.g., 192.168.xx.xx:443), it is directly used as the network address; for the "domain_IP binding format" (using a custom syntax of [domain]_ip_[IP address]:[port], such as regapi.xxx.99.com_ip_192.168.xx.xx), requests originally sent to the [domain] are redirected to the specified [IP address]:[port], while the original domain name is retained in the HTTP request header to support test scenarios requiring domain name or SSL certificate verification; for pure domain name formats, the system completes the addressing through regular DNS resolution in subsequent requests. In this way, the system transforms the structured routing rules input by the user into a configuration model that can be directly used for subsequent routing decisions.

[0024] In one embodiment of the present invention, step 103 includes steps 1031 to 1034: Step 1031: If the current interface to be tested has been bound to a preset service identifier during the interface definition stage, then the preset service identifier shall be directly used as the service identifier of the current interface to be tested.

[0025] Specifically, during the interface definition phase, the testing platform provides a service identifier binding function. When an interface is created or imported, a service identifier is pre-assigned to it (e.g., by selecting "aq" or "reg" from a dropdown menu). This identifier is stored in the platform as metadata along with the interface definition. When an interface testing task is executed, the pre-assigned service identifier is directly read from the metadata of the interface under test. In this way, for interfaces with clearly defined service affiliations, there is no need to repeatedly perform rule matching during test execution, effectively improving routing decision efficiency while maintaining the intuitiveness and maintainability of the configuration.

[0026] Step 1032: Otherwise, obtain the interface features of the current interface to be tested, use the interface features to perform matching in the preset mapping rule base, and use the matched service identifier as the service identifier of the current interface to be tested.

[0027] Specifically, if the interface to be tested is not bound to a service identifier during the definition phase, its characteristic information is extracted. This mainly includes the interface's URL path pattern (e.g., all interfaces starting with / api / auth / ), the project module to which it belongs, or user-added tags or metadata, and the service name field in the interface definition. These characteristics are then matched against a pre-defined "interface characteristic-service identifier" mapping rule base. For example, the rule base could define "all interfaces starting with / api / auth / belong to the aq service." If a match is successful, the corresponding service identifier is used as the service identifier for that interface. This mechanism allows for dynamic expansion of service identifier acquisition; even if the interface is not bound to an identifier during the definition phase, its affiliation can still be automatically inferred from the rule base, enhancing the adaptability of the interface to be tested.

[0028] Step 1033: Match the service identifier in the service identifier-target environment mapping table. If the match is successful, the matched target environment is taken as the target environment of the current interface to be tested.

[0029] Specifically, after obtaining the service identifier of the interface to be tested, the system uses this service identifier as a query condition to perform an exact match in the service identifier-target environment mapping table. If an entry corresponding to the current service identifier exists in the mapping table (e.g., service identifier "aq" corresponds to address "192.168.xx.xx:443"), then the target address in that entry is used as the target environment for the current interface. This matching mechanism achieves a precise correspondence between services and test environments, ensuring that all interfaces of the same service module are automatically routed to a unified target environment, avoiding potential omissions or inconsistencies that may result from manual item-by-item specification.

[0030] Step 1034: If the matching fails, check the default routing policy flag in the configuration model. When the default routing policy flag indicates that the default routing policy has been enabled, use the preset default environment as the target environment of the current interface to be tested. When the default routing policy flag indicates that the default routing policy is not enabled, the test skip flag of the currently tested interface will be set to terminate the interface test process of the currently tested interface.

[0031] Specifically, if no entry corresponding to the current service identifier is found in the service identifier-target environment mapping table, the default routing policy flag in the configuration model is read. This flag corresponds to whether the "default" key is configured in the JSON rule entered by the user. If the user has configured the "default" key (e.g., "default": "192.168.xx.xxx"), it means that the default routing policy is enabled, and the default address is used as the target environment for the current interface, continuing to execute subsequent tests. If the user has not configured the "default" key, it means that the default routing policy is not enabled, the system marks the interface as "skipped", and the test process for this interface is no longer executed, and the next interface to be tested in the task is processed. In this way, a flexible routing fault tolerance strategy is implemented, allowing users to set a fallback environment to ensure the testing continuity of core interfaces, and also supporting automatic filtering of interfaces without configured routes in strict mode, avoiding interference from invalid requests or incorrect routes to test results, and improving the controllability and robustness of test execution.

[0032] In addition, routing results are cached to avoid repeated queries for the same service, and the routing paths of each interface are fully recorded for subsequent auditing and analysis.

[0033] In one embodiment of the present invention, step 104 includes steps 1041 and 1042: Step 1041: Establish a dedicated network connection pool and session state management container for the target environment, and set protocol parameters according to the address format of the target environment.

[0034] Specifically, a dedicated network connection pool (HTTP(S) client connection pool) is created for the target environment. This connection pool maintains persistent connections with the backend services of the target environment. Requests from different tasks pointing to the same environment can reuse connections in this pool (connection reuse), but requests pointing to different environments must use different connection pools. This achieves traffic segmentation at the TCP / IP layer, avoiding the overhead of re-establishing connections for each request and preventing state confusion caused by connection reuse between different environments. Furthermore, an independent session state management container is created for the target environment to store session information such as cookies related to that environment. Multiple API calls within the same environment can share this container to maintain session continuity, while session data between different environments is completely isolated and invisible to each other. In addition, protocol parameters are configured according to the address format of the target environment. For example, when the address format is "domain_ip_IP:port", TLS parameters are managed independently when initiating HTTPS requests, ensuring that the SNI (Server Name Indication) field during the TLS handshake is set to the original domain name rather than the bound IP address, thus correctly passing the virtual host and certificate verification on the server side. Through the above mechanism, the system builds a completely isolated execution foundation for each target environment, ensuring the independence and security of test traffic.

[0035] Step 1042: In the isolated execution context, initiate an interface call to the backend service instance in the target environment of the interface to be tested, receive the original protocol response returned by the backend service instance, associate the original protocol response with the service identifier of the interface to be tested, and record it as the test result.

[0036] Specifically, in the isolated execution context, the test platform or test execution engine acts as the requester, assembling the corresponding interface call request based on the protocol type of the interface under test (HTTP / HTTPS or gRPC, etc.). During request assembly, session information (such as cookies) for the target environment is extracted from the session state management container and injected into the request header or request metadata to form a complete interface call request. After assembly, a network connection pool is initialized according to the configured protocol parameters, and the request is sent to the backend service instance in the target environment through a persistent connection in the network connection pool. The backend service instance in the target environment receives and processes the request, returning the original protocol response. For example, for the HTTP protocol, the response includes a status code, header, and response body; for the gRPC protocol, the response includes a response message and status metadata. After receiving the original protocol response, the response content is not tampered with, maintaining its originality and integrity. Furthermore, the test result is associated with the service identifier of the interface under test, forming a test result entry with a clearly defined environment affiliation, facilitating subsequent result tracing and analysis by service dimension.

[0037] In one embodiment of the present invention, after step 105, the method includes: releasing the resource data of the interface test task, integrating the test results of all interfaces to be tested, and generating a test report.

[0038] Specifically, when all interfaces to be tested in an interface testing task have been executed, or when the task execution is interrupted, a resource cleanup process is initiated. The resource manager takes over the resource reclamation work, releasing the dedicated network connection pools established for each target environment in sequence, closing persistent connections with backend service instances to avoid port occupation or resource leaks caused by connection remnants; simultaneously, clearing the session state management containers corresponding to each isolated execution context, clearing cached cookie session data to ensure that sensitive information is not stored in memory; and reclaiming memory resources. After resource cleanup is completed, a resource cleanup report is generated to ensure a clean testing environment and not affect the execution of subsequent tasks. Furthermore, the test results of all interfaces to be tested are summarized to generate a structured test report. In this way, it is ensured that each test task is executed in a clean environment, avoiding interference from historical task remnants on subsequent tests, and effectively improving the stability and repeatability of the testing environment.

[0039] Furthermore, the following specific application scenarios are also provided in one embodiment of the present invention: A complete business process test involves user registration, login authentication, and security verification services, which are typically deployed under different domains or network addresses. Traditionally, testers need to manually specify the target environment for each interface or perform global forwarding by modifying the Hosts file, a cumbersome and error-prone process.

[0040] With this invention, testers only need to declare routing rules in the following JSON format in the task configuration: { "aq": "192.168.xxx.xx:443", "reg": "xxx.xxx.99.com_ip_192.168.xx.xx", "default": "192.168.xx.xx" } The system can automatically send registration interface requests to 192.168.xxx.xx:443 (while preserving the original domain header), authentication interface requests to its DNS resolution address, security interface requests to the specified port, and other unlisted interface requests to the default environment 192.168.xx.xx. This enables precise and isolated testing of multiple services and environments in a single test task.

[0041] In summary, this invention provides an interface testing method. It constructs a structured configuration model by receiving user-input routing rules, unifying the management of the mapping relationship between multiple services and the test environment. During test task execution, it automatically extracts the service identifier of the interface to be tested and dynamically routes it to the corresponding target environment according to the configuration model. It creates an independent isolated execution context for each target environment to ensure that test traffic does not interfere with each other. After completing the interface call in the isolated context, it associates and records the original protocol response with the service identifier, achieving accurate result traceability. It sequentially traverses all interfaces to be tested and automatically releases network connections, clears session caches, reclaims memory resources, and generates a test report after the task ends. This approach enables structured and unified management of multiple services and test environments, as well as automatic routing and isolated execution of interface tests, effectively improving the reliability and execution efficiency of interface testing.

[0042] Please refer to Figure 4 The present invention also provides an interface testing terminal 200, including a memory 201, a processor 202, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of an interface testing method as described above.

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

Claims

1. An interface testing method, characterized in that, include: Receive routing rules input by the user and construct a configuration model based on the routing rules; When an interface test task is started, the first interface to be tested in the interface test task is taken as the current interface to be tested; Extract the service identifier of the current interface to be tested, and use the configuration model to make a routing decision based on the service identifier to obtain the target environment of the current interface to be tested; Create an isolated execution context for the target environment, execute the interface test of the current interface to be tested in the isolated execution context, and record the test results; Determine if there is a next interface to be tested in the interface testing task. If so, take the next interface to be tested as the current interface to be tested, and re-perform routing decisions and interface testing until all interfaces to be tested in the interface testing task have completed interface testing.

2. The interface testing method according to claim 1, characterized in that, Based on the routing rules, a configuration model is constructed, including: The routing rules are validated for format and network connectivity. When both the format verification and the network connectivity verification pass, the routing rules are converted into a service identifier-target environment mapping table and a default routing policy flag to obtain the configuration model.

3. The interface testing method according to claim 1, characterized in that, Extract the service identifier of the interface currently under test, including: If the interface to be tested has been bound to a preset service identifier during the interface definition phase, then the preset service identifier will be directly used as the service identifier of the interface to be tested.

4. The interface testing method according to claim 1, characterized in that, Extract the service identifier of the interface currently under test, including: Obtain the interface features of the current interface to be tested, use the interface features to perform matching in a preset mapping rule base, and use the matched service identifier as the service identifier of the current interface to be tested.

5. The interface testing method according to claim 2, characterized in that, Based on the service identifier, the configuration model is used to make routing decisions to obtain the target environment of the current interface to be tested, including: The service identifier is matched against the service identifier-target environment mapping table. If the match is successful, the matched target environment is used as the target environment of the current interface to be tested. Otherwise, check the default routing policy flag in the configuration model. When the default routing policy flag indicates that the default routing policy is enabled, use the preset default environment as the target environment for the current interface to be tested.

6. The interface testing method according to claim 5, characterized in that, The check of the default routing policy flag in the configuration model also includes: When the default routing policy flag indicates that the default routing policy is not enabled, the test skip flag of the currently tested interface will be set to terminate the interface test process of the currently tested interface.

7. The interface testing method according to claim 1, characterized in that, Creating an isolated execution context for the target environment includes: Establish a dedicated network connection pool and session state management container for the target environment, and set protocol parameters according to the address format of the target environment.

8. The interface testing method according to claim 1, characterized in that, Execute the interface test of the currently tested interface in the isolated execution context, and record the test results, including: In the isolated execution context, an interface call is initiated to the backend service instance in the target environment of the interface to be tested, the original protocol response returned by the backend service instance is received, and the original protocol response is associated with the service identifier of the interface to be tested and recorded as the test result.

9. The interface testing method according to claim 1, characterized in that, Until all interface tests for the interfaces to be tested in the aforementioned interface testing task are completed, the following applies: Release the resource data of the interface test task, integrate the test results of all interfaces to be tested, and generate a test report.

10. An interface testing terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the interface testing method according to any one of claims 1 to 9.

Images