Interface test method, device, equipment, storage medium and computer program product

Abstract

The application relates to the technical field of software development, and discloses an interface testing method, device, equipment, storage medium and computer program product. The method comprises the following steps: in response to a testing request, matching a simulation interface corresponding to the testing request in a cache, wherein the cache stores a simulation interface configured in advance by a user; performing interface testing on the simulation interface; obtaining response data; and generating an interface testing result of the simulation interface according to the response data. Since the simulation interface is stored in the cache and the interface testing is directly performed on the simulation interface corresponding to the testing request matched from the cache, the response time of the interface testing can be reduced, and the high-concurrency and low-delay scene can be supported.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to an interface testing method, apparatus, device, storage medium, and computer program product. Background Technology

[0002] In software development, interface testing is a crucial step in ensuring normal communication between system modules and overall system stability. However, in actual interface testing, situations often arise where external systems or services are relied upon. These dependencies may not be fully developed, unstable, or difficult to control.

[0003] To address these issues, relevant API testing methods simulate the behavior of real objects, helping developers perform API tests without relying on external systems, thereby improving testing efficiency and coverage. However, these methods suffer from drawbacks such as long response times and inability to support high-concurrency and low-latency scenarios. Summary of the Invention

[0004] The main purpose of this application is to provide an interface testing method, apparatus, device, storage medium, and computer program product, aiming to solve the technical problems of long response time and inability to support high concurrency and low latency scenarios in related interface testing methods.

[0005] To achieve the above objectives, this application provides an interface testing method, which includes:

[0006] In response to a test request, the simulated interface corresponding to the test request is matched in the cache, wherein the cache stores simulated interfaces pre-configured by the user;

[0007] Perform interface testing on the simulated interface to obtain response data;

[0008] The interface test results of the simulated interface are generated based on the response data.

[0009] Optionally, the step of performing interface testing on the simulated interface to obtain response data includes:

[0010] Obtain the test mode, wherein the test mode includes either the basic mode or the proxy mode;

[0011] The simulated interface is tested according to the test mode to obtain response data.

[0012] Optionally, the step of performing interface testing on the simulated interface according to the test mode to obtain response data includes:

[0013] In the basic test mode, the configuration information of the simulated interface is obtained from the cache;

[0014] The simulated interface is tested according to the configuration information to obtain response data.

[0015] Optionally, the configuration information includes: function expressions and / or data simulation scripts; the step of performing interface testing on the simulation interface according to the configuration information to obtain response data includes:

[0016] Dynamic data is generated based on the function expression and / or the data simulation script;

[0017] The simulated interface is tested based on the dynamic data to obtain response data.

[0018] Optionally, the step of performing interface testing on the simulated interface according to the test mode to obtain response data includes:

[0019] When the test mode is proxy mode, check whether the cache contains response data corresponding to the simulated interface;

[0020] If the cache contains response data corresponding to the simulated interface, then check whether to enable the simulated delay mode;

[0021] If the simulated delay mode is not enabled, the response data corresponding to the simulated interface is obtained from the cache;

[0022] If the simulated delay mode is enabled, the response data corresponding to the simulated interface will be retrieved from the cache after a preset time interval, wherein the preset time is the time required to request response data from the real interface corresponding to the simulated interface.

[0023] Optionally, after detecting whether the response data corresponding to the simulated interface exists in the cache when the test mode is proxy mode, the method further includes:

[0024] If the response data corresponding to the simulated interface is not found in the cache, the test request is forwarded to the real interface corresponding to the simulated interface.

[0025] Receive the response body and response time from the actual interface in response to the test request;

[0026] Response data is generated based on the response body and response time, and the response data is stored in the cache.

[0027] Optionally, when the test mode is proxy mode, detecting whether the cache contains response data corresponding to the simulated interface includes:

[0028] When the test mode is proxy mode, a matching identifier is generated based on the test request and the generation rules configured by the user;

[0029] The cache is checked to see if the response data corresponding to the simulated interface exists based on the matching identifier.

[0030] Optionally, the step of performing interface testing on the simulated interface according to the test mode to obtain response data includes:

[0031] When the test mode is proxy mode and the transparent mode is enabled, the test request is forwarded to the real interface corresponding to the simulated interface;

[0032] Receive the response data fed back by the real interface in response to the test request.

[0033] Optionally, the step of performing interface testing based on user configuration and the simulated interface to obtain response data includes:

[0034] The simulated interface is copied to obtain a copied interface;

[0035] Perform interface testing on the replication interface to obtain response data.

[0036] Optionally, before responding to the interface test request and matching the simulated interface information corresponding to the interface test request in the cache, the method further includes:

[0037] Receive simulated interfaces added by users on the management page;

[0038] The simulated interface is stored in the cache as an object.

[0039] Optionally, the step of matching the simulated interface corresponding to the test request in the cache in response to the test request includes:

[0040] In response to a test request, obtain the interface path from the test request;

[0041] Match the simulated interface corresponding to the test request in the cache according to the interface path.

[0042] Furthermore, to achieve the above objectives, this application also proposes an interface testing apparatus, which includes:

[0043] An interface matching module is used to respond to a test request by matching the simulated interface corresponding to the test request in the cache, wherein the cache stores simulated interfaces pre-configured by the user.

[0044] The interface testing module is used to perform interface testing on the simulated interface and obtain response data.

[0045] The result generation module is used to generate interface test results for the simulated interface based on the response data.

[0046] Optionally, the interface testing module is further configured to obtain a test mode, wherein the test mode includes a basic mode or a proxy mode; and to perform interface testing on the simulated interface according to the test mode to obtain response data.

[0047] Optionally, the interface testing module is further configured to, when the test mode is the basic mode, obtain the configuration information of the simulated interface from the cache; perform interface testing on the simulated interface according to the configuration information, and obtain response data.

[0048] Optionally, the configuration information includes: function expressions and / or data simulation scripts; the interface testing module is further configured to generate dynamic data based on the function expressions and / or the data simulation scripts; and to perform interface testing on the simulated interface based on the dynamic data to obtain response data.

[0049] Optionally, the interface testing module is further configured to, when the test mode is proxy mode, detect whether there is response data corresponding to the simulated interface in the cache; if there is response data corresponding to the simulated interface in the cache, detect whether to enable the simulated delay mode; if the simulated delay mode is not enabled, retrieve the response data corresponding to the simulated interface from the cache; if the simulated delay mode is enabled, retrieve the response data corresponding to the simulated interface from the cache after a preset time interval, wherein the preset time is the time required to request response data from the real interface corresponding to the simulated interface.

[0050] Optionally, the interface testing module is further configured to: forward the test request to the real interface corresponding to the simulated interface if the response data corresponding to the simulated interface does not exist in the cache; receive the response body and response time fed back by the real interface according to the test request; generate response data according to the response body and response time; and store the response data in the cache.

[0051] In addition, to achieve the above objectives, this application also proposes an interface testing device, which includes a memory, a processor, and an interface testing program stored in the memory and executable on the processor. The interface testing program is configured to implement the interface testing method described above.

[0052] In addition, to achieve the above objectives, this application also proposes a storage medium storing an interface testing program, which, when executed by a processor, implements the interface testing method described above.

[0053] In addition, to achieve the above objectives, this application also provides a computer program product, which includes an interface testing program that, when executed by a processor, implements the interface testing method described above.

[0054] One or more technical solutions proposed in this application have at least the following technical effects:

[0055] This application discloses a method for responding to test requests by matching the simulated interface corresponding to the test request in the cache. The cache stores simulated interfaces pre-configured by the user. Interface testing is performed on the simulated interfaces to obtain response data, and interface test results of the simulated interfaces are generated based on the response data. Since this application stores simulated interfaces in the cache and directly matches the simulated interface corresponding to the test request from the cache for interface testing, the response time of interface testing can be reduced, thereby supporting high concurrency and low latency scenarios. Attached Figure Description

[0056] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0057] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This is a flowchart illustrating the first embodiment of the interface testing method of this application;

[0059] Figure 2 This is a detailed flowchart of an embodiment of the interface testing method of this application;

[0060] Figure 3 This is a flowchart illustrating the second embodiment of the interface testing method of this application;

[0061] Figure 4 This is a flowchart illustrating the third embodiment of the interface testing method of this application;

[0062] Figure 5 This is a flowchart illustrating the fourth embodiment of the interface testing method of this application;

[0063] Figure 6 This is a flowchart illustrating the proxy pattern of an embodiment of the interface testing method of this application.

[0064] Figure 7 This is a schematic diagram of the module structure of the interface testing device according to an embodiment of this application;

[0065] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the interface testing method in this application embodiment.

[0066] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0067] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0068] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0069] In software development, interface testing is a crucial step in ensuring proper communication between system modules and overall system stability. However, in practical interface testing, situations often arise where external systems or services are relied upon. These dependencies may be incomplete, unstable, or difficult to control. To address these issues, mock technology has emerged. By simulating the behavior of real objects, mock technology helps developers perform interface testing without relying on external systems, thereby improving testing efficiency and coverage. However, related mock technologies suffer from drawbacks such as long response times and inability to support high-concurrency and low-latency scenarios.

[0070] Therefore, to overcome the above-mentioned shortcomings, this application provides a solution, which includes: responding to a test request, matching the simulated interface corresponding to the test request in the cache, wherein the cache stores simulated interfaces pre-configured by the user, performing interface testing on the simulated interface, obtaining response data, and generating interface test results for the simulated interface based on the response data; since this application stores the simulated interface in the cache and directly matches the simulated interface corresponding to the test request from the cache for interface testing, the response time of interface testing can be reduced, thereby supporting high concurrency and low latency scenarios.

[0071] It should be noted that the execution subject of this embodiment may be an interface testing device with data processing, network communication and program running functions, such as a computer, or other electronic devices that can achieve the same or similar functions. This embodiment does not limit this.

[0072] Based on this, this application provides an interface testing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the interface testing method of this application.

[0073] In the first embodiment, the interface testing method includes:

[0074] Step S10: In response to the test request, match the simulated interface corresponding to the test request in the cache, wherein the cache stores simulated interfaces pre-configured by the user.

[0075] It should be understood that the application scenario of this application embodiment can be to perform interface testing by simulating the behavior of a real interface through a mock service. In a specific implementation, for example, a website system's login interface needs to be tested, but the real system's login interface has not yet been developed. In this case, a mock service can be used to simulate the behavior of the login interface.

[0076] It should be noted that test requests can be requests sent during the software development process to verify the functionality, performance, and security of the software system. Test requests can be generated by testers or automated testing tools to simulate real user operations or data interactions; this embodiment does not impose any limitations on this. A cache can be a high-speed data storage device or technology used to store frequently accessed data to reduce data access time and improve system performance. In a mock service, a cache (such as a cache) is used to store user-pre-configured mock interfaces so that the corresponding interface can be quickly matched when a test request is received. A mock interface can be a virtual interface provided by the mock service to simulate interface behavior in a real system. The mock interface can be configured by the user according to actual needs to replace the real interface in simulation testing during the testing process.

[0077] In its implementation, when the mock service receives a test request, it searches the cache for a mock interface that matches the interface path. This process is achieved by comparing the mock interface path with the mock interface paths stored in the cache. If a matching mock interface is found, processing continues; otherwise, a 404 error is returned.

[0078] Furthermore, to facilitate user management of interface testing, before step S10, the method further includes: receiving simulated interfaces added by the user on the management page; and storing the simulated interfaces in the cache as objects.

[0079] It should be noted that the management page can be a user interface, allowing users to configure, manage, or monitor operations through a graphical or web-based interface. In a specific implementation, the management page can be provided by a mock service, allowing users to add, edit, or delete mock interfaces.

[0080] It should be understood that the mock service provides a management page through which users can add interfaces to be simulated. The interface information entered by the user (such as the interface path, request method, response data, etc.) is received and processed by the mock service. The mock service stores the simulated interface information added by the user in the form of objects in a cache. This way, when a test request is received, the mock service can quickly find a matching simulated interface in the cache.

[0081] Step S20: Perform interface testing on the simulated interface to obtain response data.

[0082] It's important to note that API testing can be a software testing method. It verifies the functionality, performance, and security of an API by sending requests to its interfaces and checking whether the responses meet expectations. The response data is the data returned by the API after receiving a request. In mock services, the response data is generated by a user-configured mock API upon receiving a test request, simulating the response behavior of a real API.

[0083] In the actual implementation, once a matching mock interface is found, the mock service will simulate the behavior of the real interface and generate response data. This process can be regarded as an interface test of the mock interface, used to verify the interface's functionality, performance, security, etc., and this embodiment does not impose any limitations on it.

[0084] Furthermore, in order to isolate requests and prevent contamination of data in the database, step S20 includes: replicating the simulated interface to obtain a replicated interface; and performing interface testing on the replicated interface to obtain response data.

[0085] It should be understood that, to ensure the original mock interface object is not modified, the mock service performs a deep copy of the matched mock interface object, obtaining a replica (i.e., a copied interface). This replica will be used for subsequent interface testing to ensure that the testing process does not affect the processing of other requests. Once the copied mock interface is obtained, the mock service will simulate the behavior of the real interface, sending requests to that interface (these requests can be generated internally by the mock service or sent by external testing tools) and receiving response data. This process can be viewed as an interface test of the copied interface.

[0086] Step S30: Generate the interface test results of the simulated interface based on the response data.

[0087] It should be understood that interface test results can be the results obtained after testing the interface, including whether the test passed, whether the response data meets expectations, response time, and other information. In specific implementations, generating interface test results based on response data can be achieved by the mock service generating interface test results based on preset evaluation criteria (such as response time, whether the response data meets expectations) after receiving response data from a simulated interface. The interface test results can be used as a reference for subsequent software development and testing.

[0088] For ease of understanding, please refer to Figure 2 This explanation is provided, but does not limit the scope of this application. Figure 2 This is a detailed flowchart of an embodiment of the interface testing method of this application. Figure 2 The interface testing method includes: After starting the mock service, users can add interfaces to be simulated on the management page (supporting HTTP / HTTPS protocols). The user-added interfaces are stored in the cache as objects (considering that mock needs to support high concurrency and low latency scenarios, mock itself does not support data persistence; data persistence is stored in the cache). When a request arrives, it first matches the request path (interface path) against the cache (supporting RESTful style matching). If no match is found, a 404 error is returned. If a match is found, the object is copied (without modifying the original object, otherwise it would affect other requests), and then passed through the tuner layer. The tuner is mainly responsible for the logical processing and assembly of response data based on user configuration. This includes generating the body, generating the header, processing function expressions, processing embedded shell expressions, mock cache proxy modes, and processing user data variables. In addition, it supports extending the tuner to simulate logic more closely suited to business scenarios. Mock offers multi-dimensional monitoring, allowing you to monitor mockQPS, mockP99, mockP95, mockP90, downstream QPS, downstreamP99, downstreamP95, downstreamP90, and cache hit rate. RESTful style matching refers to a design style and development approach for web applications. Based on the HTTP protocol, it can transmit data using XML or JSON formats, is stateless (each request contains a complete description of the information needed to process it), and effectively supports concepts such as caching, layered systems, and unified interfaces. QPS (Queries Per Second) measures the system's request processing capacity. P90 / P95 / P99 are percentile indicators, representing that 90%, 95%, and 99% of request processing times are less than or equal to a certain value, used to measure system response latency. Cache hit rate is the ratio of requests that successfully find data in the cache to the total number of requests, a crucial indicator of caching efficiency.

[0089] It should be understood that in this embodiment, the mock service is designed with an agent structure, allowing the platform to manage all agents uniformly. The mock supports multi-machine deployment and single-machine multi-deployment. Automated mock deployment and mock interface configuration can be performed on the platform. Mock interface configurations added on the platform are saved in the database. When the mock starts, it synchronizes data with the platform and sends heartbeats. Each mock can be used independently and provides an interactive page; however, interface additions made within the mock are stored in the cache and are not synchronized to the database.

[0090] This embodiment solves the problem of data states that are difficult or impossible to construct by using mock services, improves test scenario coverage, reduces test complexity, solves the problem that the triggering conditions of the service under test depend on downstream data, improves automation coverage, solves the problem of dependence on other services or interfaces during the development phase, and isolates requests to prevent pollution of data in the database.

[0091] For ease of understanding, the following example is provided, but it does not limit this application. As an example, a website system's login interface needs testing, but the actual system's login interface has not yet been developed. In this case, a mock service can be used to simulate the behavior of the login interface. Interface testing methods include:

[0092] 1. Configure the mock interface: First, the tester configures a mock login interface on the management page of the mock service, including the interface path (e.g., / api / login), request method (e.g., POST), request parameters (e.g., username and password), and response data (e.g., login success message and user information).

[0093] 2. Send a test request: Then, the tester uses testing tools or writes a test script to send a test request to the mock service to simulate user login behavior.

[0094] 3. Matching mock interfaces: After receiving a test request, the mock service searches the cache for a mock interface that matches the request path ( / api / login).

[0095] 4. Generate Response Data: The mock service generates response data based on the configured mock interface and returns it to the test request. In this example, the response data may include a login success message and simulated user information.

[0096] 5. Generate Interface Test Results: Finally, the mock service generates interface test results based on the response data, including information such as whether the test passed (i.e., whether the response data meets expectations) and response time. Testers can use the interface test results to evaluate the performance and reliability of the mock interface and provide a reference for subsequent software development and testing.

[0097] This embodiment stores the simulated interface in the cache and directly matches the simulated interface corresponding to the test request from the cache to perform interface testing, thereby reducing the response time of interface testing and supporting high concurrency and low latency scenarios.

[0098] Reference Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the interface testing method of this application, based on the above. Figure 1The first embodiment shown is followed by a second embodiment of the interface testing method of this application.

[0099] In the second embodiment, step S10 includes:

[0100] Step S101: In response to the test request, obtain the interface path from the test request.

[0101] It should be understood that, to improve the accuracy of mock interface matching, this embodiment obtains the interface path from the test request and matches the corresponding mock interface in the cache based on the interface path. The interface path can be the interface address specified in the test request, used to uniquely identify an interface. In RESTful APIs, the interface path may include a resource name and an optional resource identifier; this embodiment does not impose such limitations. In the specific implementation, when the mock service receives a test request, it first parses the request and extracts the interface path. This interface path will be used to find a matching mock interface in the cache.

[0102] Step S102: Match the simulated interface corresponding to the test request in the cache according to the interface path.

[0103] Understandably, the mock service can use the extracted interface path as a key to look up the corresponding mock interface object in the cache. If a matching mock interface is found, processing continues; otherwise, a 404 error is returned.

[0104] This embodiment obtains the interface path from the test request and matches the simulated interface corresponding to the test request in the cache based on the interface path, thereby improving the accuracy of simulated interface matching.

[0105] In the second embodiment, step S20 includes:

[0106] Step S201: Obtain the test mode, wherein the test mode includes the basic mode or the proxy mode.

[0107] It should be understood that, in order to meet the different testing needs of different users, this embodiment can also set a test mode, including a basic mode or a proxy mode, and perform interface testing on the simulated interface according to the test mode.

[0108] It should be understood that after finding a matching mock interface, the mock service will obtain the test mode corresponding to that interface. The test mode determines how the mock service generates response data or processes requests. In this embodiment, the test mode may include a basic mode and a proxy mode. The basic mode refers to the mock service directly generating response data based on the user configuration. The proxy mode refers to the mock service forwarding requests to downstream real services and using the real service's response as the response data for the mock interface; it may also refer to directly retrieving the response data corresponding to the mock interface from the cache. This embodiment does not limit this.

[0109] Step S202: Perform interface testing on the simulated interface according to the test mode to obtain response data.

[0110] It should be understood that, based on the obtained test mode, the mock service will test the simulated interface. In basic mode, the mock service can directly generate response data according to user configuration. In proxy mode, the mock service can forward requests to the downstream real service and use the real service's response as the response data of the simulated interface; alternatively, it can directly retrieve the response data corresponding to the simulated interface from the cache, and this embodiment does not impose any restrictions on this.

[0111] This embodiment sets up a test mode, which includes a basic mode or a proxy mode, and performs interface testing on the simulated interface according to the test mode, thereby meeting the different testing needs of different users.

[0112] Reference Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the interface testing method of this application, based on the above. Figure 3 The second embodiment shown presents a third embodiment of the interface testing method of this application.

[0113] In the third embodiment, step S202 includes:

[0114] Step S2021: When the test mode is in the basic mode, obtain the configuration information of the simulated interface from the cache.

[0115] It should be understood that, to meet users' basic testing needs, in this embodiment, when the test mode is basic, the configuration information of the simulated interface is retrieved from the cache, and the simulated interface is tested according to the configuration information to obtain response data. The configuration information refers to various parameters and rules configured by the user for the simulated interface, such as response headers, response codes, and response times. The configuration information determines how the simulated interface generates response data when it receives a test request. In a specific implementation, if the test mode is basic, the mock service will retrieve the configuration information of the simulated interface from the cache. The configuration information may include various parameters and rules configured by the user for the simulated interface, such as response headers, response codes, and response times.

[0116] Step S2022: Perform interface testing on the simulated interface according to the configuration information to obtain response data.

[0117] Understandably, after obtaining the configuration information, the mock service will test the simulated interface based on that information. During the testing process, the mock service will follow the logic and rules configured by the user to generate response data.

[0118] Furthermore, to make the data more flexible, in this embodiment, mock can use expressions and data simulation scripts to simulate dynamic data. The configuration information includes: function expressions and / or data simulation scripts; step S2022 includes: generating dynamic data according to the function expressions and / or the data simulation scripts; and performing interface testing on the simulated interface according to the dynamic data to obtain response data.

[0119] It's important to note that a function expression can be a special type of string used to describe a calculation or logical operation. In a mock service, function expressions can generate dynamic data, such as random strings or numbers, based on user configuration. Data simulation scripts can refer to code snippets written in shell scripting or other scripting languages, used to generate complex dynamic data within the mock service.

[0120] Understandably, after obtaining the configuration information, the mock service generates dynamic data based on the function expressions or data simulation scripts within this information. This data can be randomly generated strings, numbers, etc., or complex data generated based on test request parameters. After generating the dynamic data, the mock service uses the dynamic data to test the simulated interface. During the testing process, the mock service follows the logic and rules configured by the user to generate response data.

[0121] In practical implementation, parameter referencing: parameters in the URL, parameters in the form, user-defined parameters, and request headers can all be directly referenced using "{{variable name}}"; fields that support function expressions include: user variables, response codes, saved logs, delay times, and response bodies; fields that support shell code include: the response body; Variable and function expression usage: Variable: {{A}} where A represents a variable; Function expression: {{A()}} where A represents a function; Parameterized function expression: {{A(1; 2)}} where A represents a parameter. The function takes two parameters, "1" and "2", and multiple parameters are separated by ";;". The function expression is nested in multiple layers: {{For({{RandStr(5)}};;10;;,)}} where RandStr(5) randomly generates a string of length 5 and loops through the string 10 times using the For function, separated by ",". The output result is: Un05l,Un05l,Un05l,Un05l,Un05l,Un05l,Un05l,Un05l,Un05l,Un05l,Un05l,Un05l.

[0122] For ease of understanding, the following examples are provided, but they are not intended to limit this application. As an example, the following demonstrates how built-in functions in JSON can be used to implement dynamic data:

[0123] Request address: / demo.do?len=10

[0124] Response content configuration:

[0125] {"code":2000,

[0126] "data":[

[0127] {{For("{{RandStr(10)}}";;{len}};;,)}} ]

[0129] }

[0130] Here, len can be a parameter passed from the interface or a user-defined variable. RandStr(10) generates a random string of length 10, and the For function loops the random string len times, separating them with commas.

[0131] Instructions for embedding shell code: Use `<:shell>` to execute the code.<!--:shell--> This represents a shell code segment.

[0132] In this embodiment, when the test mode is in basic mode, the configuration information of the simulated interface is obtained from the cache, and the simulated interface is tested according to the configuration information to obtain response data, thereby meeting the user's basic testing needs.

[0133] Reference Figure 5 , Figure 5 This is a flowchart illustrating the fourth embodiment of the interface testing method of this application, based on the above. Figure 3 The second embodiment shown presents a fourth embodiment of the interface testing method of this application.

[0134] In the fourth embodiment, step S202 further includes:

[0135] Step S2021': When the test mode is proxy mode, check whether there is response data corresponding to the simulated interface in the cache.

[0136] It should be understood that, in order to address the issues of unstable downstream return results and latency during performance testing, the difficulty in constructing abnormal downstream return scenarios, and the challenge in locating performance problems, and to resolve the inaccuracy of test results caused by downstream instability in diff testing, thereby avoiding downstream interference and facilitating efficient and accurate problem localization, this embodiment can set up a proxy mode. In proxy mode, the mock service will first attempt to retrieve the response data of the simulated interface from the cache. If the corresponding data is not found in the cache, the mock service will forward the request to the real interface, obtain the real response, store it in the cache, and return it to the test requester.

[0137] Understandably, if the mock service's test mode is set to proxy mode, then upon receiving a test request, the mock service will first check if there is response data from a mock interface in the cache that matches the request.

[0138] Furthermore, in order to improve the accuracy of data matching, step S2021' includes: when the test mode is proxy mode, generating a matching identifier according to the test request and the generation rules configured by the user; and detecting whether there is response data corresponding to the simulated interface in the cache according to the matching identifier.

[0139] It's important to note that the matching identifier can be a unique identifier generated based on user-configured generation rules and the test request, used to find matching response data in the cache. In the specific implementation, if the mock service's test mode is set to proxy mode, upon receiving a test request, the mock service will generate a unique matching identifier based on the user-configured generation rules and the content of the test request. This identifier is used to find matching response data in the cache. The mock service uses the generated matching identifier to check if the corresponding response data exists in the cache. If it exists, processing continues; if it doesn't exist, a request is made to the real interface, and the response data is cached. For example, when a request arrives, a key is generated based on the user-configured key generation rules and the request message. This key is then used to match the data in the cache. If no match is found, the request is sent to the real downstream interface. After the real downstream interface returns, the data is stored in the cache before being returned. If a match is found, it determines whether to simulate latency. If simulation is needed, the time consumed when mocking the request to the real downstream interface is simulated; otherwise, the cached data is returned immediately.

[0140] Furthermore, to facilitate users directly requesting real interface data, step S202 further includes: when the test mode is proxy mode and transparent mode is enabled, forwarding the test request to the real interface corresponding to the simulated interface; and receiving the response data fed back by the real interface based on the test request.

[0141] It is understood that in this embodiment, the user can also configure settings, such as whether to enable transparent mode: enabling transparent mode means directly requesting the real downstream data without using mock cached data. Disabling transparent mode means that if mock has cached data, it will use the mock's cached data; otherwise, it will request the real downstream data.

[0142] Step S2022': If the cache contains response data corresponding to the simulated interface, then check whether to enable the simulated delay mode.

[0143] It should be understood that if a response matching the request exists in the cache, the mock service will further check whether simulated latency mode is enabled. If simulated latency mode is enabled, the mock service will simulate the latency of requesting the real interface; otherwise, it will directly return the cached response data. Simulated latency mode can be in proxy mode, allowing the mock service to simulate the latency of requesting the real interface, which helps to more realistically simulate the production environment and make the test results more accurate.

[0144] Furthermore, after step S2022', the method further includes: if the response data corresponding to the simulated interface does not exist in the cache, then forwarding the test request to the real interface corresponding to the simulated interface; receiving the response body and response time fed back by the real interface according to the test request; generating response data according to the response body and response time, and storing the response data in the cache.

[0145] Understandably, if no match is found, a request will be sent to the real downstream server. After the real downstream server returns the data, the data will be stored in the cache and then returned. If a match is found, it will determine whether to simulate latency. If simulation is required, the time consumed when mocking the request to the real downstream server will be simulated. Otherwise, the cached data will be returned immediately.

[0146] Step S2023': If the simulation delay mode is not enabled, retrieve the response data corresponding to the simulation interface from the cache.

[0147] Understandably, if the mock delay mode is not enabled, the mock service will directly retrieve the response data of the mock interface that matches the request from the cache.

[0148] Step S2023": If the simulation delay mode is enabled, the response data corresponding to the simulation interface is obtained from the cache after a preset time interval, wherein the preset time is the time required to request the response data from the real interface corresponding to the simulation interface.

[0149] It should be understood that if the mock delay mode is enabled, the mock service will simulate a delay based on a preset delay time (i.e., the time required to request response data from the real interface corresponding to the mock interface). After the delay ends, the mock service will retrieve the response data from the cache and return it to the test requester.

[0150] For ease of understanding, please refer to Figure 6 This explanation is provided, but does not limit the scope of this application. Figure 6 This is a flowchart illustrating the proxy pattern of an embodiment of the interface testing method of this application. Figure 6 In this context, the proxy pattern is a solution that highly simulates the real interface by recording the response body and response time. When used in performance testing and diff testing, it can solve the problem of inaccurate and unreliable test results caused by the instability of downstream components in diff testing and performance testing.

[0151] Proxy mode implementation process: The proxy mode is implemented by a preset script in tuner. When a request is received, a key is generated according to the user-configured key generation rules and the request message. This key is then used to match the data in the cache. If no match is found, the request is sent to the real downstream server. After the real downstream server returns the data, the data is stored in the cache before being returned. If a match is found, it is determined whether to simulate latency. If simulation is needed, the time consumed when mocking the request to the real downstream server is simulated; otherwise, the cached data is returned immediately.

[0152] When enabling proxy mode, users need to perform the following configuration:

[0153] 1. Whether to enable transparent mode: Enable transparent mode or use caching. Transparent mode means directly requesting the real downstream without using mock cached data. Otherwise, if there is cached data in the mock, the cached data in the mock will be used. If there is no cached data, the real downstream data will be requested.

[0154] 2. Cache key rules: Users can customize the key generation rules based on the request method, request URL, request parameters, and request body. This key is used to match cached data.

[0155] 3. Simulate Delay: Whether to select simulate delay will simulate the time consumed when making mock requests to the real downstream; otherwise, cached data will be returned immediately.

[0156] 4. Cache validity period: This refers to the validity period of the cache. Data will be automatically cleared after it expires.

[0157] 5. Real downstream address: The real downstream interface. Multiple addresses can be configured. Downstream nodes will poll requests in a round-robin fashion to avoid traffic hitting the same node and affecting the normal operation of the service.

[0158] In this embodiment, a proxy mode is set up. In proxy mode, the mock service first attempts to retrieve the response data of the simulated interface from the cache. If the corresponding data is not found in the cache, the mock service forwards the request to the real interface, retrieves the real response, stores it in the cache, and returns it to the test requester. This solves the problems of unstable downstream return results and latency, difficulty in constructing abnormal downstream return scenarios, and difficulty in locating performance issues during performance testing. It also solves the problem of inaccurate test results caused by downstream instability in diff testing, avoiding downstream interference and facilitating efficient and accurate localization.

[0159] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the interface testing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0160] This application also provides an interface testing device; please refer to [reference needed]. Figure 7 The interface testing device includes:

[0161] The interface matching module 10 is used to respond to a test request by matching the simulated interface corresponding to the test request in the cache, wherein the cache stores simulated interfaces pre-configured by the user.

[0162] Interface testing module 20 is used to perform interface testing on the simulated interface and obtain response data;

[0163] The result generation module 30 is used to generate the interface test results of the simulated interface based on the response data.

[0164] The interface testing apparatus provided in this application, employing the interface testing method described in the above embodiments, can solve the technical problems of long response times and inability to support high-concurrency and low-latency scenarios in related interface testing methods. Compared with the prior art, the beneficial effects of the interface testing apparatus provided in this application are the same as those of the interface testing method provided in the above embodiments, and other technical features in the interface testing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0165] This application provides an interface testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the interface testing method in Embodiment 1 above.

[0166] The following is for reference. Figure 8 The diagram illustrates a structural schematic of an interface testing device suitable for implementing embodiments of this application. The interface testing device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The interface testing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0167] like Figure 8As shown, the interface testing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the interface testing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the interface test equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows interface test equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0168] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0169] The interface testing device provided in this application, employing the interface testing method described in the above embodiments, can solve the technical problems of long response times and inability to support high-concurrency and low-latency scenarios in related interface testing methods. Compared with the prior art, the beneficial effects of the interface testing device provided in this application are the same as those of the interface testing method provided in the above embodiments, and other technical features of this interface testing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0170] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0171] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0172] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the interface testing method in the above embodiments.

[0173] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory), or flash memory, optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0174] The aforementioned computer-readable storage medium may be included in the interface testing equipment; or it may exist independently and not be assembled into the interface testing equipment.

[0175] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the interface testing device, cause the interface testing device to perform the aforementioned interface testing method.

[0176] Computer program code for performing the operations of this application 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 LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0177] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0178] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0179] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described interface testing method. This addresses the technical problem that related interface testing methods suffer from long response times and cannot support high-concurrency and low-latency scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the interface testing method provided in the above embodiments, and will not be elaborated upon here.

[0180] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the interface testing method described above.

[0181] The computer program product provided in this application can solve the technical problem that related interface testing methods have long response times and cannot support high-concurrency and low-latency scenarios. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the interface testing methods provided in the above embodiments, and will not be repeated here.

[0182] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

[0183] This application discloses A1, an interface testing method, the interface testing method comprising:

[0184] In response to a test request, the simulated interface corresponding to the test request is matched in the cache, wherein the cache stores simulated interfaces pre-configured by the user;

[0185] Perform interface testing on the simulated interface to obtain response data;

[0186] The interface test results of the simulated interface are generated based on the response data.

[0187] A2. The interface testing method as described in A1, wherein performing interface testing on the simulated interface to obtain response data includes:

[0188] Obtain the test mode, wherein the test mode includes either the basic mode or the proxy mode;

[0189] The simulated interface is tested according to the test mode to obtain response data.

[0190] A3. The interface testing method as described in A2, wherein performing interface testing on the simulated interface according to the test mode to obtain response data includes:

[0191] In the basic test mode, the configuration information of the simulated interface is obtained from the cache;

[0192] The simulated interface is tested according to the configuration information to obtain response data.

[0193] A4. The interface testing method as described in A3, wherein the configuration information includes: function expressions and / or data simulation scripts; the step of performing interface testing on the simulated interface according to the configuration information to obtain response data includes:

[0194] Dynamic data is generated based on the function expression and / or the data simulation script;

[0195] The simulated interface is tested based on the dynamic data to obtain response data.

[0196] A5. The interface testing method as described in A2, wherein performing interface testing on the simulated interface according to the test mode to obtain response data includes:

[0197] When the test mode is proxy mode, check whether the cache contains response data corresponding to the simulated interface;

[0198] If the cache contains response data corresponding to the simulated interface, then check whether to enable the simulated delay mode;

[0199] If the simulated delay mode is not enabled, the response data corresponding to the simulated interface is obtained from the cache;

[0200] If the simulated delay mode is enabled, the response data corresponding to the simulated interface will be retrieved from the cache after a preset time interval, wherein the preset time is the time required to request response data from the real interface corresponding to the simulated interface.

[0201] A6. The interface testing method as described in A5, after detecting whether the response data corresponding to the simulated interface exists in the cache when the test mode is proxy mode, further includes:

[0202] If the response data corresponding to the simulated interface is not found in the cache, the test request is forwarded to the real interface corresponding to the simulated interface.

[0203] Receive the response body and response time from the actual interface in response to the test request;

[0204] Response data is generated based on the response body and response time, and the response data is stored in the cache.

[0205] A7. The interface testing method as described in A5, wherein when the test mode is proxy mode, detecting whether the cache contains response data corresponding to the simulated interface includes:

[0206] When the test mode is proxy mode, a matching identifier is generated based on the test request and the generation rules configured by the user;

[0207] The cache is checked to see if the response data corresponding to the simulated interface exists based on the matching identifier.

[0208] A8. The interface testing method as described in A2, wherein performing interface testing on the simulated interface according to the test mode to obtain response data includes:

[0209] When the test mode is proxy mode and the transparent mode is enabled, the test request is forwarded to the real interface corresponding to the simulated interface;

[0210] Receive the response data fed back by the real interface in response to the test request.

[0211] A9. The interface testing method as described in any one of A1 to A8, wherein the step of performing interface testing based on user configuration and the simulated interface to obtain response data includes:

[0212] The simulated interface is copied to obtain a copied interface;

[0213] Perform interface testing on the replication interface to obtain response data.

[0214] A10. The interface testing method as described in any one of A1 to A8, further comprising, before matching the simulated interface information corresponding to the interface test request in the cache in response to the interface test request:

[0215] Receive simulated interfaces added by users on the management page;

[0216] The simulated interface is stored in the cache as an object.

[0217] A11. The interface testing method as described in any one of A1 to A8, wherein the step of matching the simulated interface corresponding to the test request in the cache in response to the test request includes:

[0218] In response to a test request, obtain the interface path from the test request;

[0219] Match the simulated interface corresponding to the test request in the cache according to the interface path.

[0220] This application also discloses B12, an interface testing device, the interface testing device comprising:

[0221] An interface matching module is used to respond to a test request by matching the simulated interface corresponding to the test request in the cache, wherein the cache stores simulated interfaces pre-configured by the user.

[0222] The interface testing module is used to perform interface testing on the simulated interface and obtain response data.

[0223] The result generation module is used to generate interface test results for the simulated interface based on the response data.

[0224] B13. The interface testing device as described in B12, wherein the interface testing module is further configured to acquire a test mode, wherein the test mode includes a basic mode or a proxy mode; and to perform interface testing on the simulated interface according to the test mode to obtain response data.

[0225] B14. The interface testing device as described in B13, wherein the interface testing module is further configured to, when the test mode is the basic mode, obtain the configuration information of the simulated interface from the cache; perform interface testing on the simulated interface according to the configuration information, and obtain response data.

[0226] B15. The interface testing device as described in B14, wherein the configuration information includes: function expressions and / or data simulation scripts; the interface testing module is further configured to generate dynamic data based on the function expressions and / or the data simulation scripts; and to perform interface testing on the simulated interface based on the dynamic data to obtain response data.

[0227] B16. The interface testing device as described in B13, wherein the interface testing module is further configured to, when the test mode is proxy mode, detect whether there is response data corresponding to the simulated interface in the cache; if there is response data corresponding to the simulated interface in the cache, detect whether to enable the simulated delay mode; if the simulated delay mode is not enabled, retrieve the response data corresponding to the simulated interface from the cache; if the simulated delay mode is enabled, retrieve the response data corresponding to the simulated interface from the cache after a preset time interval, wherein the preset time is the time required to request response data from the real interface corresponding to the simulated interface.

[0228] B17. The interface testing apparatus as described in B16, wherein the interface testing module is further configured to: forward the test request to the real interface corresponding to the simulated interface if the response data corresponding to the simulated interface does not exist in the cache; receive the response body and response time fed back by the real interface according to the test request; generate response data according to the response body and response time; and store the response data in the cache.

[0229] This application also discloses C18, an interface testing device, the interface testing device comprising: a memory, a processor, and an interface testing program stored in the memory and executable on the processor, wherein the interface testing program, when executed by the processor, implements the interface testing method described above.

[0230] This application also discloses D19, a storage medium storing an interface test program, which, when executed by a processor, implements the interface test method described above.

[0231] This application also discloses E20, a computer program product including an interface test program, which, when executed by a processor, implements the interface test method described above.

Claims

1. An interface testing method, characterized in that, The interface testing method includes: In response to a test request, the simulated interface corresponding to the test request is matched in the cache, wherein the cache stores simulated interfaces pre-configured by the user; Perform interface testing on the simulated interface to obtain response data; The interface test results of the simulated interface are generated based on the response data.

2. The interface testing method as described in claim 1, characterized in that, The step of performing interface testing on the simulated interface to obtain response data includes: Obtain the test mode, wherein the test mode includes either the basic mode or the proxy mode; The simulated interface is tested according to the test mode to obtain response data.

3. The interface testing method as described in claim 2, characterized in that, The step of performing interface testing on the simulated interface according to the test mode to obtain response data includes: In the basic test mode, the configuration information of the simulated interface is obtained from the cache; The simulated interface is tested according to the configuration information to obtain response data.

4. The interface testing method as described in claim 3, characterized in that, The configuration information includes: function expressions and / or data simulation scripts; the step of performing interface testing on the simulation interface according to the configuration information to obtain response data includes: Dynamic data is generated based on the function expression and / or the data simulation script; The simulated interface is tested based on the dynamic data to obtain response data.

5. The interface testing method as described in claim 2, characterized in that, The step of performing interface testing on the simulated interface according to the test mode to obtain response data includes: When the test mode is proxy mode, check whether the cache contains response data corresponding to the simulated interface; If the cache contains response data corresponding to the simulated interface, then check whether to enable the simulated delay mode; If the simulated delay mode is not enabled, the response data corresponding to the simulated interface is obtained from the cache; If the simulated delay mode is enabled, the response data corresponding to the simulated interface will be retrieved from the cache after a preset time interval, wherein the preset time is the time required to request response data from the real interface corresponding to the simulated interface.

6. The interface testing method as described in claim 5, characterized in that, When the test mode is proxy mode, after checking whether the cache contains response data corresponding to the simulated interface, the method further includes: If the response data corresponding to the simulated interface is not found in the cache, the test request is forwarded to the real interface corresponding to the simulated interface. Receive the response body and response time from the actual interface in response to the test request; Response data is generated based on the response body and response time, and the response data is stored in the cache.

7. An interface testing device, characterized in that, The interface testing device includes: An interface matching module is used to respond to a test request by matching the simulated interface corresponding to the test request in the cache, wherein the cache stores simulated interfaces pre-configured by the user. The interface testing module is used to perform interface testing on the simulated interface and obtain response data. The result generation module is used to generate interface test results for the simulated interface based on the response data.

8. An interface testing device, characterized in that, The interface testing device includes: a memory, a processor, and an interface testing program stored in the memory and executable on the processor. When the interface testing program is executed by the processor, it implements the interface testing method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores an interface test program, which, when executed by a processor, implements the interface test method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes an interface test program, which, when executed by a processor, implements the interface test method as described in any one of claims 1 to 6.

Images