CN118193355A - Code testing method, storage medium and device - Google Patents

Abstract

The present invention provides a code testing method, storage medium and device. The method includes: obtaining relevant target parameters and test data packets of a target microservice to be tested; obtaining a list of accessible services in the target microservice according to the target parameters; and remotely calling the service to be tested in the service list according to the test data packet for testing. Through this method, by obtaining relevant parameters and test data packets of the target microservice to be tested, the test service can directly remotely call the service to be tested, regardless of whether the target microservice to be tested exposes a call interface to the outside, and then perform the test task, thereby ensuring the functionality of the target microservice to be tested.

Description

Code testing methods, storage media and equipment

Technical Field

The present invention relates to the field of Internet, and in particular to a code testing method, storage medium and device.

Background technique

With the popularization of the Internet, a large number of software systems adopt distributed architecture. In a distributed system, remote calls are required between different modules to ensure the normal operation of the entire system. Feign is a popular microservice framework that simplifies the work of developers by defining interfaces to implement remote calls. However, in distributed systems, there are many problems with remote call interfaces due to various reasons, such as network delays, service failures, etc. In order to improve the robustness and stability of the system, it is necessary to test the Feign remote call interface. However, in the actual production environment, many microservices to be tested cannot be directly called remotely from the outside.

Summary of the invention

It is an object of the present invention to enable testing of services in remote code.

A further object of the present invention is to ensure the security of the test interface.

In particular, the present invention provides a code testing method, comprising:

Obtain relevant target parameters and test data packets of the target microservice to be tested;

Get the list of accessible services in the target microservice based on the target parameters;

The test data packet remotely calls the service to be tested in the service list for testing.

Optionally, the step of remotely calling the service to be tested in the service list according to the test data packet to perform the test includes:

Call the test service to obtain the test data package;

The service under test is tested through the remote call framework according to the test data package.

Optionally, the step of obtaining relevant target parameters of the target microservice to be tested and a test data packet includes:

Publish the test service to the registration center to generate the test interface;

Receive relevant target parameters and test data packets of the target microservice to be tested through the test interface;

Parse the target parameters to obtain the parsing result, which includes the service name of the target microservice to be tested in the registration center.

Optionally, the step of obtaining a list of accessible services in a target microservice according to a target parameter includes:

Search the registration center according to the service name to get the service list.

Optionally, the steps of searching in a registration center according to the service name to obtain a service list include:

Find the server where the target microservice to be tested is located through the load balancer based on the service name;

Search the server by service name to get a list of services.

Optionally, before the step of obtaining relevant target parameters of the target microservice to be tested and the test data packet, the step further includes:

Add the test interface to the gateway routing configuration and enable security authentication.

Optionally, the steps of security authentication include:

Receive test requests;

Get the security token carried in the test request;

Validate the security token;

When the security token is verified, the test request is determined to have passed the security authentication.

Optionally, the target microservice to be tested includes a microservice that is not directly accessible to the outside.

According to yet another aspect of the present invention, there is provided a machine-readable storage medium on which a machine executable program is stored. When the machine executable program is executed by a processor, any of the above code testing methods is implemented.

According to another aspect of the present invention, a computer device is provided, comprising a memory, a processor, and a machine executable program stored in the memory and running on the processor, and the processor implements any of the above code testing methods when executing the machine executable program.

In the solution of the present invention, firstly, the relevant target parameters and test data packets of the target microservice to be tested are obtained, wherein the relevant target parameters include information such as the address of the target microservice; then, the list of accessible services in the target microservice is obtained according to the target parameters; and then, the service to be tested in the service list is remotely called according to the test data packet for testing. Through this method, regardless of whether the target microservice to be tested exposes a calling interface to the outside, the test service can directly call the target microservice to be tested to perform the test task, thereby ensuring the functionality of the target microservice to be tested.

Furthermore, in the solution of the present invention, the test service is also added to the registration center, and after the test interface is generated, the test interface is added to the gateway routing configuration, thereby enabling security authentication. Through this method, the security of the test service and the test interface can be guaranteed.

Based on the following detailed description of specific embodiments of the present invention in conjunction with the accompanying drawings, those skilled in the art will become more aware of the above and other objects, advantages and features of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Hereinafter, some specific embodiments of the present invention will be described in detail in an exemplary and non-limiting manner with reference to the accompanying drawings. The same reference numerals in the accompanying drawings indicate the same or similar components or parts. It should be understood by those skilled in the art that these drawings are not necessarily drawn to scale. In the accompanying drawings:

FIG1 is a schematic flow chart of a code testing method according to an embodiment of the present invention;

FIG2 is a schematic flow chart of a code testing method according to another embodiment of the present invention;

FIG3 is a schematic flow chart of a code testing method according to yet another embodiment of the present invention;

FIG4 is a schematic diagram of a system architecture of a code testing method according to an embodiment of the present invention;

FIG5 is a schematic diagram of a machine-readable storage medium in a code testing method according to an embodiment of the present invention; and

FIG6 is a schematic diagram of a computer device for a code testing method according to an embodiment of the present invention.

Detailed ways

It should be understood by those skilled in the art that the embodiments described below are only some embodiments of the present invention, rather than all embodiments of the present invention, and these embodiments are intended to explain the technical principles of the present invention, rather than to limit the protection scope of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should still fall within the protection scope of the present invention.

Fig. 1 is a schematic diagram of a flow chart of a method for testing a code according to an embodiment of the present invention. In some optional embodiments, this flow chart may generally include:

Step S101, obtain the relevant target parameters and test data packets of the target microservice to be tested. In some optional embodiments, microservice refers to a cloud-native architecture method that contains many loosely coupled and independently deployable small components or services in a single application. Its characteristics are that the code is easier to update, new features or functions can be added directly without updating the entire application, and the team can use different technology stacks and different programming languages for different components. Components can be expanded independently of each other, thereby reducing the waste and cost associated with having to expand the entire application (because a single function may face excessive load).

However, in actual production life, since some microservices are not exposed to the outside, that is, they cannot be directly called from the outside, only some functions of the target microservice can be used indirectly through other microservices. Therefore, the test of such target microservices is usually to repeatedly call its upper-layer microservices, thereby indirectly testing some functions of the target microservices. However, this test method cannot comprehensively test the target microservice. In order to solve the above problem, this embodiment is proposed.

In this embodiment, the relevant target parameters may generally include: the name of the target microservice to be tested in the registration center and other parameters, and the test data packet refers to the test data required to be input for the target microservice to be tested. Those skilled in the art can determine the relevant target parameters and the specific content of the test data packet according to actual conditions.

Step S102, obtaining a list of accessible services in the target microservice according to the target parameters. In some optional embodiments, since the target microservice is a framework of an overall service, which contains multiple detailed services and their corresponding addresses and ports, the list of accessible services in the target microservice is obtained through the target parameters to determine the specific services that need to be tested.

Step S103: remotely call the service to be tested in the service list according to the test data packet to perform the test.

The code testing method of this embodiment obtains the relevant parameters and test data packets of the target microservice to be tested through the test service, and then finds the specific service to be tested for testing. Through this method, regardless of whether the target microservice to be tested exposes the calling interface to the outside, the test service can directly call the target microservice to be tested to perform the test task, thereby ensuring the functionality of the target microservice to be tested.

In some optional embodiments, the step of remotely calling the service to be tested in the service list according to the test data packet to test can generally include: calling the test service to obtain the test data packet; remotely calling the service to be tested according to the test data packet to test. An optional example of a remote call framework is as follows: feign is a lightweight framework for http request calls, which can call http requests in the form of java interface annotations. Therefore, by reserving a method for remote calling through feign at the code level of the test service, when the service to be tested is known, this method is called, and the test data packet required for the test needs to be passed in as a parameter, thereby completing the remote call or remote test of the service to be tested.

The step of obtaining the relevant target parameters and test data packets of the target microservice to be tested can generally include: publishing the test service to the registration center to generate a test interface; receiving the relevant target parameters and test data packets of the target microservice to be tested through the test interface; parsing the target parameters to obtain the parsing results, and the parsing results include information such as the service name of the target microservice to be tested in the registration center. In this embodiment, a core function of the registration center is used for service registration. It allows service providers to register their services to the registration center so that other service consumers can discover and call these services. During the registration process, service providers usually provide some key information, such as service name, service address, service version, etc. This information will be used by the registration center for service management and search. Therefore, in this step, registering the test service to the registration center can facilitate the tester to call the test service through the test interface. In the process of using the test service, by obtaining the relevant target parameters and test data packets of the target microservice to be tested and parsing them, the parsing results are obtained, and the parsing results include information such as the service name of the target microservice to be tested in the registration center. The target microservice to be tested can be found through the service name of the target microservice to be tested in the registration center, thereby realizing the call.

The step of obtaining a list of accessible services in the target microservice according to the target parameters may generally include: searching in the registration center according to the service name to obtain a service list. In this embodiment, some optional examples of the registration center are as follows: Zookeeper, Eureka, Nacos, Consul, and ETCD, etc. The above examples can realize the functional requirements required by the registration center. Through such a registration center, the service list registered in the registration center by the microservice to be tested can be found according to the service name. Those skilled in the art can select the specific middleware of the registration center according to the actual situation. The service list records the address and port information of each service.

According to the service name, the step of searching in the registration center to obtain the service list can generally include: searching the server where the target microservice to be tested is located through the load balancer according to the service name; searching in the server according to the service name to obtain the service list. In this embodiment, the role of the load balancer is a technology that distributes workloads (such as network traffic, data requests, computing tasks, etc.) to multiple computing resources (such as servers, virtual machines, containers, etc.) to optimize performance, improve reliability and increase scalability. Therefore, in actual production, since many businesses are distributed architectures and respond through multiple server clusters, the server where the target microservice to be tested corresponding to the service name can be found through the load balancer, thereby achieving the purpose of testing the microservice to be tested. An optional load balancer such as middleware such as Ribbon and Nginx. Those skilled in the art can determine the type of load balancer according to actual conditions.

Before obtaining the relevant target parameters of the target microservice to be tested and the step of testing the data packet, it can also generally include: adding the test interface to the gateway routing configuration and turning on security authentication. In this embodiment, the gateway is a network gateway and channel for unified management of the API, and is the only entrance for all requests of the entire microservice platform. All clients and consumers access the microservice through a unified gateway, and all non-business functions are processed at the gateway layer. Routing forwarding and filter functions can be realized in the gateway. Routing forwarding refers to receiving all external requests and forwarding them to the microservices at the back end. The filter function refers to a series of cross-cutting functions that can be completed in the service gateway, such as permission verification, current limiting, and monitoring. In this step, the forwarding of external test requests is realized by adding the test interface to the gateway routing configuration. By adding the security authentication function to the filter, the security detection can be performed on the test interface when it is called. Only by passing the security detection can the call be allowed, thereby ensuring the security of the test interface. Optional examples of gateways include: middleware such as Gateway. Those skilled in the art can determine the type of gateway and the specific process and specific operation mode of security authentication according to actual conditions.

In some optional embodiments, the steps of security authentication may generally include: receiving a test request; obtaining a security token carried in the test request; verifying the security token; and when the security token passes the verification, determining that the test request passes the security authentication. Among them, the security token is an optional way of security verification, a security mechanism for identity authentication and access control, usually a number or code, similar to a password, which can be used to prove the identity of the user.

Through this method, when the test service obtains the target parameters and test data packets related to the target service to be tested, the service list corresponding to the microservice to be tested that cannot be directly remotely called in actual production can be found through the registration center, and then the service in the service list can be remotely called through the test data packet, thereby achieving the purpose of testing hidden services. In addition, all microservices in the code can be tested, and the security of the test service can be guaranteed by installing a gateway and opening security authentication.

Fig. 2 is a flow chart of a method for testing code according to another embodiment of the present invention. In some optional embodiments, this process may generally include:

Step S201, security authentication is performed on the test request through the gateway. In this embodiment, this step can generally include: adding the test interface to the gateway routing configuration and opening security authentication. Wherein the gateway is a network gateway and channel for unified management of API, and is the only entrance for all requests of the entire microservice platform. All clients and consumers access the microservice through a unified gateway, and all non-business functions are processed at the gateway layer. Routing forwarding and filter functions can be realized in the gateway. Wherein routing forwarding refers to receiving all external requests and forwarding them to the microservices at the back end. The filter function refers to a series of cross-cutting functions that can be completed in the service gateway, such as permission verification, current limiting and monitoring. In this step, the forwarding of external test requests is realized by adding the test interface to the gateway routing configuration. By adding the security authentication function in the filter, the security detection can be performed on the test interface when it is called. Only by passing the security detection can the call be allowed, thereby ensuring the security of the test interface. Those skilled in the art can determine the type of gateway and the specific process and the specific operation mode of security authentication according to the actual situation.

Step S202, receives the relevant target parameters and test data packets of the target microservice to be tested through the test interface. In some optional embodiments, microservice refers to a cloud native architecture method, which includes many loosely coupled and separately deployable small components or services in a single application. It is characterized in that the code is easier to update, and new features or functions can be added directly without updating the entire application, and the team can use different technology stacks and different programming languages for different components. The components can be extended independently of each other, thereby reducing the waste and cost associated with having to extend the entire application (because a single function may face too much load). In actual production life, since some microservices are not exposed to the outside, that is, they cannot be directly called from the outside, only some functions of the target microservice can be indirectly used through other microservices. Therefore, the test for such target microservices is usually to repeatedly call its upper-level microservices, thereby indirectly testing some functions of the target microservices, but this test method cannot comprehensively test the target microservices. In order to solve the above problems, this embodiment is proposed.

In this embodiment, the relevant target parameters may generally include: the name of the target microservice to be tested in the registration center and other parameters, and the test data packet refers to the test data required to be input for the target microservice to be tested. Those skilled in the art can determine the relevant target parameters and the specific content of the test data packet according to actual conditions.

Step S203, search and call the test service in the registration center. In some optional embodiments, a core function of the registration center is to register services. It allows service providers to register their services with the registration center so that other service consumers can discover and call these services. During the registration process, the service provider usually provides some key information, such as service name, service address, service version, etc. This information will be used by the registration center for service management and search. Therefore, in this step, by registering the test service with the registration center, it is convenient for testers to call the test service through the test interface.

Step S204, parse the target parameters to obtain a parsing result. In some optional embodiments, in the process of using the test service, the relevant target parameters of the target microservice to be tested and the test data packet are obtained and parsed to obtain a parsing result, and the parsing result includes information such as the service name of the target microservice to be tested in the registration center. The target microservice to be tested can be found through the service name of the target microservice to be tested in the registration center, so as to realize the call.

Step S205, find the server where the target microservice to be tested is located through the load balancer according to the service name. In this embodiment, the role of the load balancer is a technology that distributes workloads (such as network traffic, data requests, computing tasks, etc.) to multiple computing resources (such as servers, virtual machines, containers, etc.) to optimize performance, improve reliability, and increase scalability. Therefore, in actual production, since many businesses are distributed architectures and respond through multiple server clusters, the server where the target microservice to be tested corresponding to the service name is located can be found through the load balancer, thereby achieving the purpose of testing the microservice to be tested.

Step S206, search the server according to the service name to obtain a service list. In this embodiment, some optional examples of the registration center are as follows: Zookeeper, Eureka, Nacos, Consul, and ETCD, etc. The above examples can realize the functional requirements required by the registration center. Through such a registration center, the service list of the microservice to be tested registered in the registration center can be found according to the service name. Those skilled in the art can select the specific middleware of the registration center according to the actual situation. The service list records the address and port information of each service.

Step S207, testing the service to be tested through the remote call framework according to the test data packet. In this embodiment, an optional example of the remote call framework is as follows: feign is a lightweight framework for http request calls, which can call http requests in the form of java interface annotations. Therefore, by reserving a method for remote calling through feign at the code level of the test service, when the service to be tested to be called is known through the above steps, this method is called, and the test data packet required for the test needs to be passed in as a parameter, thereby completing the remote call or remote test of the service to be tested.

Through this method, when the test service obtains the relevant information of the target service to be tested and the test data packet, it can find the service list corresponding to the microservice to be tested that cannot be directly called in actual production through the registration center, and then remotely call the service in the service list through the test data packet, thereby achieving the purpose of testing hidden services. In addition, all microservices in the code can be tested, and the security of the test service can be guaranteed by installing a gateway and opening security authentication.

Fig. 3 is a flow chart of a method for testing a code according to another embodiment of the present invention. In some optional embodiments, this flow may generally include:

Step S301, receiving an Http Request. In this embodiment, an Http Request represents a request sent from a client, that is, a test request; when a client accesses a server through the HTTP protocol, all information in the HTTP request header is encapsulated in this object, and all information requested by the client can be obtained through the methods provided by this object.

Step S302, verify whether the token in the request header is valid. In this embodiment, since the test service is added to the gateway routing configuration and security authentication is enabled, the gateway will verify whether the request is safe or complies with preset rules. An optional way is to verify whether the token in the request header is valid. Among them, token is a security token, which carries the information agreed upon by the server, so when the gateway receives the token, it can determine that the request is a credible request, thereby passing the security authentication.

Step S303, according to the relevant parameters in the request body, search the IP and port of the service to be tested in the registration center. In some optional embodiments, IP is the access address of a service in the server, and port is the port assigned to a service in the server. In this embodiment, the port in the logical sense usually refers to the port in the TCP/IP protocol, and the port number ranges from 0 to 65535, such as for browsing web services. When the IP and port of the service to be tested are obtained, that is, the address and port for accessing the service to be tested are obtained, then the specific method in the service to be tested can be called through this IP and port, so as to perform the test. Those skilled in the art can determine the specific form of the relevant parameters according to the actual business logic.

Step S304, initiating a request to the service under test according to the test data packet in the request body. In this embodiment, this step generally may include: remotely calling a method in the service under test using the test data packet as a parameter through the IP and port of the service under test found in step S301, thereby implementing a test on the service under test.

Step S305, receiving the response of the service under test, and delivering the response result to the client. In some optional embodiments, after the method of the service under test is remotely called, it is executed according to the logic of the service under test itself, and after the operation is completed, a response result will be obtained, that is, the response made by the service under test after receiving the call, and then the response result will be returned to the client, that is, the location where the response result of the test request is received.

Through this method, after the client initiates a test request, it can search according to the specific information carried in the test request, and after finding the address and port of the service to be tested, initiate the test according to the test data packet, and then return the response result to the client. Compared with the existing test methods, when the service to be tested cannot be called directly or is hidden from the outside, the address and port of the service to be tested can be found according to the relevant parameters, thereby realizing the method of remotely calling the service to be tested. Then the test of the service to be tested is realized.

Fig. 4 is a schematic diagram of a system architecture of a code testing method according to an embodiment of the present invention. In some optional embodiments, this schematic diagram may generally include: a load balancer 410, a gateway 420, a registry cluster 430, a microservice to be tested 440, and a test service 450.

Among them, the role of the load balancer 410 is a technology that distributes workloads (such as network traffic, data requests, computing tasks, etc.) to multiple computing resources (such as servers, virtual machines, containers, etc.) in order to optimize performance, improve reliability, and increase scalability. In this embodiment, the load balancer 410 is used to receive external requests, and then send the requests to the gateway 420 of the corresponding server through load balancing. An optional example of the load balancer 410 is as follows: Nginx middleware. Those skilled in the art can select a specific load balancer configuration according to actual needs.

Gateway 420 is a network gateway and channel for unified management of APIs. It is the only entrance for all requests of the entire microservice platform. All clients and consumers access microservices through a unified gateway, and all non-business functions are processed at the gateway layer. Routing forwarding and filter functions can be implemented in the gateway. Routing forwarding refers to receiving all external requests and forwarding them to the microservices at the back end. The filter function refers to a series of cross-cutting functions that can be completed in the service gateway, such as permission verification, current limiting, and monitoring. In this embodiment, an optional example of gateway 420 is such as Gateway middleware, which can realize load balancing while realizing the role of the gateway, thereby sending requests to the corresponding server to call the corresponding service. Those skilled in the art can select a specific gateway configuration according to actual needs.

A core function of the registry cluster 430 is to register services. It allows service providers to register their services with the registry so that other service consumers can discover and call these services. During the registration process, service providers usually provide some key information, such as service name, service address, service version, etc. This information will be used by the registry to manage and find services. In addition, the registry cluster 430 will also regularly pull service lists for the gateway 420 and other services, so as to update the relevant registration information in the registry cluster in time. An optional example of the registry cluster 430 is nacos middleware. Those skilled in the art can select a specific registry configuration according to actual needs.

When the tester wants to test the service 441 in the microservice 440 to be tested through the client, and the microservice 440 to be tested is only registered in the registration center cluster due to actual business reasons and is not open to the outside world, the microservice 440 to be tested cannot be directly called from the outside, that is, the test cannot be directly initiated to the microservice 440 to be tested.

In this embodiment, the tester implements direct testing of the service 441 to be tested in the microservice 440 to be tested by calling the test service 450. The specific execution process is: when the tester can call the test service 450, the tester sends a test request to the test service 450 through the client, and the test request stores the relevant target parameters and test data packets of the microservice to be tested. The relevant target parameters generally include: the name of the target microservice 440 to be tested in the registration center cluster 430 and other parameters, and the test data packet refers to the test data required to be input for the target microservice to be tested. Then, the load balancer 410 finds the corresponding gateway 420 for authentication; after passing the authentication, the name and other information of the microservice 440 to be tested in the registration center cluster 430 are determined according to the information in the test request, so as to find the corresponding service list in the registration center cluster 430; then, the address and port information of the service 441 to be tested are found in the service list, and a remote call is initiated to the service 441 to be tested according to the content in the test data packet.

Through the above method, all services registered in the registry cluster can be remotely called through the test service, so that when some services are hidden from the outside, testing can also be performed to ensure the functionality of the service under test. In addition, the test service is also registered and added to the gateway to ensure the security of the test service.

This embodiment also provides a machine-readable storage medium and a computer device. Figure 5 is a schematic diagram of a machine-readable storage medium 501 according to an embodiment of the present invention, and Figure 6 is a schematic diagram of a computer device 603 according to an embodiment of the present invention.

The machine-readable storage medium 501 stores a machine executable program 502 , which implements the code testing method of any of the above embodiments when executed by a processor.

The computer device 603 may include a memory 601 , a processor 602 , and a machine executable program 502 stored in the memory 601 and running on the processor 602 , and the processor 602 implements the code testing method of any of the above embodiments when executing the machine executable program 502 .

It should be noted that the logic and/or steps represented in the flowchart or described in other ways herein, for example, remotely calling the service to be tested, can be specifically implemented in any machine-readable storage medium for use by an instruction execution system, device or equipment (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or equipment and execute instructions), or used in combination with these instruction execution systems, devices or equipment.

For the description of this embodiment, the machine-readable storage medium 501 may be any device that can contain, store, communicate, propagate or transmit a program for use with an instruction execution system, apparatus or device or in conjunction with such instruction execution system, apparatus or device.

It should be understood that each part of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system.

The computer device 603 may be a vehicle-mounted device such as an onboard computer. The computer device 603 may be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, a program module may include routines, programs, target programs, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. The computer device 603 may be implemented in a distributed cloud computing environment where remote processing devices linked via a communication network perform tasks. In a distributed cloud computing environment, program modules may be located on a local or remote computing system storage medium including a storage device, such as a central processing unit of a vehicle.

The computer device 603 may include a processor 602 adapted to execute stored instructions, and a memory 601 that provides temporary storage space for the operation of the instructions during operation. The processor 602 may be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory 601 may include a random access memory (RAM), a read-only memory, a flash memory, or any other suitable storage system.

The processor 602 may be connected to an I/O interface (input/output interface) suitable for connecting the computer device 603 to one or more I/O devices (input/output devices) through a system interconnect (e.g., PCI, PCI-Express, etc.). The I/O devices may include, for example, a keyboard and a pointing device, wherein the pointing device may include a touch pad or a touch screen, etc. The I/O devices may be built-in components of the computer device 603, or may be devices externally connected to the computing device.

Processor 602 can also be linked to a display interface suitable for connecting computer device 603 to a display device through a system interconnection. Display device can include a display screen as a built-in component of computer device 603. Display device can also include a computer monitor, a television or a projector, etc., which are externally connected to computer device 603. In addition, a network interface controller (NIC) can be suitable for connecting computer device 603 to a network through a system interconnection. In some embodiments, NIC can use any suitable interface or protocol (such as an Internet small computer system interface, etc.) to transmit data. The network can be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN) or the Internet, etc. Remote devices can be connected to computing devices through a network.

The flow chart provided by the present embodiment is not intended to indicate that the operation of the method will be performed in any particular order, or that all operations of the method are included in all every case. In addition, the method may include additional operations. Within the scope of the technical ideas provided by the present embodiment method, additional changes may be made to the above method.

At this point, those skilled in the art should recognize that, although multiple exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications that conform to the principles of the present invention can still be directly determined or derived based on the content disclosed in the present invention without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should be understood and identified as covering all such other variations or modifications.

Claims (10)

1. A method of testing a code, comprising:

Acquiring relevant target parameters and test data packets of a target micro-service to be tested;

Acquiring a service list accessible in the target micro-service according to the target parameters;

and remotely calling the service to be tested in the service list according to the test data packet to test.

2. The method for testing a code according to claim 1, wherein,

The step of remotely calling the service to be tested in the service list for testing according to the test data packet comprises the following steps:

calling a test service to acquire the test data packet;

and remotely calling the service to be tested according to the test data packet to test.

3. The method for testing a code according to claim 2, wherein,

The step of obtaining the relevant target parameters and the test data packet of the target micro-service to be tested comprises the following steps:

releasing the test service to a registry so as to generate a test interface;

receiving relevant target parameters and test data packets of the target micro-service to be tested through the test interface;

and analyzing the target parameters to obtain an analysis result, wherein the analysis result comprises the service name of the target micro-service to be tested in the registry.

4. The method for testing a code according to claim 3, wherein,

The step of obtaining the service list accessible in the target micro-service according to the target parameter comprises the following steps:

and searching in the registry according to the service name to obtain the service list.

5. The method for testing a code according to claim 4, wherein,

The step of searching in the registry according to the service name to obtain the service list comprises the following steps:

Searching a server where the target micro-service to be detected is located through a load balancer according to the service name;

And searching in the server according to the service name to obtain the service list.

6. The method for testing a code according to claim 3, wherein,

The step of obtaining the relevant target parameters of the target micro-service to be tested and the test data packet further comprises the following steps:

and adding the test interface into gateway routing configuration, and starting security authentication.

7. The method for testing a code according to claim 6, wherein,

The step of security authentication comprises the following steps:

Receiving a test request;

Acquiring a security token carried in the test request;

verifying the security token;

and when the security token passes the verification, judging that the test request passes the security authentication.

8. The method of testing a code according to claim 1, wherein the target micro-service to be tested comprises an externally inaccessible micro-service.

9. A machine-readable storage medium having stored thereon a machine-executable program which, when executed by a processor, implements a method of testing a code according to any of claims 1 to 8.

10. A computer device comprising a memory, a processor and a machine executable program stored on the memory and running on the processor, and the processor when executing the machine executable program implements the method of testing the code of any one of claims 1 to 8.