Micro-service testing method, system and device, equipment and program product

Abstract

The invention relates to a micro-service testing method, system and device, electronic equipment and a computer program product, relates to the technical field of software testing, and can be applied to a unit testing scene based on a micro-service architecture. The method comprises the following steps: acquiring a service test demand, and generating a service calling request based on the service test demand and a predefined service contract; obtaining a target test pile from a service storage position based on the service calling request, wherein the service storage position is used for storing a service test pile newly published by a service provider; and performing integrated test operation according to the target test pile. According to the method, the contract between the services is taken as a core, the problem of dependency coupling existing in a traditional unit test is solved, and the response speed and flexibility of API updating are remarkably improved.

Description

Technical Field

[0001] The present disclosure relates to the field of software testing technology, and in particular to a microservice testing method, a microservice testing system, a microservice testing device, an electronic device, and a computer program product. Background Art

[0002] Unit testing is a key part of the software development lifecycle, which helps improve the reliability, maintainability and overall quality of the software. Unit tests are particularly important in the microservices architecture because they help developers understand and trust the behavior of individual services while providing assurance when services are deployed and scaled independently. The implementation of unit testing in software development using a microservices architecture undoubtedly adds a lot of challenges, especially when service components are closely connected and deployed on complex container orchestration systems such as Kubernetes (k8s).

[0003] For example, in a microservice architecture, there may be complex dependencies between different service components. These dependencies need to be simulated during unit testing to ensure the integrity and accuracy of the test. This requires writing a large number of mock objects or stub codes to simulate these dependencies, which increases the complexity and tediousness of the test. At the same time, in container orchestration systems such as Kubernetes, the deployment and management of services are more complex and may involve interactions between multiple containers and services. When performing unit testing, it is necessary to consider the interactions between these containers and ensure that the test environment is built and deployed correctly, which increases the difficulty and tediousness of the test.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] The purpose of the present disclosure is to provide a microservice testing method, a microservice testing system, a microservice testing device, an electronic device, a computer-readable storage medium, and a computer program product, thereby at least to some extent overcoming the problems of the existing unit testing solutions for microservice architectures, such as delayed API updates and dependency coupling between services.

[0006] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by the practice of the present invention.

[0007] According to a first aspect of the present disclosure, a microservice testing method is provided, including: obtaining service testing requirements, generating a service call request based on the service testing requirements and a predefined service contract; obtaining a target test stub from a service storage location based on the service call request, the service storage location being used to store the service test stub most recently released by a service provider; and performing an integrated testing operation according to the target test stub.

[0008] In an exemplary embodiment of the present disclosure, generating a service call request based on the service testing requirement and a predefined service contract includes: obtaining the service contract, the service contract is generated by a service testing tool based on service contract structure information, the service contract structure information includes one or more of a request structure, a response structure, service parameters and a status code; determining test environment information based on the service testing requirement; generating the service call request according to the test environment information and the service contract.

[0009] In an exemplary embodiment of the present disclosure, generating the service call request according to the test environment information and the service contract includes: determining a target request service according to the service test requirements, the target request service including a target service name and a target cluster domain where the target request service is located; generating an initial service request address based on the target service name and the target cluster domain; generating port configuration information corresponding to the test environment information, and generating the service call request according to the port configuration information and the initial service request address.

[0010] In an exemplary embodiment of the present disclosure, the generating of the initial service request address based on the target service name and the target cluster domain includes: taking the cluster domain where the current service is located as the current cluster domain; obtaining a predefined service request address format, wherein the service request address format includes a same-domain identifier; when the current cluster domain and the target cluster domain are the same cluster domain, omitting the same-domain identifier, and generating the initial service request address based on the target service name; when the current cluster domain and the target cluster domain are not the same cluster domain, determining the target domain name of the target cluster domain; generating the initial service request address based on the target service name and the target domain name.

[0011] In an exemplary embodiment of the present disclosure, the service call request includes a target service name, and obtaining a target test pile from a service storage location based on the service call request includes: establishing a communication connection with the service storage location based on the service call request; determining the target test pile from a plurality of the service test piles according to the target service name, and storing the obtained target test pile locally.

[0012] According to a second aspect of the present disclosure, a microservice testing method is provided, including: determining service contract structure information between multiple services, and generating a service contract based on the service contract structure information; generating and publishing a service test stub based on the service contract, and the service test stub is used to provide to a service consumer to perform a test operation.

[0013] In an exemplary embodiment of the present disclosure, the determining of service contract structure information between multiple services and generating a service contract based on the service contract structure information include: determining the service contract structure information according to request response requirements between the multiple services, the service contract structure information including one or more of a request structure, a response structure, service parameters and a status code; and generating the service contract based on the service contract structure information by a service testing tool.

[0014] In an exemplary embodiment of the present disclosure, generating and publishing a service test stub based on the service contract includes: determining a response service provided by a service provider; generating the service test stub according to the response service and the service contract; and publishing the service test stub to a service storage location through a service deployment tool, wherein the service storage location includes one or more of a service storage warehouse, a service registration center, and a centralized storage location.

[0015] In an exemplary embodiment of the present disclosure, generating the service test stub according to the response service and the service contract includes: determining response service information corresponding to the response service, the response service information including one or more of a response service name and a domain cluster name where the response service is located; determining a response service path corresponding to the response service according to the response service name and the domain cluster name; and generating the service test stub based on the response service path.

[0016] According to a third aspect of the present disclosure, a testing system for microservices is provided, including: a service provider, used to determine service contract structure information between multiple services, generate a service contract based on the service contract structure information, and generate and publish service test stubs based on the service contract; a service storage location, used to store the service test stubs published by the service provider; a service consumer, used to generate a service call request according to service testing requirements and the service contract, obtain a target test stub from the service storage location according to the service call request, and the target test stub is used to perform an integration test operation.

[0017] According to a fourth aspect of the present disclosure, a testing device for a microservice is provided, including: a service request generation module, used to obtain service test requirements, and generate a service call request based on the service test requirements and a predefined service contract; a test pile acquisition module, used to obtain a target test pile from a service storage location based on the service call request, and the service storage location is used to store the service test piles newly released by the service provider; an integration test module, used to perform integration test operations according to the target test pile.

[0018] In an exemplary embodiment of the present disclosure, the service request generation module includes a service call request generation unit, which is used to: obtain the service contract, the service contract is generated by a service testing tool based on service contract structure information, the service contract structure information includes one or more of a request structure, a response structure, service parameters and a status code; determine the test environment information based on the service testing requirements; and generate the service call request according to the test environment information and the service contract.

[0019] In an exemplary embodiment of the present disclosure, the service call request generation unit includes a service call request generation sub-unit, which is used to: determine the target request service according to the service test requirements, the target request service including the target service name and the target cluster domain where the target request service is located; generate an initial service request address based on the target service name and the target cluster domain; generate port configuration information corresponding to the test environment information, and generate the service call request according to the port configuration information and the initial service request address.

[0020] In an exemplary embodiment of the present disclosure, the service call request generation subunit includes an initial address generation subunit, which is used to: take the cluster domain where the current service is located as the current cluster domain; obtain a predefined service request address format, and the service request address format includes a same-domain identifier; when the current cluster domain and the target cluster domain are the same cluster domain, omit the same-domain identifier, and generate the initial service request address based on the target service name; when the current cluster domain and the target cluster domain are not the same cluster domain, determine the target domain name of the target cluster domain; generate the initial service request address based on the target service name and the target domain name.

[0021] In an exemplary embodiment of the present disclosure, the service call request includes a target service name, and the test pile acquisition module includes a test pile acquisition unit, which is used to: establish a communication connection with the service storage location based on the service call request; determine the target test pile from multiple service test piles according to the target service name, and store the acquired target test pile locally.

[0022] According to a fifth aspect of the present disclosure, a testing device for microservices is provided, including: a consensus file generation module, used to determine service contract structure information between multiple services, and generate a service contract based on the service contract structure information; a test stub publishing module, used to generate and publish service test stubs based on the service contract, and the service test stubs are used to be provided to service consumers to perform test operations.

[0023] In an exemplary embodiment of the present disclosure, the consensus file generation module includes a consensus file generation unit, which is used to: determine the service contract structure information according to the request response requirements between the multiple services, and the service contract structure information includes one or more of a request structure, a response structure, service parameters and a status code; and generate the service contract based on the service contract structure information by a service testing tool.

[0024] In an exemplary embodiment of the present disclosure, the test pile publishing module includes a test pile publishing unit, which is used to: determine the response service provided by the service provider; generate the service test pile according to the response service and the service contract; and publish the service test pile to a service storage location through a service deployment tool, and the service storage location includes one or more of a service storage warehouse, a service registration center, and a centralized storage location.

[0025] In an exemplary embodiment of the present disclosure, the test pile publishing unit includes a test pile generating subunit, which is used to: determine response service information corresponding to the response service, the response service information including one or more of a response service name and a domain cluster name where the response service is located; determine a response service path corresponding to the response service based on the response service name and the domain cluster name; and generate the service test pile based on the response service path.

[0026] According to a sixth aspect of the present disclosure, there is provided an electronic device, comprising: a processor; and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, a testing method for a microservice according to any one of the above items is implemented.

[0027] According to a seventh aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the testing method of the microservice according to any one of the above items is implemented.

[0028] According to an eighth aspect of the present disclosure, a computer program product is provided, including a computer program, which implements any one of the above-described microservice testing methods when executed by a processor.

[0029] The technical solution provided by the present disclosure may have the following beneficial effects:

[0030] The testing method of microservices in the exemplary embodiment of the present disclosure, on the one hand, ensures the consistency and correctness of the service interface during the test process by clarifying the service contract between the two service parties, and can effectively solve the dependency coupling problem between services. On the other hand, since the service storage location stores the latest released service test stubs, once the service API changes, the relevant unit tests can be updated immediately to ensure that all services can quickly adapt to the new API specifications, significantly improving the response speed and flexibility of API updates.

[0031] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present disclosure, and together with the specification, are used to explain the principles of the present disclosure. Obviously, the drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0033] Figure 1 A flowchart schematically illustrates a method for testing a microservice according to an exemplary embodiment of the present disclosure;

[0034] Figure 2 A flowchart of a contract-based unit test according to an exemplary embodiment of the present disclosure is schematically shown;

[0035] Figure 3 A schematic diagram schematically illustrates a service discovery and communication process according to an exemplary embodiment of the present disclosure;

[0036] Figure 4 A flowchart schematically illustrates a method for testing a microservice according to another exemplary embodiment of the present disclosure;

[0037] Figure 5 A block diagram schematically shows a microservice testing device according to an exemplary embodiment of the present disclosure;

[0038] Figure 6 A block diagram schematically shows a microservice testing device according to another exemplary embodiment of the present disclosure;

[0039] Figure 7 A schematic diagram schematically illustrates a computer-readable storage medium according to an exemplary embodiment of the present disclosure;

[0040] Figure 8A block diagram of an electronic device according to an exemplary embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0041] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be comprehensive and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The same reference numerals in the figures represent the same or similar parts, and thus their repeated description will be omitted.

[0042] In addition, the described features, structures or characteristics may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure may be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. may be adopted. In other cases, known structures, methods, devices, implementations, materials or operations are not shown or described in detail to avoid blurring the various aspects of the present disclosure.

[0043] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or these functional entities or parts of functional entities may be implemented in one or more software hardened modules, or these functional entities may be implemented in different networks and / or processor devices and / or microcontroller devices.

[0044] In a microservice architecture, communication between services is usually implemented through Hypertext Transfer Protocol (HTTP) or other network protocols, which requires developers to simulate and control the interaction between these services in order to perform effective unit testing and integration testing. In a microservice architecture, it is a common practice to use a mock server (MockServer) for joint debugging and unit testing, which allows developers to simulate real server behavior in a test environment and control the flow of requests and responses.

[0045] However, the above solution has the following problems: (1) Application Programming Interface (API) updates lag behind. When the backend service is updated but the MockServer simulation is not synchronized in time, the test case may be inconsistent with the actual API behavior. This will make the test results unreliable and even mislead developers.

[0046] (2) Dependency issues. There are complex dependencies between services in a microservice architecture. When using MockServer, you need to ensure that all dependent services are properly simulated, which is particularly difficult when service dependencies are serious. In addition, network factors, team online time, and changes in environment configuration may affect the accuracy and stability of MockServer.

[0047] (3) Impact of environmental changes. The behavior of services may vary in different development, test, and production environments. If MockServer fails to accurately simulate these environmental differences, the test results may not truly reflect the performance of the service in actual operation.

[0048] (4) Limitations of static data simulation. MockServer usually uses static data to simulate responses. Although this method is simple, it may not fully simulate dynamic data changes in the real environment. Therefore, the test cases may not cover all possible data scenarios, resulting in insufficient test coverage.

[0049] Based on this, according to an embodiment of the present disclosure, a microservice testing method, a microservice testing system, a microservice testing device, an electronic device, a computer-readable storage medium, and a computer program product are proposed.

[0050] In this article, it is important to understand that the terms involved are, Parallel development: is a software development approach that allows multiple development teams or individuals to work on different parts of the same project at the same time.

[0051] Microservices: A software architecture style that builds a large, complex application into a set of small, independent services, each of which implements a specific business function and can be independently developed, deployed, run, and scaled.

[0052] Unit testing: is a testing method in the software development process that aims to verify the correctness of the smallest testable part of the software (usually a function or method). The purpose of unit testing is to isolate a small part of the code and ensure that this part of the code works as expected under various input conditions.

[0053] Contract testing: is a software testing method that focuses on verifying whether the interaction between system components conforms to pre-defined contracts. These contracts usually include interface specifications, data formats, behavioral conventions, etc., which define how components communicate and the expected behavior.

[0054] Kubernetes: is an open source container orchestration platform for automating the deployment, scaling, and management of containerized applications.

[0055] Service: In Kubernetes (K8s), Service is an abstract concept that is used to define a logical collection of Pods (container groups) with the same functions, and can provide external access through defined network endpoints.

[0056] In this example embodiment, a microservice testing method is first provided, which is applied to service consumers, also known as service requesters, service users, etc. The microservice testing method of the present disclosure can be implemented using a server, or the method described in the present disclosure can be implemented using a terminal device, wherein the terminals described in the present disclosure may include mobile terminals such as mobile phones, tablet computers, laptops, PDAs, personal digital assistants (PDAs), and fixed terminals such as desktop computers. Figure 1 The following is a schematic diagram of a microservice testing method flow according to some embodiments of the present disclosure. Figure 1 , the testing method of the microservice can include the following steps:

[0057] Step S110, obtaining service test requirements, and generating a service call request based on the service test requirements and a predefined service contract.

[0058] According to some exemplary embodiments of the present disclosure, a service test requirement may be a test requirement currently initiated by a service consumer. A service consumer may be a party that initiates a service call request. A service contract may be a service contract adopted between a service consumer and a service provider. A service contract is a collection of a set of related service operations. When a service contract attribute class (ServiceContractAttribute class) is applied to an interface, the attributes of the service contract are given. A service call request, also known as a service request, may be a call request initiated by a service consumer to a service provider based on a service test requirement. In a microservice testing method, a service test requirement may be a test requirement for a microservice, a service contract may be a service contract adopted between a service consumer and a service provider of a microservice, and a service call request may be a call request for a microservice.

[0059] For microservice architecture, independence and rapid iteration between services are its core advantages. However, as the number of services increases, the complexity of unit testing also increases. Existing unit testing methods become difficult to maintain due to the tight coupling between services. At the same time, API updates usually need to wait for the coordination of all related services, which leads to delayed updates and reduced development efficiency.

[0060] In view of the above problems, the present disclosure proposes a clearly defined service-to-service contract, so that each microservice can be tested independently without relying on other services. First, determine the contract definition. In the microservice call, the service provider and the service user (service consumer) need to jointly define the contract between the microservices.

[0061] After obtaining the service test requirements of the service requester, a pre-defined service contract is used as a template, a corresponding service call request is generated according to the service test requirements and the service contract, and the corresponding service is called or downloaded based on the service call request.

[0062] Step S120, obtaining a target test stub from a service storage location based on a service call request, where the service storage location is used to store the service test stub most recently released by the service provider.

[0063] According to some exemplary embodiments of the present disclosure, the service storage location may be a storage location of a service test pile, and the service provider deploys the generated service test pile at the above location. The target test pile may be a service test pile required in a service call request initiated by a service consumer. The service test pile may be a test pile code provided in advance by the service provider. The pile code may be used to simulate components or services required during the test process.

[0064] A service provider can include one or more service providers. In a parallel development microservice architecture, multiple service providers can publish the latest version of service test stubs in the service storage location, so that the service storage location always stores the latest stub code. Service consumers can obtain matching target test stubs from the service storage location based on service call requests.

[0065] Step S130: performing an integrated test operation according to the target test stub.

[0066] According to some exemplary embodiments of the present disclosure, an integrated test operation, also called an assembly test or a joint test, refers to a joint test operation performed on the entire link based on multiple microservice modules included in a program.

[0067] After obtaining the target test stub, the service consumer can perform integration testing operations based on the target test stub to determine whether the contract rules defined by both parties are met. For multiple microservice modules, all test units obtain the target test stubs required this time and jointly test the entire program link.

[0068] According to the testing method of microservices in this example embodiment, on the one hand, by clarifying the service contract between the two service parties, the consistency and correctness of the service interface during the test process are ensured, which can effectively solve the dependency coupling problem between services. On the other hand, since the service storage location stores the latest released service test stubs, once the service API changes, the relevant unit tests can be updated immediately to ensure that all services can quickly adapt to the new API specifications, significantly improving the response speed and flexibility of API updates.

[0069] Next, the testing method of the microservices in this example embodiment will be further described.

[0070] In an exemplary embodiment of the present disclosure, for step S110, a service call request is generated based on service testing requirements and a predefined service contract, including: obtaining a service contract, where the service contract is generated by a service testing tool based on service contract structure information, where the service contract structure information includes one or more of a request structure, a response structure, service parameters, and a status code; determining test environment information based on service testing requirements; and generating a service call request based on the test environment information and the service contract.

[0071] Among them, the service testing tool can be a tool used to generate a service contract in the testing process based on the microservice architecture. The service contract structure information can be related information such as the data structure contained in the service contract. The test environment information can be related information of the specific environment in which the service consumer is currently located. For example, the environment in which the service consumer is located can include a test environment, a production environment, etc. Different environments have different service configurations.

[0072] For microservice architectures in specific environments, such as microservice architectures developed in parallel in Kubernetes (K8s) environments, in order to solve the dependency coupling problem between services, both parties can define service contracts. The service contracts define detailed specifications for service requests and service responses, including data structures, transmission formats, parameter types, status codes, etc. This helps ensure the stability and predictability of services, and also facilitates service integration and testing.

[0073] Specifically, a service contract usually contains the following information: The request structure can be the data structure corresponding to the service call request, which defines the format of the service request, including but not limited to the HTTP method, uniform resource locator (URL) path, query parameters, request header and request body, etc. The response structure can be the data structure corresponding to the service response, which defines the format of the service response, including but not limited to the status code, response header and response body, etc. The service parameters can be the parameters contained in the service request and service response, which specify the name, type, whether it is required, value range, etc. of each parameter in the service request and service response. The status code can be used to define the various HTTP status codes that the service can return and their meanings.

[0074] Based on the above contract definition, the service provider can use service testing tools, such as Spring CloudContract, to generate the contract implementation code on the server side, for example, to generate the service provider's service contract template. For the generated service contract template, a service test stub can be generated for the service provider. For example, the service test stub can be stored in a specified location using a stubs.jar file, thereby allowing consumers to obtain the service contract from the specified location and perform integration testing locally without calling the actual remote service.

[0075] refer to Figure 2 , Figure 2 The flowchart of the contract-based unit test according to an exemplary embodiment of the present disclosure is schematically shown. The service provider and the service user jointly define the service contract, and the service provider can generate a service test stub based on the service contract, such as service provider 1 generates service test stub 1 based on the service contract, and service provider 2 generates service test stub 2 based on the service contract, and publishes it to a service storage location, such as a Maven warehouse.

[0076] Service consumers can determine the test environment information based on their own service testing needs. Different test environments may correspond to different service configurations. Service consumers can make different service configurations based on the current test environment information, such as port configuration, and generate corresponding service call requests. By pre-defining the service contract, the consistency and correctness of the service interface can be ensured; in addition, each microservice can be tested independently without relying on other services. Developers can focus on the internal logic of their own services without having to wait for updates to other services, which greatly improves development efficiency.

[0077] In an exemplary embodiment of the present disclosure, a service call request is generated according to test environment information and a service contract, including: determining a target request service according to service test requirements, the target request service including a target service name and a target cluster domain where the target request service is located; generating an initial service request address based on the target service name and the target cluster domain; generating port configuration information corresponding to the test environment information, and generating a service call request according to the port configuration information and the initial service request address.

[0078] The target request service may be the service that the service consumer wants to request. The target service name may be the specific name of the target request service. The target cluster domain may be the cluster domain where the target request service is located. The target cluster domain may be in the same cluster domain as the service consumer or in a different cluster domain. The initial service request address may be the service request address that has not been configured for injection. The port configuration information may be the configuration information of the relevant service port under the test environment information.

[0079] When determining the service test requirements required by the service consumer, the target request service can be determined according to the service test requirements, such as determining the specific name (service-name) of the target request service and the target cluster domain (namespace). For example, in a Kubernetes cluster, service discovery and communication are implemented through a specific Domain Name System (DNS) domain name format, and the initial service request address is generated based on the specific DNS domain name format, the target service name, and the target cluster domain.

[0080] In different environments (such as test and production environments), the configuration of services may be different. In order to flexibly deal with such differences, after generating the initial service request address, you can further determine the test environment information corresponding to the service consumer, and use Kubernetes' configuration tool (ConfigMap resource) to inject port configuration to generate service call requests. Through ConfigMap, environment-specific configuration information can be centrally managed and passed to applications in the form of environment variables or command line parameters, allowing services to automatically adjust configurations according to different environments, thereby achieving dynamic configuration injection and seamless switching between environments. This approach not only simplifies configuration management, but also improves the flexibility and portability of applications.

[0081] In an exemplary embodiment of the present disclosure, an initial service request address is generated based on a target service name and a target cluster domain, including: taking the cluster domain where the current service is located as the current cluster domain; obtaining a predefined service request address format, the service request address format including a same-domain identifier; when the current cluster domain and the target cluster domain are the same cluster domain, omitting the same-domain identifier, and generating an initial service request address based on the target service name; when the current cluster domain and the target cluster domain are not the same cluster domain, determining the target domain name of the target cluster domain; generating an initial service request address based on the target service name and the target domain name.

[0082] The current cluster domain may be the cluster domain where the service consumer is currently located. The service request address format may be a predefined unified service address format. The same domain identifier may mean that the required service call request and the service consumer are in the same cluster domain (or the same namespace).

[0083] In a Kubernetes cluster, service discovery and communication are implemented through a specific DNS domain name format. For example, the predefined service request address format can be <service-name> . <namespace>.svc.cluster.local; "svc.cluster.local" can be the same domain identifier in the service request address, which can indicate that the request is for services in the same namespace.

[0084] In particular, if the current cluster domain is the same as the target cluster domain, you can omit <namespace>.svc.cluster.local part, then by default, the service will point to the service object with the same name in the current namespace, which facilitates service communication within the same namespace. It is easy for those skilled in the art to understand that the same domain identifier in the initial service request address can be omitted or not. When the same domain identifier is omitted, the default service will point to the service object with the same name in the current namespace; when the same domain identifier is not omitted, the specific name of the current namespace needs to be specified.

[0085] If the previous cluster domain and the target cluster domain are not the same cluster domain, the target domain name of the target cluster domain is obtained, and the corresponding target service name and target domain name are filled in based on the service request address format to generate the initial service request address. The use of the predefined service request address format can ensure that services can accurately discover and access each other through names.

[0086] In an exemplary embodiment of the present disclosure, a target test pile is obtained from a service storage location based on a service call request, including: establishing a communication connection with the service storage location based on the service call request; determining a target test pile from multiple service test piles according to a target service name, and storing the obtained target test pile locally.

[0087] After generating a service call request, the service consumer can obtain the target test stub based on the service call request. Figure 3 , Figure 3 A schematic diagram schematically shows a service discovery and communication process according to an exemplary embodiment of the present disclosure. Figure 3 Service consumers can use ConfigMap resources for configuration operations and inject the above environment configuration information into the service call request. The service consumer establishes a communication connection between the DNS domain name address contained in the service call request and the corresponding service storage location. For example, the format of "<service name>:${pod-service provider.port}" is used to call a service provided by a service provider through a certain port.

[0088] After the service consumer and service provider establish a communication connection, you can determine the target test pile from multiple service test piles based on the target service name. Figure 3 A service of a service provider can correspond to multiple ports, and a port service can be provided by a container group (pod). If a service of a service provider points to multiple container groups, the service test stubs in different container groups are called.

[0089] Continue to refer Figure 2 , multiple service providers can publish service test piles to the service storage location in advance. If the service consumer has a service call request, the target test pile will be obtained from the service storage location (such as Maven warehouse) based on the service call request. For example, the target test piles obtained by the service consumer include service test pile 1 of service provider 1 and service test pile 2 of service provider 2, and they are stored locally as local simulation data (local mock). Service discovery and communication are performed through domain name formats with specific naming rules, which simplifies mutual discovery and access between services; at the same time, it allows service users to use the latest downloaded test piles for local testing without remotely calling service providers, thereby improving testing efficiency and reducing dependencies.

[0090] During the integration testing phase, service providers and service consumers can conduct in-depth testing in the Kubernetes (K8s) integrated environment. For example, the service consumer downloads the latest stubs jar from the Maven private server every time during the contract test; using the downloaded latest stubs test piles, without remotely calling the service provider for testing, to verify whether the contract rules defined by both parties are met.

[0091] In summary, the testing method of the microservice disclosed in the present invention obtains the service test requirements, generates a service call request based on the service test requirements and the predefined service contract; obtains the target test pile from the service storage location based on the service call request, and the service storage location is used to store the service test piles newly released by the service provider; and performs integration test operations according to the target test pile. On the one hand, by clarifying the service contract between the two parties of the service, the consistency and correctness of the service interface during the test process are ensured, and the dependency coupling problem between services can be effectively solved. On the other hand, since the service storage location stores the latest released service test piles, once the service API changes, the relevant unit tests can be updated immediately to ensure that all services can quickly adapt to the new API specifications, significantly improving the response speed and flexibility of API updates. On the other hand, the service discovery and communication method based on the specified domain name format simplifies the mutual discovery and access between services through specific naming rules. On the other hand, a method for centralized management of environment-specific configurations is implemented, which allows services to automatically adjust configurations according to different environments through the combination of ConfigMap and environment variables or command line parameters, without manually changing code or configuration files.

[0092] In some exemplary embodiments of the present disclosure, a microservice testing method is also provided, which is applied to a service provider, also known as a service provider. The microservice testing method of the present disclosure can be implemented using a server, or the method described in the present disclosure can be implemented using a terminal device. Figure 4 The following is a schematic diagram of a microservice testing method flow according to some embodiments of the present disclosure. Figure 4 , the testing method of the microservice can include the following steps:

[0093] Step S410: determining service contract structure information among multiple services, and generating a service contract based on the service contract structure information.

[0094] According to some exemplary embodiments of the present disclosure, similar to service consumers, in order to solve the problem of dependency coupling between multiple services in a microservice architecture, the present disclosure proposes to define a clearly defined service-to-service contract so that each microservice can be tested independently without relying on other services. The service provider and the service user (service consumer) need to jointly define the contract between services.

[0095] First, determine the information contained in the service contract and the corresponding data structure. For example, a service contract usually contains the following information: data structure, transmission format, parameter type, status code, etc. The above content is described in detail on the service consumer execution side above, and this disclosure will not repeat it. After both parties complete the contract definition, a contract implementation file on the server side, such as a contract implementation code, can be generated to generate a service contract.

[0096] Step S420: Generate and publish a service test stub based on the service contract. The service test stub is used to provide the service consumer with a test operation.

[0097] According to some exemplary embodiments of the present disclosure, after generating the contract implementation code of the service side, a service test stub may be generated for the service provider based on the service contract, and the service test stub may be used to provide to the service consumer to perform test operations.

[0098] For example, continue to refer to Figure 2 , multiple service providers can publish service test stubs generated based on service contracts in the service storage location, and subsequent service consumers can download matching target test stubs from the service storage location according to service call requirements to perform test operations.

[0099] According to the microservice testing method in this example embodiment, on the one hand, by pre-defining the service contracts of both service parties to realize the interaction between services, more flexible and decoupled testing can be achieved. On the other hand, changes in the API of the service can be quickly integrated into the unit test without manually updating the test code of each service, thereby improving testing efficiency and reducing dependencies.

[0100] Next, the testing method of the microservices in this example embodiment will be further described.

[0101] In an exemplary embodiment of the present disclosure, for step S410, service contract structure information between multiple services is determined, and a service contract is generated based on the service contract structure information, including: determining the service contract structure information according to the request response requirements between the multiple services, the service contract structure information including one or more of a request structure, a response structure, service parameters and a status code; and generating a service contract based on the service contract structure information by a service testing tool.

[0102] The request response requirements may be specific requirements for service request and service response from both the service provider and the service user.

[0103] Define the message rules for requests and responses based on the request and response requirements of both parties, determine the service contract structure information, and complete the contract definition. Then, the service provider can use service testing tools, such as Spring Cloud Contract, to generate the contract implementation code on the server side. The following code is a template contract file.

[0104]

[0105] By defining clear inter-service contracts, each microservice can be tested independently without relying on other services. In this way, developers can focus on the internal logic of their own services without having to wait for other services to be updated, which greatly improves development efficiency. In addition, the contract test document can serve as a specification for the service interface, helping developers understand how to use the service correctly.

[0106] In an exemplary embodiment of the present disclosure, for step S420, generating and publishing a service test stub based on a service contract includes: determining a response service provided by a service provider; generating a service test stub based on the response service and the service contract; and publishing the service test stub to a service storage location through a service deployment tool, the service storage location including one or more of a service storage warehouse, a service registration center, and a centralized storage location.

[0107] The response service may be a service response that a service provider can provide. The service deployment tool may be a configuration tool for publishing service test piles. The service storage warehouse may be a data warehouse for storing service test piles. The service registration center may be a unified center for managing service test piles published by multiple service providers. The centralized storage location may be a centralized storage location for other services provided in the microservice architecture.

[0108] After determining the response service provided by the service provider, you can use packaging tools, such as the packaging tool mvnpackage, to generate service test stubs for the service provider. mvn package is mainly used for local development and testing to ensure that the code can be correctly compiled and packaged into a JAR file (Java Archive) or a web application file (WebArchive file, WAR file). Figure 2 , the present disclosure can save the service test stub as a JAR file, here the stubs.jar file, allowing the service consumer to perform integration testing locally without calling the actual remote service.

[0109] The service test stubs published by the service provider to the service storage location are all the latest versions, which allows the test solution disclosed in this disclosure to quickly respond to API changes. Once the API contract changes, the relevant unit tests can be updated immediately to ensure that all services can quickly adapt to the new API specifications. This rapid iteration and response mechanism not only ensures consistency and compatibility between services, but also provides strong support for continuous integration (CI) and continuous deployment (CD) processes.

[0110] After generating the service test stub, use a service deployment tool, such as mvn deploy, to deploy the service test stub jar to a service storage repository (such as a Maven repository), a service registry, or other centralized storage location so that service consumers can access and utilize these contracts. Service consumers can develop corresponding client code based on these contract definitions and perform local contract testing to ensure that their implementation is consistent with the contract. In this way, the publication and use of contracts promotes effective collaboration and compatibility verification between services, and through the above-mentioned automated process, API changes can be quickly integrated into unit tests without the need to manually update the test code for each service.

[0111] In an exemplary embodiment of the present disclosure, a service test stub is generated according to a response service and a service contract, including: determining response service information corresponding to the response service, the response service information including one or more of a response service name and a domain cluster name where the response service is located; determining a response service path corresponding to the response service according to the response service name and the domain cluster name; and generating a service test stub based on the response service path.

[0112] The response service information may be basic information included in the response service. For example, the response service information may include, but is not limited to, one or more of the response service name and the domain cluster name where the response service is located.

[0113] In a Kubernetes cluster, service discovery and communication are implemented through a specific DNS domain name format. The DNS domain name format can include the response service name and the domain cluster where it is located. The response service path is generated based on the response service name and the domain cluster name where the response service is located. For example, the path format can be <service-name> . <namespace>.svc.cluster.local. This format ensures that services can accurately discover and access each other through names. Then, service test stubs are generated based on the response service path. Specific naming rules simplify mutual discovery and access between services.

[0114] The service call paths of the service consumers to the service objects in the same cluster domain and different cluster domains have been described in detail in the above text on the naming method of the service call paths, and this disclosure will not elaborate on this.

[0115] In summary, the testing method of the microservice disclosed in the present invention determines the service consensus structure information between multiple services, generates a service consensus file based on the service consensus structure information; generates and publishes a service test stub based on the service consensus file, and the service test stub is used to provide to the service consumer to perform the test operation. On the one hand, by pre-defining the service contracts of both parties of the service to realize the interaction between services, more flexible and decoupled testing can be achieved. On the other hand, changes to the API in the service can be quickly integrated into the unit test without manually updating the test code of each service, while allowing the service user to use the latest downloaded stubs test stubs for local testing without remotely calling the service provider, thereby improving the testing efficiency and reducing the dependency.

[0116] In addition, in this example embodiment, a microservice testing system is also provided. Figure 2 The microservice testing system 200 may include: a service provider 210, which is used to determine the service contract structure information between multiple services, generate a service contract based on the service contract structure information, and generate and publish a service test stub based on the service contract; a service storage location 220, which is used to store the service test stub published by the service provider; a service consumer 230, which is used to generate a service call request according to the service test requirements and the service contract, and obtain a target test stub from the service storage location according to the service call request, and the target test stub is used to perform an integration test operation.

[0117] The disclosed microservice testing system optimizes the parallel development process under the microservice architecture through a contract-driven approach, improves development efficiency, reduces testing costs, such as reducing the cost of building and maintaining the test environment, and provides a solid foundation for the rapid iteration and continuous delivery of microservices. Contract testing can discover integration problems between services in the early stages of development, avoiding expensive modification costs later; at the same time, contract testing complements unit testing to ensure test coverage of interactions between services.

[0118] It should be noted that, although the steps of the method of the present invention are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.

[0119] Next, in this example embodiment, a microservice testing device is also provided. Figure 5 The microservice testing device 500 may include: a service request generating module 510 , a test stub acquiring module 520 and an integrated testing module 530 .

[0120] Specifically, the service request generation module 510 is used to obtain service test requirements and generate a service call request based on the service test requirements and a predefined service contract; the test stub acquisition module 520 is used to obtain a target test stub from a service storage location based on the service call request, and the service storage location is used to store the service test stub that has been newly released by the service provider; the integration test module 530 is used to perform integration test operations based on the target test stub.

[0121] In an exemplary embodiment of the present disclosure, the service request generation module 510 includes a service call request generation unit, which is used to: obtain a service contract, where the service contract is generated by a service testing tool based on service contract structure information, where the service contract structure information includes one or more of a request structure, a response structure, service parameters and a status code; determine test environment information based on service testing requirements; and generate a service call request based on the test environment information and the service contract.

[0122] In an exemplary embodiment of the present disclosure, a service call request generation unit includes a service call request generation sub-unit, which is used to: determine a target request service according to a service test requirement, the target request service including a target service name and a target cluster domain where the target request service is located; generate an initial service request address based on the target service name and the target cluster domain; generate port configuration information corresponding to the test environment information, and generate a service call request according to the port configuration information and the initial service request address.

[0123] In an exemplary embodiment of the present disclosure, the service call request generation subunit includes an initial address generation subunit, which is used to: take the cluster domain where the current service is located as the current cluster domain; obtain a predefined service request address format, the service request address format includes a same-domain identifier; when the current cluster domain and the target cluster domain are the same cluster domain, omit the same-domain identifier, and generate an initial service request address based on the target service name; when the current cluster domain and the target cluster domain are not the same cluster domain, determine the target domain name of the target cluster domain; generate an initial service request address based on the target service name and the target domain name.

[0124] In an exemplary embodiment of the present disclosure, the service call request includes a target service name, and the test pile acquisition module 520 includes a test pile acquisition unit, which is used to: establish a communication connection with the service storage location based on the service call request; determine the target test pile from multiple service test piles according to the target service name, and store the acquired target test pile locally.

[0125] In this example embodiment, a microservice testing device is also provided. Figure 6 The microservice testing device 600 may include: a consensus file generation module 610 and a test stub publishing module 620.

[0126] Specifically, the consensus file generation module 610 is used to determine the service contract structure information between multiple services and generate a service contract based on the service contract structure information; the test stub publishing module 620 is used to generate and publish service test stubs based on the service contract, and the service test stubs are used to provide to service consumers to perform test operations.

[0127] In an exemplary embodiment of the present disclosure, the consensus file generation module 610 includes a consensus file generation unit, which is used to: determine service contract structure information according to request response requirements between multiple services, the service contract structure information including one or more of request structure, response structure, service parameters and status code; and generate a service contract based on the service contract structure information by a service testing tool.

[0128] In an exemplary embodiment of the present disclosure, the test pile publishing module 620 includes a test pile publishing unit, which is used to: determine the response service provided by the service provider; generate a service test pile based on the response service and the service contract; and publish the service test pile to a service storage location through a service deployment tool, and the service storage location includes one or more of a service storage warehouse, a service registration center, and a centralized storage location.

[0129] In an exemplary embodiment of the present disclosure, a test pile publishing unit includes a test pile generating subunit, which is used to: determine response service information corresponding to a response service, the response service information including one or more of a response service name and a domain cluster name where the response service is located; determine a response service path corresponding to the response service based on the response service name and the domain cluster name; and generate a service test pile based on the response service path.

[0130] The specific details of the virtual modules of the testing devices of each microservice mentioned above have been described in detail in the testing methods of the corresponding microservices. The undisclosed details can be found in the implementation methods of the method part, so they will not be repeated here.

[0131] It should be noted that although several modules or units of the test device of the microservice are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0132] The exemplary embodiments of the present disclosure also provide a computer program product, which includes a computer program, and when the computer program is executed by a processor, the above-mentioned microservice testing method is implemented.

[0133] In one embodiment, the computer program product may be a tangible product containing the computer program, such as a computer-readable storage medium storing the computer program. Figure 7 , Figure 7 The schematic diagram of a computer-readable storage medium according to an exemplary embodiment of the present disclosure is schematically shown. The readable storage medium may be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, and other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory (Flash), mechanical hard disk (HDD), solid state drive (SSD), etc. Exemplarily, the computer program product may be implemented as a non-volatile storage medium storing a computer program, such as a read-only memory, a NAND flash memory (Nand Flash), etc.

[0134] In one embodiment, the computer program product may be an intangible product including a computer program. Exemplarily, the computer program product may be implemented as a virtual digital product, such as a digital file storing an executable file, an installation package, etc. of the computer program.

[0135] The code of the computer program can be written in one or more programming languages. Programming languages ​​such as C language, Java, C++, etc. The program code can be executed entirely on the user computing device, or partially on the user computing device, or as a separate software package, or partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, such as a local area network (LAN), a wide area network (WAN), etc., or can be connected to an external computing device (e.g., an Internet connection provided by an operator).

[0136] The computer program may be carried or transmitted via electrical, magnetic, optical, electromagnetic, infrared, or other signals. The electronic device may convert the signal carrying the computer program into a digital signal, thereby running the computer program. When the computer program is run on an electronic device, its code is used to enable the electronic device to execute (more specifically, the processor of the electronic device may execute) the method steps of various exemplary embodiments of the present disclosure, such as the test method for executing the above-mentioned microservices.

[0137] The exemplary embodiments of the present disclosure also provide an electronic device, which may include a processor and a memory. The memory stores executable instructions of the processor, such as a computer program. The processor executes the method steps of various exemplary embodiments of the present disclosure by executing the executable instructions.

[0138] Reference below Figure 8 , the electronic device is exemplarily described in the form of a general-purpose computing device. It should be understood that Figure 8 The electronic device 800 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0139] like Figure 8 As shown, the electronic device 800 may include: a processor 810 , a memory 820 , a bus 830 , an I / O (input / output) interface 840 , a network adapter 850 , and a display 860 .

[0140] The memory 820 may include a volatile memory, such as a RAM 821, a cache unit 822, and may also include a non-volatile memory, such as a ROM 823. The memory 820 may also include one or more program modules 824, such program modules 824 include but are not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or a combination thereof may include the implementation of a network environment. For example, the program module 824 may include each module in the above-mentioned device.

[0141] The processor 810 may include one or more processing units. For example, the processor 810 may include an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor and / or an NPU (Neural-Network Processing Unit), etc.

[0142] The processor 810 may be used to execute executable instructions stored in the memory 820, such as executing the above-mentioned microservice testing method.

[0143] The bus 830 is used to realize the connection between different components of the electronic device 800, and may include a data bus, an address bus, and a control bus.

[0144] The electronic device 800 can communicate with one or more external devices 900 (eg, a keyboard, a mouse, an external controller, etc.) through the I / O interface 840 .

[0145] The electronic device 800 can communicate with one or more networks through the network adapter 850. For example, the network adapter 850 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, near field communication, etc. The network adapter 850 can communicate with other modules of the electronic device 800 through the bus 830.

[0146] The electronic device 800 may display a graphical user interface, such as an interface displaying the integrated test results of the entire link, through the display 860 .

[0147] although Figure 8 Not shown, other hardware and / or software modules may also be provided in the electronic device 800, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, etc.

[0148] As can be seen from the above, the technical solution of the present disclosure can be implemented as a method, an apparatus, a system, a computer program product, a storage medium, an electronic device, etc. Those skilled in the art can understand that various aspects of the present disclosure can be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software, such as being respectively referred to as a "circuit", "module" or "system".

[0149] It should be understood that the present disclosure is not limited to the specific method steps or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from the scope thereof. Those skilled in the art will easily think of other embodiments based on the specific embodiments provided by the present disclosure. Therefore, the specific embodiments provided by the present disclosure are only exemplary, and the scope and spirit of the present disclosure are indicated by the claims, and any variations, uses or adaptive changes of the present disclosure should be covered, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the technical field that are not disclosed in the present disclosure.< / namespace> < / service-name> < / namespace> < / namespace> < / service-name>

Claims

1. A microservice testing method, characterized in that: include: Obtaining service test requirements, and generating a service call request based on the service test requirements and a predefined service contract; Acquire a target test stub from a service storage location based on the service call request, where the service storage location is used to store the service test stub most recently released by the storage service provider; An integration test operation is performed according to the target test stub.

2. The method according to claim 1, characterized in that: The generating of a service call request based on the service test requirement and a predefined service contract includes: Acquire the service contract, where the service contract is generated by a service testing tool based on service contract structure information, where the service contract structure information includes one or more of a request structure, a response structure, a service parameter, and a status code; Determine test environment information based on the service test requirements; The service call request is generated according to the test environment information and the service contract.

3. The method according to claim 2, characterized in that The generating the service call request according to the test environment information and the service contract includes: Determine a target request service according to the service test requirement, wherein the target request service includes a target service name and a target cluster domain where the target request service is located; Based on the target service name and the target cluster domain, generate an initial service request address; Generate port configuration information corresponding to the test environment information, and generate the service call request according to the port configuration information and the initial service request address.

4. The method according to claim 3, characterized in that: The generating an initial service request address based on the target service name and the target cluster domain includes: Set the cluster domain where the current service is located as the current cluster domain; Obtaining a predefined service request address format, wherein the service request address format includes a same-domain identifier; When the current cluster domain and the target cluster domain are the same cluster domain, the same-domain identifier is omitted, and the initial service request address is generated based on the target service name; When the current cluster domain and the target cluster domain are not the same cluster domain, determining a target domain name of the target cluster domain; The initial service request address is generated based on the target service name and the target domain name.

5. The method according to claim 1, characterized in that The service call request includes a target service name, and obtaining a target test stub from a service storage location based on the service call request includes: Establishing a communication connection with the service storage location based on the service call request; According to the target service name, the target test pile is determined from the plurality of service test piles, and the acquired target test pile is stored locally.

6. A microservice testing method, characterized in that: include: Determining service contract structure information between a plurality of services, and generating a service contract based on the service contract structure information; A service test stub is generated and published based on the service contract, and the service test stub is used to provide to a service consumer to perform a test operation.

7. The method according to claim 6, characterized in that The determining of service contract structure information between a plurality of services and generating a service contract based on the service contract structure information includes: Determining the service contract structure information according to the request response requirements between the multiple services, wherein the service contract structure information includes one or more of a request structure, a response structure, a service parameter, and a status code; The service contract is generated by a service testing tool based on the service contract structure information.

8. The method according to claim 6, characterized in that The generating and publishing a service test stub based on the service contract includes: Determine the responsive services provided by the service provider; Generate the service test stub according to the response service and the service contract; The service test stub is published to a service storage location through a service deployment tool, and the service storage location includes one or more of a service storage warehouse, a service registration center, and a centralized storage location.

9. The method according to claim 8, characterized in that The generating the service test stub according to the response service and the service contract includes: Determine response service information corresponding to the response service, where the response service information includes one or more of a response service name and a domain cluster name where the response service is located; Determine a response service path corresponding to the response service according to the response service name and the domain cluster name; The service test stub is generated based on the response service path.

10. A microservice testing system, characterized in that: include: A service provider is used to determine the service contract structure information between multiple services, generate a service contract according to the service contract structure information, and generate and publish a service test stub based on the service contract; A service storage location, used to store the service test stub published by the service provider; The service consumer is used to generate a service call request according to the service test requirements and the service contract, and obtain a target test stub from the service storage location according to the service call request, wherein the target test stub is used to perform an integrated test operation.

11. A microservice testing device, characterized in that: include: A service request generation module, used to obtain service test requirements and generate a service call request based on the service test requirements and a predefined service contract; A test pile acquisition module, used to acquire a target test pile from a service storage location based on the service call request, wherein the service storage location is used to store the service test pile newly released by the service provider; The integrated test module is used to perform integrated test operations according to the target test stub.

12. A microservice testing device, characterized in that: include: A consensus file generation module, used to determine service contract structure information between multiple services, and generate a service contract based on the service contract structure information; The test stub publishing module is used to generate and publish service test stubs based on the service contract, and the service test stubs are used to be provided to service consumers to perform test operations.

13. An electronic device, characterized in that: include: processor; as well as A memory having computer-readable instructions stored thereon, wherein the computer-readable instructions, when executed by the processor, implement the method for testing the microservice according to any one of claims 1 to 9.

14. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the microservice testing method according to any one of claims 1 to 9 is implemented.

Images