An interface call test method applied to microservices and a related device

Abstract

The application provides an interface call test method applied to micro services and a related device. The method comprises the following steps: obtaining a target interface parameter document based on a target interface code of a target interface, the target interface being used to represent a to-be-tested transaction interface provided by an interface provider in the micro services, the interface provider being used to represent an application system providing a transaction interface in the micro services; automatically generating a target test interface code based on the target interface code and the target interface parameter document, the target test interface code being used to represent a simulation interface code corresponding to an interface consumer, the interface consumer being used to represent an application system calling a transaction interface in the micro services; automatically generating a target test script based on the target test interface code and the target interface parameter document; and executing the target test script by using an interface test tool to obtain a test result of the target interface. The target test interface code and the corresponding target test script can be automatically generated by the above method, and the call test of the target interface is realized.

Description

Technical Field

[0001] This application relates to the field of interface testing technology, specifically to an interface call testing method and related apparatus applied to microservices. Background Technology

[0002] With the rapid development of Internet technology, enterprises often need to develop multiple projects to complete various business tasks. In order to solve the problems of updating and iterating multiple projects, microservice architecture has been widely used.

[0003] Microservices architecture is an architectural pattern that divides a single application into a set of small services that coordinate and cooperate with each other to provide end-user value. In practice, microservices architecture employs distributed system development, meaning it splits applications into modules, enabling rapid development and deployment of multiple applications.

[0004] In a microservice architecture, it is often necessary to call many services to complete a function. Service calls are generally implemented through API interfaces. In other words, in a microservice architecture, consumers need to access the services provided by providers by calling interfaces. Therefore, in order to ensure that the services provided by providers can be called normally, it is necessary to perform corresponding call tests on the provider's interfaces.

[0005] In related technologies, testing microservice API calls primarily involves testing the service-side API calls synchronously after the consumer-side functionality is developed. While this method provides test results for the service-side API calls, in actual microservice use, situations often arise where the service-side API is completed before the consumer-side API is developed. This leads to the service-side API not being invoked in a timely manner, hindering the development and application of microservice architectures. Summary of the Invention

[0006] This application provides a method and related apparatus for testing interface calls in microservices, which can realize automatic call testing of interfaces in microservices.

[0007] In view of this, the first aspect of the embodiments of this application provides a method for testing interface calls applied to microservices, the method comprising:

[0008] Based on the target interface code of the target interface, the target interface parameter document of the target interface is obtained. The target interface is used to represent the transaction interface to be tested provided by the interface provider in the microservice. The interface provider is used to represent the application system that provides the transaction interface in the microservice.

[0009] Based on the target interface code and the target interface parameter document, target test interface code is automatically generated. The target test interface code is used to represent the simulated interface code corresponding to the interface consumer. The interface consumer is used to represent the application system in the microservice that calls the transaction interface.

[0010] Based on the target test interface code and the target interface parameter document, the target test script is automatically generated;

[0011] The target test script is executed using an interface testing tool to obtain the test results of the target interface.

[0012] A second aspect of this application provides an interface call testing apparatus for microservices, the apparatus comprising:

[0013] The acquisition unit is used to obtain the target interface parameter document of the target interface based on the target interface code of the target interface. The target interface is used to represent the transaction interface to be tested provided by the interface provider in the microservice. The interface provider is used to represent the application system that provides the transaction interface in the microservice.

[0014] The first generation unit is used to automatically generate target test interface code based on the target interface code and the target interface parameter document. The target test interface code is used to represent the simulated interface code corresponding to the interface consumer. The interface consumer is used to represent the application system in the microservice that calls the transaction interface.

[0015] The second generation unit is used to automatically generate the target test script based on the target test interface code and the target interface parameter document;

[0016] The testing unit is used to execute the target test script using an interface testing tool to obtain the test results of the target interface.

[0017] A third aspect of this application provides an electronic device, including:

[0018] Memory, used to store executable instructions;

[0019] When the processor executes the executable instructions stored in the memory, it implements the interface call testing method for microservices provided in the embodiments of this application.

[0020] A fourth aspect of this application provides a computer-readable medium storing executable instructions, which, when executed by a processor, implement the interface call testing method for microservices provided in this application.

[0021] This application provides a method and related apparatus for testing interface calls in microservices. The method includes: obtaining a target interface parameter document based on the target interface code of the target interface, where the target interface represents a transaction interface to be tested provided by an interface provider in the microservice, and the interface provider represents an application system providing the transaction interface in the microservice; automatically generating target test interface code based on the target interface code and the target interface parameter document, where the target test interface code represents the simulated interface code corresponding to the interface consumer, and the interface consumer represents an application system in the microservice that calls the transaction interface; automatically generating a target test script based on the target test interface code and the target interface parameter document; and executing the target test script using an interface testing tool to obtain the test results of the target interface. This method can automatically generate the target test interface code and the corresponding target test script, enabling call testing of the target interface corresponding to the interface provider even when there is no interface consumer. Attached Figure Description

[0022] 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, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0023] Figure 1 A flowchart for microservice interface call management is provided as an embodiment of this application;

[0024] Figure 2 A flowchart illustrating an interface call testing method for microservices provided in this application embodiment;

[0025] Figure 3 A schematic diagram of interface parameters provided in an embodiment of this application;

[0026] Figure 4 A schematic diagram of a function template provided in an embodiment of this application;

[0027] Figure 5 A schematic diagram illustrating the automatic generation of a target test script provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of an interface call testing device for microservices provided in an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0030] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] The relevant terms used in the embodiments of this application will be explained below.

[0032] An interface (Application Programming Interface, API) is an interface used to execute a specific transaction that contains a piece of logic.

[0033] Open APIs are a common application of service-oriented websites. Website service providers encapsulate their website services into a series of APIs and expose them to third-party developers. This behavior is called opening up the website's API, and the exposed APIs are called open interfaces.

[0034] RESTful APIs are an architectural design style that provides design principles and constraints. Software designed based on this style can be more concise, layered, and easier to implement mechanisms such as caching.

[0035] The Hypertext Transfer Protocol (HTTP) is a simple request-response protocol that specifies what messages a client can send to a server and what responses it can receive.

[0036] Microservices architecture is an architectural pattern that advocates dividing a monolithic application into a set of small services that coordinate and cooperate with each other to provide end-user value. Microservices architecture is actually developed using distributed systems, splitting applications into modules to enable rapid development and deployment of multiple applications. In microservices architecture, each service runs in its own independent process, and services communicate with each other using lightweight communication mechanisms (typically RESTful APIs based on the HTTP protocol). Microservices architecture solves the development efficiency and scalability problems of monolithic architecture, facilitating collaborative development among applications, and allowing the number of services to be dynamically adjusted according to actual access volume, thus possessing high scalability.

[0037] In a microservice architecture, many services need to be called to complete a function. Service calls are generally implemented through API interfaces. Internal APIs are private APIs, while APIs exposed for consumers to use are open APIs. Service calls in a microservice system are implemented by calling open APIs. To better manage the registration, subscription, and invocation of microservices between consumers and services, there is usually an interface management system and a service registration management system. These systems manage the exposed interfaces and services, as well as the calls between consumers and services. Figure 1 As shown, the OpenAPI call management process is as follows:

[0038] The application interconnection component includes functions such as service registration, service discovery, load balancing, API calls, API self-description, and circuit breaking. Both service providers and service consumers need to embed the application interconnection component into their own systems. Service consumers access the OpenAPI of the service providers they have subscribed to through the application interconnection component.

[0039] The API management system is responsible for the registration and subscription management of APIs.

[0040] The microservice registry center includes a management module and a registration module, providing functions such as node connection management for microservice instances and display of service registration information.

[0041] A distributed configuration center enables remote control and real-time application of configuration parameters for application systems.

[0042] exist Figure 1 The following is an explanation of each step in the OpenAPI call management process:

[0043] ① Microservice providers register microservice transaction interface information in the interface management system, including registering microservice information, transaction information, and interface information, and publishing the interface after interface verification.

[0044] ② The microservice consumer applies for interface subscription in the interface management system.

[0045] ③ The interface management system sends the control rules (transaction information, interface information, microservice application information, subscription relationships, etc.) to the microservice registry center, which then converts the microservice control rules into interface control configurations for each application.

[0046] ④ The microservice registry management terminal calls the configuration center API to upload the interface control configuration information to the distributed configuration center for updating.

[0047] ⑤ After approval by the distributed configuration center, the configuration is pushed to each node of the designated microservice consumer for canary configuration update or full node configuration update, thus completing the configuration distribution of interface management data and realizing the configuration push of interface management information.

[0048] After completing the development of the service-side interface and consumer-side calls, as well as the aforementioned registration and configuration, the service-side interface call tests are simultaneously implemented through the corresponding functional tests on the consumer side. OpenAPI call testing differs from the interface testing of the OpenAPI itself. Interface testing directly accesses the interface by sending requests and determines whether the returned content matches the expected result. OpenAPI call testing, however, verifies whether the OpenAPI interface can be called normally through consumer calls. Call testing also verifies whether the subscription and configuration information of the entire call chain from consumer to service is correct. Generally, only one positive test case needs to be executed to verify the normal operation of the call interface and the call chain.

[0049] In related technologies, testing microservice API calls primarily involves testing the service-side API calls synchronously after the consumer-side functionality is developed. While this method provides test results for the service-side API calls, in actual microservice use, situations often arise where the service-side API is completed before the consumer-side API is developed. This leads to the service-side API not being invoked in a timely manner, hindering the development and application of microservice architectures.

[0050] Therefore, embodiments of this application provide a method and related apparatus for testing interface calls in microservices, which can realize automatic call testing of interfaces in microservices.

[0051] The following describes a method embodiment for testing interface calls applied to microservices provided in this application. Figure 2 As shown, Figure 2 A flowchart illustrating an interface call testing method for microservices provided in this application embodiment, the method comprising:

[0052] S201. Based on the target interface code, obtain the target interface parameter document of the target interface. The target interface is used to represent the transaction interface to be tested provided by the interface provider in the microservice. The interface provider is used to represent the application system that provides the transaction interface in the microservice.

[0053] An interface provider, also known as an interface service provider, refers to an application system that provides transaction interfaces to the outside world in a microservice. It can be simply referred to as a service provider or provider.

[0054] The target interface refers to the transaction interface to be tested provided by the interface provider in the microservice. It is usually an open interface, that is, the website service provider encapsulates its website service into a series of interfaces and exposes them to third-party developers. The target interface is also the object to be called for testing in this application.

[0055] To test the call to the target interface, it is necessary to obtain the target interface parameter document. In actual use, by sorting out the interface parameters in the target interface code, as well as the actual input parameter relationships and values, an interface parameter document can be formed, which serves as the input for subsequent steps S202 and S203.

[0056] It should be noted that the actual input parameter relationships need to be set according to the specific circumstances of the target interface to be tested.

[0057] When the target interface uses the HTTP protocol for message transmission, a typical HTTP request message mainly consists of several parts: Request type, Request URL, Request headers, Request params, and Request body. Furthermore, the Request type, Request URL, and Request headers of the target interface can be customized as needed during subsequent call testing. Therefore, it is mainly necessary to focus on the Request params and Request body parameters of the target interface. Usually, the parameter types of Request params are regular variable types, which can be directly read from the target interface code. However, the parameters of the Request body are generally custom class objects, and it is necessary to sort out the actual input parameters of the class objects in advance.

[0058] This application can provide a simple input parameter document format, such as Figure 3 As shown.

[0059] Figure 3 The first column is the interface name of the target interface. The second and third columns are the input parameter types and corresponding parameter names of the interface functions in the target interface code. The first three columns can be directly taken from the target interface code. The fourth and fifth columns are the member variable types and member names corresponding to the required fields contained in the custom class object. Figure 3 The second column, UserQuery, is a custom class variable type containing multiple member variables. Since only the orgCode variable needs to be entered in actual use, the fourth and fifth columns of the table list the orgCode variables of type String. The sixth column is the variable value, which is used to populate the data for subsequent interface call tests. This column can also be empty and will be filled in when the interface call test is executed.

[0060] S202. Based on the target interface code and target interface parameter document, automatically generate the target test interface code. The target test interface code is used to represent the simulated interface code corresponding to the interface consumer. The interface consumer is used to represent the application system in the microservice that calls the transaction interface.

[0061] In practice, it often happens that the service provider's interface has been developed, but the consumer has not been developed simultaneously or there is no consumer subscription at the moment. In this case, in order to test the call of the service provider's interface, the consumer can be simulated by testing the interface code. Then, the service provider's interface can be verified to be called normally by executing the test code. Considering that it is highly demanding for testers to write the test interface code and test code themselves, and that testers who actually perform testing work generally have weak or no coding skills, this application automatically generates the target test interface code based on the target interface code and target interface parameter documentation.

[0062] After the target interface parameter document of the target interface is determined in S201, the actual input parameter variables of the class object can be obtained. Combined with the target interface code, the target test interface code corresponding to the interface consumer can be automatically generated so that the simulation of the interface consumer can be realized in subsequent steps based on the target test interface code.

[0063] In some embodiments, the method for automatically generating target test interface code based on target interface code and target interface parameter documentation includes:

[0064] Based on the target interface code and target interface parameter documentation, the target test interface code is automatically generated according to preset rules.

[0065] The preset rules can be the corresponding rules summarized and refined from the process of writing the test interface code in the early stage. Based on the target interface code and the target interface parameter document, the target test interface code can be automatically generated according to the preset rules.

[0066] It should be noted that test interface code based on preset rules can be automatically generated using various programming languages.

[0067] In some embodiments, the method for automatically generating target test interface code according to preset rules based on target interface code and target interface parameter documentation includes:

[0068] Based on the target interface code and target interface parameter documentation, the target test interface code is automatically generated in the Spring Boot project according to preset rules.

[0069] Specifically, automatically generating target test interface code in a Spring Boot project according to preset rules includes the following steps:

[0070] Step 1: Obtain the input statements from the target API code. For example, if the target API code's corresponding document name is UserInfoAPI.java, a target test API code document TestUserInfoAPI.java can be automatically created based on the target API code. All import statements for imported JAR files in the header of the target API code can be automatically read and written into the target test API code document TestUserInfoAPI.java. Below are all the import statements in the header of UserInfoAPI.java:

[0071] "import java.util.List;

[0072] import javax.servlet.http.HttpServletRequest;

[0073] import org.springframework.stereotype.Component;

[0074] import org.springframework.web.bind.annotation.RequestBody;

[0075] import org.springframework.web.bind.annotation.RequestParam;

[0076] import com.abchina.air.accm.annotation.ApiClient;

[0077] import com.abchina.air.accm.annotation.ApiMapping;

[0078] import com.abchina.alpaca.air.dto.BaseVO;

[0079] import com.abchina.alpaca.air.dto.UserVO;

[0080] import com.abchina.alpaca.air.dto.OrgDomainExt;

[0081] import com.abchina.alpaca.air.dto.OperandVO;

[0082] import com.abchina.alpaca.air.dto.OrgQuery;

[0083] import com.abchina.alpaca.air.dto.OrgVO;

[0084] import com.abchina.alpaca.air.dto.ResourceVO;

[0085] import com.abchina.alpaca.air.dto.RoleVO;

[0086] import com.abchina.alpaca.air.dto.UserBriefVO;

[0087] import com.abchina.alpaca.air.dto.UserExtVO;

[0088] import com.abchina.alpaca.air.dto.UserQuery;

[0089] import com.abchina.alpaca.air.dto.UserRoleVO;

[0090] import com.abchina.taihang.framework.api.pojo.vo.AbstractVO;

[0091] import net.sf.json.JSONObject;”

[0092] Step 2: Write the statements for the fixed request types that need to be imported into the target test interface code documentation. This step is mainly to reduce the workload of subsequent debugging. Import commonly used JAR packages into the test class. The import statements here can be added as needed. For example, the following statements can be added:

[0093] "import org.springframework.web.bind.annotation.RestController;

[0094] import org.springframework.web.bind.annotation.RequestMapping;

[0095] import org.springframework.web.bind.annotation.RequestMethod;

[0096] import org.springframework.web.bind.annotation.ResponseBody;

[0097] import org.springframework.web.bind.annotation.RequestParam;

[0098] import org.springframework.beans.factory.annotation.Autowired;”

[0099] Step 3: Import the API call path in the microservice architecture. For example, when testing the target API defined in UserInfoAPI.java in the alpaca project, add "import com.abchina.alpaca.air.api.UserInfoAPI;" to the target test API code documentation. The API call path can be provided by the API provider as input for automatically generating the target test API code.

[0100] Step 4: Create test classes and annotations based on certain rules. The class name, access path, and private variables are automatically generated according to certain rules based on the target interface. The generated class structure is as follows:

[0101] @RestController

[0102] @RequestMapping(value=" / rest / testUserInfoAPI / ") / / Defines the target test interface access path

[0103] public class TestUserInfoAPI{

[0104] @Autowird

[0105] Private UserInfoAPI userInfoAPI; / / Defines the target interface class object for subsequent calls.

[0106] }

[0107] Step 5: Automatically generate the corresponding target test interface function based on the target interface function and target interface parameter documentation in the target interface code.

[0108] Based on the target interface code and target interface parameter documentation, determine whether the target test interface function's input parameters include class variables, and then select the appropriate test interface function template. Test interface functions that do not contain class variables use... Figure 4 Function template 1 includes the use of class variables. Figure 4 In function template 2, the return type and function name of the test interface function are directly obtained from the target interface code.

[0109] Taking the target interface `findUsersByOrgRecursive` in `UserInfoAPI` as an example, the return type and function name of the target test interface code are directly taken from the target interface code. The HTTP request method type of the target test interface code is uniformly set to `GET`. The parameters of the target test interface are uniformly annotated with `@RequestParam`. Regular type parameters are directly taken from the target interface code, and class type parameters are replaced with actual input parameters according to the target interface parameter documentation obtained in step S101. Since this target interface contains class type input parameters, function template 2 is used. Non-class type parameters are directly referenced, and class type parameters are first defined as class objects, assigned values, and then referenced. The function of the interface under test is called through the interface class object and the result is returned.

[0110] By following the steps above, the target test interface code can be automatically generated based on the target interface code and the target interface parameter document, so that the corresponding target test script can be generated subsequently.

[0111] S203. Based on the target test interface code and target interface parameter document, automatically generate the target test script.

[0112] Since relying on testers to write target test scripts places high demands on testers, the target test script can be automatically generated after the target test interface code generated in S202 is combined with the parameter values ​​in the target interface parameter document obtained in S201.

[0113] In some embodiments, the method for automatically generating a target test script based on the target test interface code and the target interface parameter document includes:

[0114] Based on the target test interface code, automatically obtain the target access path, target request method, target interface name, and target interface input parameters of the target interface;

[0115] Based on the target interface name and target interface input parameters, automatically obtain the target input parameter values ​​corresponding to the target interface from the target interface parameter document;

[0116] The target test script is automatically generated based on the target access path, target request method, target interface name, and target input parameter values.

[0117] like Figure 5 As shown, the target access path, target request method, target interface name, and target input parameters are obtained from the target test interface code. These are then written into the test request for each target interface in sequence. Combined with the parameter values ​​in the target interface parameter document, the corresponding input parameter values ​​for each target interface are written to obtain the target test script.

[0118] For example, when Postman is used as the API call tool, the automatically generated Postman import can be in JSON file format, with a single parameter defined as follows:

[0119]

[0120]

[0121] A single HTTP request looks like this:

[0122]

[0123]

[0124] The target test script includes multiple requests. In each request, the `id` must correspond to the `order` parameter value list in the collection. The target API name is obtained from the target test API code and assigned to `name`, the target request method is assigned to `method`, the target request path is concatenated and assigned to `url`, and the target API input parameters are assigned to `queryParams`. The remaining parameter values ​​can be left as default. The above are the generation rules for a single request; multiple requests can be generated sequentially according to the rules for a single request.

[0125] S204. Use an interface testing tool to execute the target test script and obtain the test results of the target interface.

[0126] Place the target test interface code generated in step S202 into the local test project, add configuration information, and add the annotation of the project package where the target interface is located in the startup class. Then start the local test project, import the target test script generated in step S203 through the interface testing tool, and use the interface testing tool to initiate the call test of the target interface to obtain the test results of the target interface.

[0127] It should be noted that there are many types of interface testing tools. The Postman tool mentioned in this application can also be replaced by tools such as JMeter and Fiddler, which can achieve the same function of sending requests for testing.

[0128] In summary, this application provides a method for testing interface calls in microservices. The method includes: obtaining a target interface parameter document based on the target interface code of the target interface, where the target interface represents a transaction interface to be tested provided by an interface provider in the microservice, and the interface provider represents the application system providing the transaction interface in the microservice; automatically generating target test interface code based on the target interface code and the target interface parameter document, where the target test interface code represents the simulated interface code corresponding to the interface consumer, and the interface consumer represents the application system calling the transaction interface in the microservice; automatically generating a target test script based on the target test interface code and the target interface parameter document; and executing the target test script using an interface testing tool to obtain the test results of the target interface. This method can automatically generate the target test interface code and the corresponding target test script, enabling call testing of the target interface corresponding to the interface provider even when there is no interface consumer.

[0129] The following describes an embodiment of an interface call testing device for microservices provided in this application. Figure 6 As shown, Figure 6 This application provides a schematic diagram of an interface call testing device for microservices, which includes:

[0130] The acquisition unit 601 is used to obtain the target interface parameter document of the target interface based on the target interface code of the target interface. The target interface is used to represent the transaction interface to be tested provided by the interface provider in the microservice. The interface provider is used to represent the application system that provides the transaction interface in the microservice.

[0131] The first generation unit 602 is used to automatically generate target test interface code based on the target interface code and the target interface parameter document. The target test interface code is used to represent the simulated interface code corresponding to the interface consumer. The interface consumer is used to represent the application system in the microservice that calls the transaction interface.

[0132] The second generation unit 603 is used to automatically generate the target test script based on the target test interface code and the target interface parameter document;

[0133] Test unit 604 is used to execute the target test script using an interface testing tool to obtain the test results of the target interface.

[0134] In some embodiments, the first generation unit 602 is used to automatically generate target test interface code according to preset rules based on the target interface code and the target interface parameter document.

[0135] In some embodiments, the first generation unit 602 is used to automatically generate target test interface code in a Spring Boot project according to preset rules based on the target interface code and the target interface parameter document.

[0136] In some embodiments, the second generation unit 603 is configured to automatically obtain the target access path, target request method, target interface name, and target interface input parameters of the target interface based on the target test interface code; automatically obtain the target input parameter values ​​corresponding to the target interface from the target interface parameter document based on the target interface name and target interface input parameters; and automatically generate the target test script based on the target access path, target request method, target interface name, and target input parameter values.

[0137] It should be noted that the specific working process of each module provided in the above embodiments of this application can be referred to the corresponding implementation methods in the above method embodiments, and will not be repeated here.

[0138] Another embodiment of this application provides an electronic device, including:

[0139] Memory, used to store executable instructions;

[0140] A processor, when executing executable instructions stored in memory, implements the method described in the embodiments of this application.

[0141] Another embodiment of this application provides a computer-readable storage medium storing executable instructions for implementing the methods described above in the embodiments of this application when executed by a processor.

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

[0143] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An interface call test method applied to microservices, characterized in that, The method comprises: obtaining a target interface parameter document of a target interface based on a target interface code of the target interface, the target interface being used to represent a to-be-tested transaction interface provided by an interface provider in the microservice, the interface provider being used to represent an application system in the microservice that provides a transaction interface; generating a target test interface code automatically according to the target interface code and the target interface parameter document, the target test interface code being used to represent a simulation interface code corresponding to an interface consumer, the interface consumer being used to represent an application system in the microservice that calls a transaction interface; generating a target test script automatically according to the target test interface code and the target interface parameter document; executing the target test script by using an interface test tool to obtain a test result of the target interface.

2. The method of claim 1, wherein, The generating a target test interface code automatically according to the target interface code and the target interface parameter document comprises: generating a target test interface code automatically according to the target interface code and the target interface parameter document according to a preset rule.

3. The method of claim 2, wherein, The generating a target test interface code automatically according to the target interface code and the target interface parameter document according to a preset rule comprises: generating a target test interface code automatically according to the target interface code and the target interface parameter document in a Spring boot project according to a preset rule.

4. The method of claim 1, wherein, The generating a target test script automatically according to the target test interface code and the target interface parameter document comprises: obtaining a target access path, a target request mode, a target interface name and a target interface input parameter of the target interface automatically according to the target test interface code; obtaining a target input parameter value corresponding to the target interface from the target interface parameter document automatically according to the target interface name and the target interface input parameter; generating a target test script automatically according to the target access path, the target request mode, the target interface name and the target input parameter value.

5. An interface call testing apparatus applied to microservices, characterized by, The device comprises: an obtaining unit configured to obtain a target interface parameter document of a target interface based on a target interface code of the target interface, the target interface being used to represent a to-be-tested transaction interface provided by an interface provider in the microservice, the interface provider being used to represent an application system in the microservice that provides a transaction interface; a first generating unit configured to generate a target test interface code automatically according to the target interface code and the target interface parameter document, the target test interface code being used to represent a simulation interface code corresponding to an interface consumer, the interface consumer being used to represent an application system in the microservice that calls a transaction interface; a second generating unit configured to generate a target test script automatically according to the target test interface code and the target interface parameter document; a testing unit configured to execute the target test script by using an interface test tool to obtain a test result of the target interface.

6. The apparatus of claim 5, wherein, The first generating unit is configured to generate a target test interface code automatically according to the target interface code and the target interface parameter document according to a preset rule.

7. The apparatus of claim 6, wherein, The first generation unit is configured to automatically generate target test interface code in a Spring boot project according to the target interface code and the target interface parameter document and in accordance with a preset rule.

8. The apparatus of claim 5, wherein, The second generation unit is configured to automatically obtain a target access path, a target request mode, a target interface name and target interface input parameters of the target interface according to the target test interface code. According to the target interface name and the target interface input parameters, the target input parameter values corresponding to the target interface are automatically obtained from the target interface parameter document; and a target test script is automatically generated according to the target access path, the target request mode, the target interface name and the target input parameter values.

9. An electronic device, comprising: Comprise: A memory for storing executable instructions; A processor for executing the executable instructions stored in the memory, realizing the interface call test method for microservices in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, Executable instructions are stored for being executed by the processor, realizing the interface call test method for microservices in any one of claims 1 to 4.

Images