Interface testing method and device and readable storage medium

Abstract

The invention provides an interface testing method and device and a readable storage medium, and relates to the technical field of software testing, and the method comprises the steps: configuring a plurality of first-level downstream services corresponding to a tested interface; in response to a first test performed on the tested interface by a tester, starting a cache function for the plurality of first-level downstream services of the tested interface, and storing response contents of all the called interfaces of the plurality of first-level downstream services in the first test in a cache; in response to the Nth test performed on the tested interface by a tester, the first-level downstream service of the tested interface directly reads the corresponding response content in the cache and returns the response content, Ngt; 1. According to the method, the device and the readable storage medium, the problem of low test efficiency caused by calling of a plurality of other service interfaces when the tested interface is tested by an existing interface test method can be solved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to an interface testing method, device and readable storage medium. Background Art

[0002] In a complex microservice application system, an interface usually calls the interfaces of other services during execution. The complete business logic can only be completed when all interface calls return successfully.

[0003] A simple interface implementation diagram is as follows Figure 1 As shown, during the execution of interface A (belonging to service A), request B (interface B requesting service B) and request C (interface C requesting service C) will occur, and interface B will request interface D1 of service D during the execution, and interface C will request interface D2 of service D during the execution. Only when all the involved interfaces (interface B, interface C, interface D1, interface D2) of all the involved services (such as service B, service C) respond normally and return successfully, can interface A continue to complete the execution of its own logic and finally return the result to the client. When testing interface A, due to the call of multiple other service interfaces, the response speed of interface A will be relatively slow, especially when the response speed of some interfaces in the call chain is very slow (assuming that interface D1 is very slow), it will further drag down the response speed of interface A. In the test environment, due to the shortage of server resources and the limited resource support for each service, the response of interface A will be even slower, which leads to low test efficiency, especially when multiple tests need to be initiated on interface A. Summary of the invention

[0004] The technical problem to be solved by the present invention is to provide an interface testing method, device and readable storage medium in view of the above-mentioned deficiencies in the prior art, so as to solve the problem of low testing efficiency caused by calling multiple other service interfaces when testing the interface under test in the existing interface testing method.

[0005] In a first aspect, the present invention provides an interface testing method, the method comprising:

[0006] Configure multiple first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs;

[0007] In response to the tester performing a first test on the interface under test, enabling a cache function for multiple first-level downstream services of the interface under test, and saving response contents of all called interfaces of multiple first-level downstream services in the first test in the cache;

[0008] In response to the tester performing the Nth test on the interface under test, the first-level downstream service of the interface under test directly reads the corresponding response content in the cache and returns it, where N>1.

[0009] Furthermore, before configuring a plurality of first-level downstream services corresponding to the interface under test, the method further includes:

[0010] Receiving interface configuration information of the tested interface input by a tester, wherein the interface configuration information includes a name of an application to which the tested interface belongs and an address of the tested interface;

[0011] Add the interface configuration information according to the tester's new instructions, and add the interface configuration information to the interface configuration list;

[0012] The configuring of multiple first-level downstream services corresponding to the interface under test specifically includes:

[0013] According to the editing operation on the tested interface triggered by the tester based on the interface configuration list, displaying the first-level downstream service list page corresponding to the tested interface;

[0014] According to the tester's adding operation based on the first-level downstream service list page, multiple first-level downstream services corresponding to the tested interface are configured.

[0015] Further, in response to the tester performing a first test on the interface under test, enabling a cache function for multiple first-level downstream services of the interface under test, and saving the response contents of all called interfaces of multiple first-level downstream services in the first test in the cache, the method further includes:

[0016] In response to the tester's operation of turning on the status of the tested interface in the interface configuration list, a first remote command is executed according to the turning on operation to call a first monitoring logic implementation package to mount and monitor the application to which the tested interface belongs, and all the first-level downstream services configured by the tested interface are traversed and read, a second remote command is executed for each of the first-level downstream services, and a second monitoring logic implementation package is called through the second remote command to mount and monitor the application and the first-level downstream service;

[0017] The first monitoring logic implementation package is used to add a preset header information to the corresponding Hypertext Transfer Protocol HTTP request header if a request to a first-level downstream service interface is initiated during the execution of the tested interface;

[0018] The second monitoring logic implementation package is used to save the response content of a first-level downstream service interface to the remote dictionary service Redis based on the preset header information during the first test during the execution of the interface under test; or to read the response content from Redis based on the preset header information and return it to the caller during the Nth test.

[0019] Furthermore, the implementation logic of the first monitoring logic implementation package includes:

[0020] Monitor all methods in the application, and when a method is called, determine whether the method is an interface method before execution;

[0021] In response to the method being an interface method, obtaining the address of the method, and determining whether the address of the method is an interface configured in the interface configuration list, and whether the corresponding application is a currently monitored application, and if so, saving the address of the method into a preset thread variable;

[0022] In response to the certain method not being an interface method, determining whether the certain method is a preset specific method, and if so, attempting to obtain a value from the thread variable, and if the value can be obtained from the thread variable, obtaining a first parameter object of the specific method, and adding a preset header information in the HTTP request header through the first parameter object of the specific method;

[0023] The specific method is used to indicate that the interface under test has initiated a request to a first-level downstream service interface during execution.

[0024] Further, the determining whether the method is an interface method specifically includes:

[0025] Get the object that calls the method, and use reflection to get the class object of the object;

[0026] Use the class object to obtain the method Method object of the method;

[0027] Using the Method object to determine whether the method contains a preset annotation;

[0028] In response to the certain method including a preset annotation, it is determined that the certain method is an interface method.

[0029] Furthermore, the implementation logic of the second monitoring logic implementation package includes:

[0030] Monitor all methods in the application. When a method is called, before the method is executed, execute step S1. After the method is executed, before returning the content to the caller, execute step S2:

[0031] S1, determine whether the method is an interface method, in response to the method being an interface method, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method, if the target header information matches the preset header information, and the address of the method is the interface configured in the interface configuration list, try to read the value value of the key key corresponding to the method in Redis, and return the value as the response content of the method to the caller;

[0032] S2, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method. If the target header information matches the preset header information, generate the key corresponding to the method, and save the response content to be returned to the caller as the value of the key corresponding to the method in the Redis.

[0033] Further, if the target key exists in the target header information, and the value of the target key is the same as the value of the target key in the preset header information, it is determined that the target header information matches the preset header information.

[0034] In a second aspect, the present invention provides an interface testing device, the device comprising:

[0035] A downstream service configuration module, used to configure multiple first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs;

[0036] A first test module, connected to the downstream service configuration module, is used to enable a cache function for multiple first-level downstream services of the tested interface in response to a tester performing a first test on the tested interface, and save the response contents of all called interfaces of multiple first-level downstream services in the first test in the cache;

[0037] The second test module is connected to the first test module, and is used for directly reading the corresponding response content in the cache and returning it in response to the tester performing the Nth test on the interface under test, where N>1.

[0038] In a third aspect, the present invention provides an interface testing device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the interface testing method described in the first aspect.

[0039] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the interface testing method described in the first aspect is implemented.

[0040] The interface testing method, device and readable storage medium provided by the present invention. First, multiple first-level downstream services corresponding to the interface under test are configured, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs; then, in response to the tester performing the first test on the interface under test, the cache function is enabled for the multiple first-level downstream services of the interface under test, and the response contents of all called interfaces of the multiple first-level downstream services in the first test are saved in the cache; and in response to the tester performing the Nth test on the interface under test, the first-level downstream service of the interface under test directly reads the corresponding response content in the cache and returns it, wherein N>1. The present application automatically enables the cache function for multiple first-level downstream services of the interface under test, and saves the response contents obtained in the first test in the cache, so that when the interface under test calls these first-level downstream services again, the response contents can be directly read from the cache, thereby avoiding the time consumption caused by executing other service interfaces multiple times, and significantly improving the test efficiency of the interface under test. The problem of low test efficiency caused by the call of multiple other service interfaces in the existing interface testing method when testing the interface under test is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 Implement schematics for existing interfaces;

[0042] Figure 2 This is a flow chart of an interface testing method according to Embodiment 1 of the present invention;

[0043] Figure 3 A schematic diagram of a new page for interface configuration information according to an embodiment of the present invention;

[0044] Figure 4 This is a schematic diagram of an interface configuration list display page according to an embodiment of the present invention;

[0045] Figure 5 This is a schematic diagram of a first-level downstream service list page according to an embodiment of the present invention;

[0046] Figure 6 A schematic diagram of a newly added page for the first-level downstream service of an embodiment of the present invention;

[0047] Figure 7 This is a schematic diagram of the structure of an interface testing device according to Embodiment 2 of the present invention;

[0048] Figure 8This is a structural schematic diagram of an interface testing device according to embodiment 3 of the present invention. DETAILED DESCRIPTION

[0049] In order to enable those skilled in the art to better understand the technical solution of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0050] It should be understood that the specific embodiments and drawings described herein are only used to explain the present invention rather than to limit the present invention.

[0051] It can be understood that, in the absence of conflict, the various embodiments of the present invention and the various features in the embodiments can be combined with each other.

[0052] It can be understood that, for the convenience of description, the drawings of the present invention only show the parts related to the present invention, while the parts irrelevant to the present invention are not shown in the drawings.

[0053] It can be understood that each unit and module involved in the embodiments of the present invention may correspond to only one physical structure, or may be composed of multiple physical structures, or multiple units and modules may be integrated into one physical structure.

[0054] It can be understood that the terms "first", "second", etc. in the embodiments of the present invention are used to distinguish different objects, or to distinguish different processing of the same object, rather than to describe a specific order of objects.

[0055] It can be understood that, in the absence of conflict, the functions and steps marked in the flowcharts and block diagrams of the present invention may occur in an order different from that marked in the drawings.

[0056] It is understood that the flowcharts and block diagrams of the present invention illustrate the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to the various embodiments of the present invention. Each box in the flowchart or block diagram may represent a unit, module, program segment, or code, which contains executable instructions for implementing the specified functions. Moreover, each box or combination of boxes in the block diagram and flowchart may be implemented by a hardware-based system that implements the specified functions, or may be implemented by a combination of hardware and computer instructions.

[0057] It can be understood that the units and modules involved in the embodiments of the present invention can be implemented by software or hardware. For example, the units and modules can be located in a processor.

[0058] Embodiment 1:

[0059] This embodiment provides an interface testing method, such as Figure 2 As shown, the method includes:

[0060] Step S101: configuring a plurality of first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to a service to which an interface directly called during the execution of the interface under test belongs.

[0061] In this embodiment, the service names of multiple first-level downstream services corresponding to the tested interface can be configured according to the tester's instructions, such as kcard-zzz, kcard-sss, etc., and associated with the address of the tested interface and the application to which it belongs. The first-level downstream service refers to the service to which the interface directly calls during the execution of the tested interface belongs.

[0062] Optionally, before configuring a plurality of first-level downstream services corresponding to the interface under test, the method further includes:

[0063] Receiving interface configuration information of the tested interface input by a tester, the interface configuration information including the name of the application to which the tested interface belongs and the address of the tested interface;

[0064] Add the interface configuration information according to the new instructions of the tester, and add the interface configuration information to the interface configuration list;

[0065] The configuring of the plurality of first-level downstream services corresponding to the interface under test specifically includes:

[0066] According to the editing operation on the tested interface triggered by the tester based on the interface configuration list, displaying the first-level downstream service list page corresponding to the tested interface;

[0067] According to the adding operation performed by the tester based on the first-level downstream service list page, multiple first-level downstream services corresponding to the tested interface are configured.

[0068] In this embodiment, the tester can fill in the interface configuration information of the tested interface on the interface configuration information new page. The schematic diagram of the interface configuration information new page can be as follows: Figure 3 As shown in the figure, application refers to the name of the application to which the tested interface belongs, such as kcard-xxx; interface refers to the address of the tested interface; when the tester clicks the "Add" button, he can enter Figure 4 The interface configuration list page shown in the figure shows all the configuration information. For the newly added configuration (such as the kcard-xxx line), the status is "Not Enabled" by default. When the tester clicks the "Edit" button to trigger the editing operation for the tested interface, a pop-up window will appear. Figure 5 The first-level downstream service list page shown in the figure, each time the tester clicks the "Add" button in the upper right corner, Figure 6In the new page for the first-level downstream service shown, you can add a new line of configuration.

[0069] Step S102: in response to the tester performing a first test on the interface under test, enabling a cache function for multiple first-level downstream services of the interface under test, and saving response contents of all called interfaces of multiple first-level downstream services in the first test in the cache;

[0070] Step S103: In response to the tester performing the Nth test on the interface under test, the first-level downstream service of the interface under test directly reads the corresponding response content in the cache and returns it, where N>1.

[0071] In this embodiment, after the test is initiated for the first time, the first-level downstream services and interfaces of the interface under test will enable the cache function and save the first response in the cache; when the test is initiated for the second time, the first-level downstream interface of the interface under test will directly read the response content in the cache and return it, and will not repeatedly execute the interface logic. Therefore, the response speed is very fast, thereby greatly saving the execution time of the interface under test.

[0072] Optionally, in response to the tester performing a first test on the interface under test, enabling a cache function for multiple first-level downstream services of the interface under test, and before saving the response contents of all called interfaces of multiple first-level downstream services in the first test in the cache, the method further includes:

[0073] In response to the tester's operation of turning on the status of the tested interface in the interface configuration list, a first remote command is executed according to the turning on operation to call a first monitoring logic implementation package to mount and monitor the application to which the tested interface belongs, and all the first-level downstream services configured by the tested interface are traversed and read, a second remote command is executed for each of the first-level downstream services, and a second monitoring logic implementation package is called through the second remote command to mount and monitor the application and the first-level downstream service;

[0074] The first monitoring logic implementation package is used to add a preset header information to the corresponding HTTP (Hyper Text Transfer Protocol) request header if a request to a first-level downstream service interface is initiated during the execution of the tested interface;

[0075] The second monitoring logic implementation package is used to save the response content of a first-level downstream service interface to Redis (Remote DictionaryServer, remote dictionary service) based on the preset header information during the execution of the interface under test in the first test; or to read the response content from Redis based on the preset header information and return it to the caller in the Nth test.

[0076] In this embodiment, when the tester clicks Figure 4 Click the "Open" button to trigger the state opening operation. At this time, the following logic is executed:

[0077] 1. Execute a remote command to mount and monitor the application. For example, the command is: . / sandbox.sh-p 7-d'service-monitor / interfaceMonit', where 7 is the process of the application, which is obtained by executing the command ps-ef|grep-ikcard-xxx|awk'{print$2}' (for example, the application is kcard-xxx); sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the application is located; jvm-sandbox is a process monitoring tool based on the jvm environment, which can monitor the java process (that is, the application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if jvm-sandbox is not used, other monitoring tools can also be used to achieve the purpose. service-monitor / interfaceMonit is the name of the first monitoring logic implementation package. The first monitoring logic implementation package is used to add a preset header information to the corresponding HTTP request header if a request to a first-level downstream service interface is initiated during the execution of the interface under test.

[0078] 2. Traverse and read all first-level downstream services of the interface under test ( Figure 5The second monitoring logic implementation package is used to save the response content of a first-level downstream service interface to Redis based on the preset header information during the execution of the tested interface in the first test; or to read the response content from Redis based on the preset header information and return it to the caller in the Nth test.

[0079] Optionally, the implementation logic of the first monitoring logic implementation package includes:

[0080] Monitor all methods in the application, and when a method is called, determine whether the method is an interface method before execution;

[0081] In response to the method being an interface method, obtaining the address of the method, and determining whether the address of the method is an interface configured in the interface configuration list, and whether the corresponding application is a currently monitored application, and if so, saving the address of the method into a preset thread variable;

[0082] In response to the certain method not being an interface method, determining whether the certain method is a preset specific method, and if so, attempting to obtain a value from the thread variable, and if the value can be obtained from the thread variable, obtaining a first parameter object of the specific method, and adding a preset header information in the HTTP request header through the first parameter object of the specific method;

[0083] The specific method is used to indicate that the interface under test has initiated a request to a first-level downstream service interface during execution.

[0084] In this embodiment, the thread variable threadLocal is a global static variable of ThreadLocal type. The saved data can be read at any time during the subsequent operation of the thread, and can only be read by the program executed under the thread, and will not be read by other threads. The specific method is, for example, the javax.servlet.http.HttpServlet#service method. In spring, the HTTP request is initiated using code, and the underlying method is the javax.servlet.http.HttpServlet#service method; when this method is called, it means that the interface under test has initiated a request to a first-level downstream service interface during execution. The preset header information includes a key and a corresponding value. For example, the preset header information can be serviceZ:kcard / superVip / receive, where serviceZ is the key, kcard / superVip / receive is the corresponding value, and kcard / superVip / receive is the URL (Uniform Resource Locator) of the interface under test, that is, the address, which is obtained from the line variable threadLocal.

[0085] Optionally, determining whether the method is an interface method specifically includes:

[0086] Get the object that calls the method, and use reflection to get the class object of the object;

[0087] Use the class object to obtain the method Method object of the method;

[0088] Using the Method object to determine whether the method contains a preset annotation;

[0089] In response to the certain method including a preset annotation, it is determined that the certain method is an interface method.

[0090] In this embodiment, a preset annotation such as @RequestMapping annotation is used to determine whether the method is annotated with @RequestMapping. If so, it indicates that the method is an interface method.

[0091] Optionally, the implementation logic of the second monitoring logic implementation package includes:

[0092] Monitor all methods in the application. When a method is called, before the method is executed, execute step S1. After the method is executed, before returning the content to the caller, execute step S2:

[0093] S1, determine whether the method is an interface method, in response to the method being an interface method, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method, if the target header information matches the preset header information, and the address of the method is the interface configured in the interface configuration list, try to read the value value of the key key corresponding to the method in Redis, and return the value as the response content of the method to the caller;

[0094] S2, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method. If the target header information matches the preset header information, generate the key corresponding to the method, and save the response content to be returned to the caller as the value of the key corresponding to the method in the Redis.

[0095] In this embodiment, the key corresponding to the method can be composed of the service name of the first-level downstream service + request URL + tested interface URL, such as kcard-zzz: / kcard / ecs / kindCardInfo:kcard / superVip / receive, where kcard-zzz is the service name, / kcard / ecs / kindCardInfo is the request URL, and kcard / superVip / receive is the tested interface URL. The corresponding value is the corresponding response content.

[0096] Optionally, if the target header information contains a target key, and the value of the target key is the same as the value of the target key in the preset header information, it is determined that the target header information matches the preset header information.

[0097] In this embodiment, taking the preset header information serviceZ:kcard / superVip / receive as an example, first try to obtain the value of the key serviceZ in the target header information. If the value can be obtained and the value is kcard / superVip / receive, it is determined that the target header information matches the preset header information.

[0098] In an optional embodiment, an expiration time may be specified for the response content stored in Redis. For example, specifying an expiration time of 3600 seconds means that the cache will only be saved for 1 hour.

[0099] In a specific embodiment, the interface testing method may include the following steps:

[0100] Step 1: Testers Figure 3 In the interface configuration information adding page shown, add a new configuration information, fill in the application, interface, and then click the "Add" button.

[0101] Among them, application: refers to the name of the application to which the tested interface belongs, such as kcard-xxx;

[0102] Interface: refers to the interface being tested;

[0103] After clicking the "Add" button, a request will be triggered to service Z (the service provided by the present invention). After receiving the request, service Z will save the newly added configuration to Redis for subsequent use; among them, for the newly added configuration, the value of the status field is saved as "not enabled" by default.

[0104] Step 2, then jump to Figure 4 The interface configuration list page shown in the figure shows all the configuration information. For the newly added configuration (such as the kcard-xxx line), the status is "Not Enabled" by default. At this time, the tester can click the "Enable" button to change the status to Enabled. In order to make the configuration effective, the tester needs to further click the "Edit" button. Figure 5 , and further edit the row configuration. Only after further editing is completed can the status be changed to enabled.

[0105] Specifically, jump to Figure 4 After the page is opened, the page will initiate a query request to service Z to query all configuration information; service Z reads all configuration information saved in Redis and returns it to the page, which is displayed as a table; the tester clicks the "Open" button, which triggers a request to service Z. After receiving the request, service Z executes the following logic:

[0106] 1. Execute the remote command to mount and monitor the application. The command is: . / sandbox.sh -p 7 -d 'service-monitor / interfaceMonit', where 7 is the process of the application, which is obtained by executing the command ps-ef|grep-ikcard-xxx|awk'{print$2}' (for example, the target application is kcard-xxx); sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the application is located; jvm-sandbox is a process monitoring tool based on the jvm environment, which can monitor the java process (i.e., the application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if jvm-sandbox is not used, other monitoring tools can also be used to achieve the purpose; service-monitor / interfaceMonit is the name of the monitoring logic implementation package provided by the present invention, and the implementation logic is as follows:

[0107] (1) Monitor all methods in the application. When a method is called, execute the logic in (2) before the method is executed.

[0108] (2) Determine whether the method is annotated with @RequestMapping. If so, then execute the logic from (3) to (5). If not, then execute the logic from (6) to (7). The implementation logic of the judgment is as follows:

[0109] (2-1) Get the object that calls the method, use reflection to get the class object of the object (code: Class<?> aClass = target.getClass()), and use the class object to get the Method object of the method (code: MethoddeclaredMethod = aClass.getDeclaredMethod(bEvent.javaMethodName));

[0110] (2-2) Use the Method object to determine whether the method contains

[0111] @RequestMapping annotation (code:

[0112] if(declaredMethod.isAnnotationPresent(RequestMapping.class))), if it is included, it means that the method is annotated with @RequestMapping, which means that the method is an interface method;

[0113] (3) Use the Method object to obtain the @RequestMapping annotation object acting on it (code: RequestMapping annotation = declaredMethod.getAnnotation(RequestMapping.class)), and then obtain the value of the value attribute of the annotation object (code: String url = annotation.value()), which represents the interface address mapped to the current method;

[0114] (4) Determine whether the interface address is Figure 4 An interface of a configuration in the page list, and whether the application of the configuration is the currently monitored application, if both are, execute the logic of (5);

[0115] (5) Save the interface address (such as kcard / superVip / receive) to the thread variable threadLocal (the code is threadLocal.set("kcard / superVip / receive")). Here, threadLocal is a global static variable of type ThreadLocal, which is used to save some data during the thread execution process (such as kcard / superVip / receive here). The saved data can be read at any time during the subsequent running of the thread, and can only be read by the program executed under the thread, and will not be read by other threads (other threads read the thread variable data saved by themselves);

[0116] (6) If the current method is the javax.servlet.http.HttpServlet#service method, try to get the value from the thread variable threadLocal. If the value can be obtained, execute the logic of (7). Here is an explanation. In spring, when using code to initiate an http request, the underlying method used is the javax.servlet.http.HttpServlet#service method. When this method is called, it means that the interface under test has initiated a request to a first-level downstream service interface during execution.

[0117] It should be noted that the javax.servlet.http.HttpServlet#service method is a specific method in the application in addition to the above interface methods. It is a bottom-level method in the spring framework. When the interface under test needs to initiate a request to the first-level service interface during execution, it will call this method to initiate the request. If the value can be obtained from the thread variable threadLocal, it means that this method (javax.servlet.http.HttpServlet#service) is called during the execution of the interface under test and requires intervention. If the value cannot be obtained, it means that although this method has been called, it is not the interface under test (in Figure 4 If the interface is configured in the configuration and the status is enabled), then there is no need to intervene. Here, what this value is is not the key, the key is whether there is a value.

[0118] (7) Get the first parameter object of the method (i.e., the object of the javax.servlet.http.HttpServletRequest class), and add a piece of information to the request header through the object, the content of which is serviceZ:kcard / superVip / receive, where kcard / superVip / receive is the URL of the interface under test, obtained from the line variable threadLocal. The purpose of adding this information is to check whether there is this information when the interface of the first-level service is called later. At this time, there are two situations: if there is this information, it means that the request is initiated from the interface under test and intervention is required; if there is no this information, it means that the request is not initiated from the interface under test and intervention is not required.

[0119] It should be noted that during the execution of the interface under test, requests to certain interfaces of multiple first-level services may be initiated, and each request is initiated through this method (javax.servlet.http.HttpServlet#service). Therefore, steps (6) and (7) will be executed multiple times.

[0120] 2. Traverse and read all first-level downstream services of the interface ( Figure 5 The command is: . / sandbox.sh -p 3 -d 'service-monitor / firstInterfaceMonit', where 3 is the process of a first-level downstream service; service-monitor / firstInterfaceMonit is the monitoring logic implementation package for the first-level downstream service provided by the present invention, and the implementation logic is as follows:

[0121] (1) Monitor all methods in the application. When a method is called, execute the logic from (2) to (6) before it is executed. After it is executed and before the content is returned to the caller, execute the logic from (7) to (8).

[0122] (2) Determine whether the method is annotated with @RequestMapping. If so, then execute the logic of (3); the implementation logic of the judgment is the same as that in service-monitor / interfaceMonit; here is an explanation, confirming that the method is annotated with @RequestMapping, which means that the method is an interface method. Since it is an interface method, the first parameter of the method must be an object of the HttpServletRequest class;

[0123] (3) Get the first parameter object of the method (referring to the method of the first-level downstream service), which must be an object of the HttpServletRequest class; try to get the value of the key serviceZ in the request header information of the interface through the object (the code is request.getHeader("serviceZ")). If the value can be obtained, execute the logic of (4); Here, the reason why the header information serviceZ:kcard / superVip / receive can be obtained in this step is because there is related processing in the service-monitor / interfaceMonit package mentioned above. The processing is: during the execution of the interface under test, if a request to the first-level service interface is initiated, the header information serviceZ:kcard / superVip / receive is added to the request header before the request. See the previous description for details;

[0124] It should be noted that the tested interface only needs Figure 4 If it is configured and the status is enabled, each time during the execution process, if a request is initiated to a first-level downstream service interface, the serviceZ header information will be added to the request header.

[0125] (4) Get the value and determine whether it is Figure 4 If a certain interface under test is in the state of being opened, then the logic of (5) is executed;

[0126] (5) Obtain the requested URL through the HttpServletRequest object (the code is request.getRequestURI()), concatenate it with the application name as the key, and attempt to read the corresponding value in Redis (the code is like this get kcard-zzz: / kcard / ecs / kindCardInfo). If the value can be read, execute the logic in (6);

[0127] (6) Return this value as the return value of this method to the caller (that is, return the interface response content). After returning, this method is equivalent to being mocked and its own code will not be executed. If the value cannot be read in the previous step (that is, the response content of this first-level downstream service interface does not exist in Redis, indicating that this is the first test at this time), then (6) will not be executed, that is, this method will not be mocked, and its own code and response content will be executed normally at this time.

[0128] (7) Still obtain the first parameter object (HttpServletRequest object) of this method first, and attempt to obtain the value of the key serviceZ in the request header information of the interface through this object. If the value can be obtained and the value is kcard / superVip / receive, execute the logic in (8);

[0129] (8) Obtain the requested URL through the HttpServletRequest object, and save the response content that will be returned to the caller in Redis. Among them, the key is the concatenation of the application name and the requested URL (the code is like this set kcard-zzz: / kcard / ecs / kindCardInfo “{“code”:”0000”,”message”:”is Wang Card”,”result”:”success”}” expire 3600); Specify the expiration time as 3600 seconds when saving, indicating that this cache will only be saved for 1 hour.

[0130] It should be noted that (7) and (8) will only be executed when the tested interface is executed for the first time or the cache here expires. Otherwise, only (2) to (6) will be executed. Because when (6) is executed, the method is mocked, and then the method will not be really executed, so there is no such opportunity as "before returning the content to the caller".

[0131] It should be noted that in an alternative implementation, to avoid mutual influence caused by the same first-level service in different applications, the following changes can be made to (5), (7), and (8) in 2:

[0132] a) For (5): Change the key to be composed of the service name (of the first-level downstream service) + request URL + tested interface URL (i.e., the address of the tested interface), such as kcard-zzz: / kcard / ecs / kindCardInfo:kcard / superVip / receive, where kcard-zzz is the service name, / kcard / ecs / kindCardInfo is the request URL, and kcard / superVip / receive is the tested interface URL.

[0133] b) For (7): It is necessary to determine whether the value is Figure 4 If a tested interface in the table is in the enabled state, then the logic in (8) is executed;

[0134] c) For (8): also change the key to be composed of the service name + request URL + tested interface URL, such as

[0135] kcard-zzz: / kcard / ecs / kindCardInfo:kcard / superVip / receive.

[0136] Step 3. Click the "Edit" button to jump to Figure 5 The first-level downstream service list page shown in the figure, on this page, the tester needs to configure the information: the first-level downstream service. The first-level downstream service refers to the service to which the interface directly calls during the execution of the tested interface belongs; each time the tester clicks the "Add" button (it will open Figure 6 To add a new line of configuration, click the First-level Downstream Service Add Page shown in the figure.

[0137] Specifically, the role of configuring the first-level downstream service is as described above. It should be noted that we only need to configure the first-level downstream service, and do not need to configure the second- and third-level downstream services. The reason is that as long as the interface of the second-level downstream service directly returns the content in the cache, it is equivalent to being mocked, and the second- and third-level downstream service interfaces will not be called. Therefore, there is no need to cache the interfaces of the second- and third-level downstream services.

[0138] It should be noted that mock can be understood as substitution, that is, the value read from Redis replaces the return value of the method. After the substitution, the method is equivalent to being executed (but it is not actually executed).

[0139] Step 4. After the above configuration is completed, the tester can start testing the interface under test. After the first test is initiated, the first-level downstream service and interface of the interface under test will enable the cache function and save the first response in the cache; when the test is initiated for the second time, the first-level downstream interface of the interface under test will directly read the response content in the cache and return it without repeatedly executing the interface logic. Therefore, the response speed is very fast, which greatly saves the execution time of the interface under test.

[0140] Specifically, during interface testing, the main steps are:

[0141] 1) During the execution of the interface under test, a request to an interface (such as interface B) of a sub-service (such as service B) will occur (referred to as request B). At this time, an identifier (serviceZ:kcard / superVip / receive) will be added to the request header of request B;

[0142] 2) Service B has enabled the cache function. Therefore, when interface B is requested, it will check whether the request header contains the identifier (serviceZ:kcard / superVip / receive). If it does, it will check whether the response content of the interface has been saved in Redis. If not, it means that interface B is requested for the first time. In this case, the response content will be saved in Redis after normal execution. If it is saved, it means that interface B is not requested for the first time. In this case, the response content in the cache will be directly returned to the interface under test.

[0143] Among them, service-monitor / interfaceMonit in step S2 implements the logic of 1), and service-monitor / firstInterfaceMonit implements the logic of 2).

[0144] It should be noted that the interface testing method provided by the present invention can automatically add caching capabilities to other service interfaces, so that when the interface under test calls other service interfaces again during execution, it can read and directly return the previous response from the cache, avoiding the time-consuming repeated execution of other service interfaces, thereby improving the testing efficiency of the interface under test.

[0145] The interface testing method provided by the embodiment of the present invention first configures multiple first-level downstream services corresponding to the tested interface, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the tested interface belongs; then, in response to the tester performing the first test on the tested interface, the cache function is enabled for the multiple first-level downstream services of the tested interface, and the response contents of all called interfaces of the multiple first-level downstream services in the first test are saved in the cache; and in response to the tester performing the Nth test on the tested interface, the first-level downstream service of the tested interface directly reads the corresponding response content in the cache and returns it, wherein N>1. The present application automatically enables the cache function for the multiple first-level downstream services of the tested interface, and saves the response contents obtained in the first test in the cache, so that when the tested interface calls these first-level downstream services again, the response contents can be directly read from the cache, thereby avoiding the time consumption caused by executing other service interfaces multiple times, and significantly improving the test efficiency of the tested interface. The problem of low test efficiency caused by the call of multiple other service interfaces in the existing interface testing method when testing the tested interface is solved.

[0146] Embodiment 2:

[0147] like Figure 7 As shown, this embodiment provides an interface testing device, which is used to execute the above interface testing method, including:

[0148] The downstream service configuration module 11 is used to configure a plurality of first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs;

[0149] The first test module 12 is connected to the downstream service configuration module 11, and is used to enable a cache function for multiple first-level downstream services of the interface under test in response to the tester performing a first test on the interface under test, and save the response contents of all called interfaces of multiple first-level downstream services in the first test in the cache;

[0150] The second test module 13 is connected to the first test module 12, and is used for directly reading the corresponding response content in the cache and returning it in response to the tester performing the Nth test on the interface under test, where N>1.

[0151] Optionally, the device further comprises:

[0152] A configuration information receiving module, used to receive interface configuration information of the tested interface input by a tester, wherein the interface configuration information includes the name of the application to which the tested interface belongs and the address of the tested interface;

[0153] A configuration information adding module, used to add the interface configuration information according to the tester's new instructions, and add the interface configuration information to the interface configuration list;

[0154] The downstream service configuration module 11 includes:

[0155] A downstream service list display unit, configured to display a first-level downstream service list page corresponding to the interface under test according to an editing operation on the interface under test triggered by a tester based on the interface configuration list;

[0156] The downstream service configuration unit is used to configure multiple first-level downstream services corresponding to the tested interface according to the adding operation of the tester based on the first-level downstream service list page.

[0157] Optionally, the device further comprises:

[0158] A mounting monitoring module is used to respond to the tester's operation of turning on the status of the tested interface in the interface configuration list, execute a first remote command according to the turning on operation to call a first monitoring logic implementation package to mount and monitor the application to which the tested interface belongs, and traverse and read all the first-level downstream services configured by the tested interface, execute a second remote command for each of the first-level downstream services, and call a second monitoring logic implementation package through the second remote command to mount and monitor the application and the first-level downstream service;

[0159] The first monitoring logic implementation package is used to add a preset header information to the corresponding Hypertext Transfer Protocol HTTP request header if a request to a first-level downstream service interface is initiated during the execution of the tested interface;

[0160] The second monitoring logic implementation package is used to save the response content of a first-level downstream service interface to the remote dictionary service Redis based on the preset header information during the first test during the execution of the interface under test; or to read the response content from Redis based on the preset header information and return it to the caller during the Nth test.

[0161] Optionally, the mounting monitoring module includes:

[0162] A first monitoring unit is used to monitor all methods in the application, and when a method is called, before execution, determine whether the method is an interface method;

[0163] A first processing unit is configured to, in response to the method being an interface method, obtain an address of the method, and determine whether the address of the method is an interface configured in the interface configuration list, and whether the corresponding application is a currently monitored application, and if so, save the address of the method into a preset thread variable;

[0164] a second processing unit, configured to, in response to the certain method not being an interface method, determine whether the certain method is a preset specific method, and if so, attempt to obtain a value from the thread variable, and if the value can be obtained from the thread variable, obtain a first parameter object of the specific method, and add a preset header information in an HTTP request header through the first parameter object of the specific method;

[0165] The specific method is used to indicate that the interface under test has initiated a request to a first-level downstream service interface during execution.

[0166] Optionally, the first monitoring unit includes:

[0167] A class object acquisition unit, used to acquire the object that calls the method, and to acquire the class object of the object by using reflection;

[0168] A Method object acquisition unit, used to use the class object to acquire a method Method object of the method;

[0169] An annotation judgment unit, used to use the Method object to judge whether the method contains a preset annotation;

[0170] The interface method determination unit is used to determine that the certain method is an interface method in response to the certain method containing a preset annotation.

[0171] Optionally, the mounting monitoring module further includes:

[0172] The second monitoring unit is used to monitor all methods in the application. When a method is called, before the method is executed, step S1 is executed. After the method is executed, before returning the content to the caller, step S2 is executed:

[0173] S1, determine whether the method is an interface method, in response to the method being an interface method, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method, if the target header information matches the preset header information, and the address of the method is the interface configured in the interface configuration list, try to read the value value of the key key corresponding to the method in Redis, and return the value as the response content of the method to the caller;

[0174] S2, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method. If the target header information matches the preset header information, generate the key corresponding to the method, and save the response content to be returned to the caller as the value of the key corresponding to the method in the Redis.

[0175] Optionally, if the target header information contains a target key, and the value of the target key is the same as the value of the target key in the preset header information, it is determined that the target header information matches the preset header information.

[0176] Embodiment 3:

[0177] refer to Figure 8 This embodiment provides an interface testing device, including a memory 21 and a processor 22. The memory 21 stores a computer program, and the processor 22 is configured to run the computer program to execute the interface testing method in Example 1.

[0178] The memory 21 is connected to the processor 22. The memory 21 may be a flash memory, a read-only memory or other memory. The processor 22 may be a central processing unit or a single-chip microcomputer.

[0179] Embodiment 4:

[0180] This embodiment provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the interface testing method in the above-mentioned embodiment 1 is implemented.

[0181] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable read only memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0182] In summary, the interface testing method, device and readable storage medium provided by the embodiments of the present invention first configure multiple first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs; then, in response to the tester performing the first test on the interface under test, the cache function is enabled for the multiple first-level downstream services of the interface under test, and the response contents of all called interfaces of the multiple first-level downstream services in the first test are saved in the cache; and in response to the tester performing the Nth test on the interface under test, the first-level downstream service of the interface under test directly reads the corresponding response content in the cache and returns it, wherein N>1. The present application automatically enables the cache function for multiple first-level downstream services of the interface under test, and saves the response contents obtained in the first test in the cache, so that when the interface under test calls these first-level downstream services again, the response contents can be directly read from the cache, thereby avoiding the time consumption caused by executing other service interfaces multiple times, and significantly improving the test efficiency of the interface under test. The invention solves the problem that when the interface under test is tested in the existing interface testing method, the testing efficiency is low due to the calling of multiple other service interfaces.

[0183] It is to be understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present invention, but the present invention is not limited thereto. For those of ordinary skill in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. An interface testing method, characterized in that: The method comprises: Configure multiple first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs; In response to the tester performing a first test on the interface under test, enabling a cache function for multiple first-level downstream services of the interface under test, and saving response contents of all called interfaces of multiple first-level downstream services in the first test in the cache; In response to the tester performing the Nth test on the interface under test, the first-level downstream service of the interface under test directly reads the corresponding response content in the cache and returns it, where N>1.

2. The method according to claim 1, characterized in that: Before configuring a plurality of first-level downstream services corresponding to the interface under test, the method further includes: Receiving interface configuration information of the tested interface input by a tester, wherein the interface configuration information includes a name of an application to which the tested interface belongs and an address of the tested interface; Add the interface configuration information according to the tester's new instructions, and add the interface configuration information to the interface configuration list; The configuring of multiple first-level downstream services corresponding to the interface under test specifically includes: According to the editing operation on the tested interface triggered by the tester based on the interface configuration list, displaying the first-level downstream service list page corresponding to the tested interface; According to the tester's adding operation based on the first-level downstream service list page, multiple first-level downstream services corresponding to the tested interface are configured.

3. The method according to claim 1, characterized in that: In response to the tester performing a first test on the interface under test, before enabling a cache function for multiple first-level downstream services of the interface under test and saving the response contents of all called interfaces of multiple first-level downstream services in the first test in the cache, the method further includes: In response to the tester's operation of turning on the status of the tested interface in the interface configuration list, a first remote command is executed according to the turning on operation to call a first monitoring logic implementation package to mount and monitor the application to which the tested interface belongs, and all the first-level downstream services configured by the tested interface are traversed and read, a second remote command is executed for each of the first-level downstream services, and a second monitoring logic implementation package is called through the second remote command to mount and monitor the application and the first-level downstream service; The first monitoring logic implementation package is used to add a preset header information to the corresponding Hypertext Transfer Protocol HTTP request header if a request to a first-level downstream service interface is initiated during the execution of the tested interface; The second monitoring logic implementation package is used to save the response content of a first-level downstream service interface to the remote dictionary service Redis based on the preset header information during the first test during the execution of the interface under test; or to read the response content from Redis based on the preset header information and return it to the caller during the Nth test.

4. The method according to claim 3, characterized in that The implementation logic of the first monitoring logic implementation package includes: Monitor all methods in the application, and when a method is called, determine whether the method is an interface method before execution; In response to the method being an interface method, obtaining the address of the method, and determining whether the address of the method is an interface configured in the interface configuration list, and whether the corresponding application is a currently monitored application, and if so, saving the address of the method into a preset thread variable; In response to the certain method not being an interface method, determining whether the certain method is a preset specific method, and if so, attempting to obtain a value from the thread variable, and if the value can be obtained from the thread variable, obtaining a first parameter object of the specific method, and adding a preset header information in the HTTP request header through the first parameter object of the specific method; The specific method is used to indicate that the interface under test has initiated a request to a first-level downstream service interface during execution.

5. The method according to claim 4, characterized in that The determining whether the method is an interface method specifically includes: Get the object that calls the method, and use reflection to get the class object of the object; Use the class object to obtain the method Method object of the method; Using the Method object to determine whether the method contains a preset annotation; In response to the certain method including a preset annotation, it is determined that the certain method is an interface method.

6. The method according to claim 4, characterized in that The implementation logic of the second monitoring logic implementation package includes: Monitor all methods in the application. When a method is called, before the method is executed, execute step S1. After the method is executed, before returning the content to the caller, execute step S2: S1, determine whether the method is an interface method, in response to the method being an interface method, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method, if the target header information matches the preset header information, and the address of the method is the interface configured in the interface configuration list, try to read the value value of the key key corresponding to the method in Redis, and return the value as the response content of the method to the caller; S2, obtain the first parameter object of the method, and obtain the target header information in the HTTP request header through the first parameter object of the method. If the target header information matches the preset header information, generate the key corresponding to the method, and save the response content to be returned to the caller as the value of the key corresponding to the method in the Redis.

7. The method according to claim 6, characterized in that If the target key exists in the target header information, and the value of the target key is the same as the value of the target key in the preset header information, it is determined that the target header information matches the preset header information.

8. An interface testing device, characterized in that: The device comprises: A downstream service configuration module, used to configure multiple first-level downstream services corresponding to the interface under test, wherein the first-level downstream service refers to the service to which the interface directly called during the execution of the interface under test belongs; A first test module, connected to the downstream service configuration module, is used to enable a cache function for multiple first-level downstream services of the tested interface in response to a tester performing a first test on the tested interface, and save the response contents of all called interfaces of multiple first-level downstream services in the first test in the cache; The second test module is connected to the first test module, and is used for directly reading the corresponding response content in the cache and returning it in response to the tester performing the Nth test on the interface under test, where N>1.

9. An interface testing device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the interface testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the interface testing method according to any one of claims 1 to 7 is implemented.

Images