CN114428734B

CN114428734B - Mock method, mock system and test system

Info

Publication number: CN114428734B
Application number: CN202210061201.7A
Authority: CN
Inventors: 王俭
Original assignee: Hangzhou Benma Network Technology Co ltd
Current assignee: Hangzhou Benma Network Technology Co ltd
Priority date: 2022-01-19
Filing date: 2022-01-19
Publication date: 2025-07-22
Anticipated expiration: 2042-01-19
Also published as: CN114428734A

Abstract

The present invention discloses a mock method, a mock system and a test system, wherein the mock method comprises the following steps: obtaining an API request sent by a client through a proxy module, the proxy module has an independent local domain name, and the proxy module only acts as a proxy for the client; judging whether to perform a mock test based on the API request, generating corresponding mock data when performing a mock test, and sending the mock data to the proxy module, which is returned to the client by the proxy module. The present invention has a one-to-one correspondence between proxy modules and clients, and each proxy module has an independent local domain name design, which effectively avoids mutual contamination of mock data.

Description

Mock method, mock system and test system

Technical Field

The present invention relates to the field of information technologies, and in particular, to a mock method, a mock system, and a test system.

Background

Because of different labor division in a modern software development system, the client and the server usually bear the development of corresponding functions by different development roles, namely, the client developer takes charge of designing and realizing a UI interface, interaction logic and a data request, and the server developer takes charge of storing related business logic of data in a lasting way, and in the development mode, the server developer is required to provide an API for the client developer to realize the interaction of the client and the server.

Before the API is developed by the server, the API is unavailable, theoretically, a client developer needs to wait for the completion of the API of the server to perform the butt joint and development of the API so as to ensure that the client and the server can realize the same function according to the consistent target, but the development efficiency is slower, so that after the API is designed and before the development is completed, the development of the client is assisted by simulating the capability of the API in a mock mode, the parallel development of the client and the server is realized, the overall development efficiency is further improved,

The API provided by the server is typically an HTTP API, but the mock solution provided today is not applicable to scenarios involving service domain names.

Disclosure of Invention

Aiming at the defects that the mock scheme in the prior art is large in limitation and not suitable for a test scene related to a service domain name, the invention provides a mock technology and a test technology.

In order to solve the technical problems, the invention is solved by the following technical scheme:

A mock method comprising the steps of:

The method comprises the steps that an API request sent by a client is obtained through an agent module, wherein the agent module is provided with independent local domain names, namely, the local domain names of the agent modules are different from each other, and the agent module only agents the client;

Judging whether to perform a mock test or not based on the API request, generating corresponding mock data when the mock test is performed, sending the mock data to the proxy module, and returning the proxy module to the client.

As an implementation manner, before the agent module obtains the API request sent by the client, the method further includes an initialization step, which specifically includes:

receiving a pull notification sent by an agent module, wherein the pull notification comprises client information;

Reading a mock configuration ID of a corresponding client based on the client information, wherein the mock configuration ID has uniqueness and is mapped with a plurality of rule data;

and pulling corresponding rule data based on the mock configuration ID, generating and storing a target rule group corresponding to the mock configuration ID, wherein the rule data comprises a corresponding API name and a mock rule.

As one implementation manner, the API request includes client information, and based on the API request, whether to perform a mock test is determined, and when performing the mock test, the step of generating corresponding mock data is as follows:

Reading a mock configuration ID of a corresponding client based on the client information, and acquiring corresponding rule data based on the mock configuration ID to obtain a target rule group;

Reading API configuration data of the client based on the client information, wherein the API configuration data comprises an API name and mock starting information;

judging whether to perform a mock test or not based on the API configuration data and the API request, acquiring corresponding rule data from the target rule group based on the API request when performing the mock test, and generating corresponding mock data based on the rule data.

As one possible implementation:

And carrying out data combination on the API configuration data and the target rule set to obtain a corresponding combination rule set, namely filtering rule data in the target rule set based on the API configuration data, so that the rule data in the obtained combination rule set are all rule data of the API which needs the mock test in the corresponding client.

And inquiring whether the rule data corresponding to the API request exists in the merging rule group, judging that the mock test is not performed when the rule data does not exist, judging that the mock test is performed when the rule data exists, and generating corresponding mock data based on the rule data.

The invention also provides a mock system, which comprises a mock service, wherein the mock service comprises the following components:

the request receiving unit is used for acquiring an API request sent by a client through a proxy module, wherein the proxy module has an independent local domain name and only proxies the client;

And the processing unit is used for judging whether to carry out a mock test or not based on the API request, generating corresponding mock data when the mock test is carried out, sending the mock data to the proxy module, and returning the proxy module to the client.

As one possible implementation:

The mock system also comprises a mock configuration service connected with each mock service signal;

The mock configuration service is used for configuring rule data and grouping data, wherein the grouping data is used for indicating the mapping relation between the mock configuration ID and the rule data;

The mock service further includes:

The notification receiving unit is used for receiving the pull notification sent by the proxy module, wherein the pull notification contains client information;

the first pulling unit is used for reading the mock configuration ID of the corresponding client based on the client information;

and the second pulling unit is used for pulling corresponding rule data from the mock configuration service based on the mock configuration ID, generating and storing a target rule group corresponding to the mock configuration ID, wherein the rule data comprises a corresponding API name and a mock rule.

As an embodiment, the processing unit includes:

The processing subunit is used for extracting client information from the API request, and also used for enabling the first pulling unit to read a mock configuration ID and API configuration data of a corresponding client based on the client information, wherein the API configuration data comprises an API name and mock starting information;

an extraction subunit, configured to obtain corresponding rule data based on the mock configuration ID, and obtain a target rule group;

And the execution subunit is used for judging whether to perform a mock test or not based on the API configuration data and the API request, and when the mock test is performed, acquiring corresponding rule data from the target rule group based on the API request, and generating the corresponding mock data based on the rule data.

The invention also provides a test system, which comprises:

the system comprises a mock system, a plurality of clients and proxy modules corresponding to the clients one by one, wherein the corresponding clients are in signal connection with the proxy modules, and each proxy module is in signal connection with the mock system;

each proxy module is provided with an independent local domain name, and is used for receiving an API request initiated by a corresponding client, sending the API request to the mock system, receiving mock data returned by the mock system and sending the mock data to the corresponding client;

and the mock system is used for receiving the API requests sent by the proxy modules, judging whether to perform a mock test based on the API requests, generating corresponding mock data when performing the mock test, and returning to the corresponding proxy modules.

As one possible implementation:

the mock system comprises a mock configuration service and a plurality of mock services which are in signal connection, and each mock service is in signal connection with the mock configuration service;

The mock configuration service is used for configuring rule data and packet data, wherein the rule data comprises corresponding API information and mock rules, and the packet data comprises a mock configuration ID and a plurality of API information mapped with the mock configuration ID.

As one possible implementation:

Each client and each proxy module are operated in the terminal equipment, and the corresponding client and proxy module are operated in the same terminal equipment;

the mock service corresponds to the terminal equipment one by one, or the mock service corresponds to the client side one by one;

When the mock service corresponds to the terminal equipment one by one, the mock service is respectively connected with each client group and each proxy module running in the terminal equipment in a signal manner;

When the mock service corresponds to the client one by one, the mock service is in signal connection with the client and the proxy module corresponding to the client.

That is, the number of mock services in the present invention may be one or more.

The invention has the remarkable technical effects due to the adoption of the technical scheme:

the invention corresponds to the proxy modules and the clients one by one, and each proxy module has the independent design of the local domain name, so that the mutual pollution of mock data is effectively avoided.

The invention separates the mock service and the mock configuration service, so that the centralized mock configuration service and the localized mock service are combined, the centralized mock configuration service can meet the requirement of mock data sharing, and the localized mock service can improve the system stability.

The invention designs the mock configuration ID, so that a plurality of clients can share one target rule group, and data redundancy is effectively avoided.

The invention designs the API configuration data, is convenient for performing mock test identification on the API request, and accurately judges whether the mock test is needed.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of module connection of a mock service in a mock system according to the present invention;

FIG. 2 is a schematic diagram of another module connection of a mock service in a mock system of the present invention;

FIG. 3 is a schematic diagram of the modular connection of a test system according to the present invention;

Fig. 4 is a schematic diagram of module connection of the test system when the mock service 11 corresponds to the terminal device;

FIG. 5 is a schematic diagram of the module connection of the test system when the mock service 11 corresponds to the client 20;

fig. 6 is a timing diagram of a test system performing a mock test.

Detailed Description

The present invention will be described in further detail with reference to the following examples, which are illustrative of the present invention and are not intended to limit the present invention thereto.

Example 1, a mock process, comprising the steps of:

s100, acquiring an API request sent by a client through a proxy module, wherein the proxy module has an independent local domain name and only proxies the client;

And S200, judging whether to perform a mock test or not based on the API request, generating corresponding mock data when the mock test is performed, sending the mock data to the proxy module, and returning the proxy module to the client.

When the mock data is associated with a domain name, the mock data is isolated based on the local domain name of the proxy module.

The mock method provided by the prior art has higher limitation, and when a mock test relates to a service domain name, the phenomenon of data pollution exists, so that the test requirement in the current software development process is difficult to meet;

In the prior art, each client sends an API request to a mock service (mockserver), and when the mock service performs corresponding mock based on a fixed domain name (mock server.com), the mock data of each client related to the fixed domain name can mutually cover pollution;

the HTTP Cookie is taken as an example for detailed description:

The first client side makes an API request for simulating the Cookie, and the mock service writes the corresponding Cookie, namely, cookie1, based on a fixed domain name (mockserver.com);

At this time, the second client also provides an API request for simulating the Cookie, and the mock service also writes the corresponding Cookie, namely, the Cookie2, based on the fixed domain name (mock server.com);

since cookie1 and cookie2 are written under the same fixed domain name, cookie2 will overwrite cookie1, resulting in mock data that will overwrite each other.

Aiming at the problem that mock data related to service domain names can mutually cover pollution, different mockserver domain names can be started for different requests to isolate Cookies so as to avoid the mutual pollution of the mock data, but the proposal needs each API to open a special domain name, has extremely high implementation cost and has no practicability.

According to the invention, the proxy module and the client are in one-to-one correspondence, the proxy module is provided with independent local domain names, when an API request sent by the proxy module is received, the isolation of mock data can be realized based on the local domain names of the proxy module, so that any type of data can not pollute actual service when mock is carried out, and the mock of the HTTP Cookie is taken as an example, and cookies corresponding to different clients are isolated based on the local domain names of the corresponding proxy module.

Further, in step S200, whether to perform the mock test is determined based on the API request, and the specific steps for generating the corresponding mock data when performing the mock test are as follows:

S210, reading a mock configuration ID of a corresponding client based on the client information, and acquiring corresponding rule data based on the mock configuration ID to obtain a target rule group;

s220, reading API configuration data of the client based on the client information, wherein the API configuration data comprises an API name and mock starting information;

And S230, judging whether a mock test is carried out or not based on the API configuration data and the API request, and when the mock test is carried out, acquiring corresponding rule data from the target rule group based on the API request and generating corresponding mock data based on the rule data.

The rule data includes API information and corresponding mock rules, and executing the mock rules can obtain corresponding mock data, which is the prior art, and will not be described in detail in this specification.

Because the rule data corresponding to the mock configuration ID is not all the rule data required by the corresponding client, in the actual test process, a real response result needs to be returned instead of the mock data aiming at the API request corresponding to the API which has completed the mock test;

For example:

After the first client finishes the mock test of the first API, a client developer changes the mock starting information of the first API into closed state to indicate that the mock test is not performed any more, and when the first client initiates an API request corresponding to the first API again, the automatic judgment is made that the mock test is not performed based on the mock starting information of the first client;

According to the invention, through designing the API configuration data, a client developer configures the API configuration data of the corresponding client according to actual needs, and after the mock service receives an API request, the API configuration data of the corresponding client is pulled, and whether the mock test is executed or not is determined based on the API configuration data.

Further, in step S230, the specific steps for determining whether to perform the mock test based on the API configuration data and the API request are as follows:

S231, carrying out data combination on the API configuration data and the target rule set to obtain a corresponding combination rule set;

The priority of the API configuration data is higher than that of the target rule group, and rule data in the target rule group is extracted based on mock starting information in the API configuration data, so that rule data corresponding to the APIs required by the corresponding client for performing mock test are all in the merged rule group;

S232, inquiring whether rule data corresponding to the API request exists in the merging rule group, judging that the mock test is not performed when the rule data does not exist, judging that the mock test is performed when the rule data exists, and generating corresponding mock data based on the rule data.

Embodiment 2, adding S300 an initialization step to embodiment 1, and the rest is the same as embodiment 1, specifically, before step S100 obtains the API request sent by the client through the proxy module, the following steps are performed:

s310, receiving a pull notification sent by the proxy module, wherein the pull notification comprises client information;

the client information is the client information of the client proxied by the proxy module.

In this embodiment, the pull notification is initiated when each proxy module is initialized, and a person skilled in the art may also cause each proxy module to initiate the pull notification at regular time according to actual needs, which is not described in detail in this embodiment;

s320, reading a mock configuration ID of a corresponding client based on the client information;

The mock configuration ID is a mock configuration ID configured by a client staff, and has uniqueness;

The mock configuration ID is mapped with a plurality of rule data, wherein the rule data comprises corresponding API names and mock rules, the mock rules are used for defining a data mock mode which can be identified and processed by a mock service, and the data mock mode is stored in a JSON data format.

S330, pulling corresponding rule data based on the mock configuration ID, generating a target rule group corresponding to the mock configuration ID, and storing the target rule group.

Note that, a person skilled in the art may set a mapping relationship between a mock configuration ID and rule data according to actual needs, a client may have at least one mock configuration ID, and the mock configuration IDs of the clients in the same terminal device may be the same or different, which is not limited in detail by the present invention.

The mock method disclosed in the embodiment is executed in the terminal equipment;

According to the method, corresponding rule data are pulled in advance based on the mock configuration ID of the client, and a target rule group corresponding to the mock configuration ID is generated and stored, so that corresponding mock rules can be extracted when a mock test is conducted;

A plurality of clients and agent modules corresponding to the clients can be operated in one terminal device, rule data required by the clients in the same terminal device are overlapped, for example, a mock configuration ID is configured for each client, so that a corresponding target rule group is pulled for each client to be stored, and data redundancy is caused;

Therefore, client developers can construct one or more mock configuration IDs according to APIs of all clients in the current terminal equipment to reduce data redundancy, and rule data among different clients can be shared on the premise of ensuring normal mock testing by configuring the API configuration data for each client.

For example:

All clients in the current terminal equipment share a mock configuration ID, and the API mapped with the mock configuration ID is the intersection of APIs corresponding to all the clients, and the method specifically comprises the following steps:

The first client and the second client run on the same terminal equipment, the first client corresponds to 100 APIs, and the second client corresponds to 120 APIs (including 100 APIs corresponding to the first client);

Creating a mock configuration ID mapped with 120 APIs corresponding to the second client, for example, "00001", where the mock configuration IDs corresponding to the first client and the second client are both "00001";

Therefore, the target rule group pulled based on the mock configuration ID "00001" contains 120 pieces of rule data, and at this time, only 100 pieces of rule data needed by the first client can be enabled by the API configuration data;

The method and the system can meet different requirements of each client on the rule data while sharing the rule data through the design of the API configuration data.

Embodiment 3, a mock system, comprising a mock service, as shown in fig. 1, the mock service comprising:

A request receiving unit 100, configured to obtain an API request sent by a client through a proxy module, where the proxy module has an independent local domain name, and the proxy module only proxies the client;

Further:

further, the processing unit 120 includes:

A processing subunit 121, configured to extract client information from an API request, and further configured to read, based on the client information, a mock configuration ID and API configuration data of a corresponding client, where the API configuration data includes an API name and mock start information;

an extraction subunit 122, configured to obtain corresponding rule data based on the mock configuration ID, and obtain a target rule group;

And an execution subunit 123, configured to determine whether to perform a mock test based on the API configuration data and the API request, and when performing a mock test, obtain corresponding rule data from the target rule group based on the API request, and generate corresponding mock data based on the rule data.

This embodiment is an embodiment of the apparatus corresponding to embodiment 1, and since it is substantially similar to embodiment 1, the description is relatively simple, and the relevant points will be referred to in the description of the method embodiment.

Embodiment 4, referring to fig. 2, the notification receiving unit 130, the first pulling unit 140 and the second pulling unit 150 are added to the mock service of embodiment 3, and the rest is the same as embodiment 3;

A notification receiving unit 130, configured to receive a pull notification sent by the proxy module, where the pull notification includes client information;

a first pulling unit 140, configured to read a mock configuration ID of a corresponding client based on the client information;

And a second pulling unit 150, configured to pull, from the mock configuration service, corresponding rule data based on the mock configuration ID, generate and store a target rule group corresponding to the mock configuration ID, where the rule data includes a corresponding API name and a mock rule.

In this embodiment, the mock service is a localized mock service, which runs in each terminal device and is connected with the proxy module and the client signal in the terminal device.

This embodiment is an embodiment of the apparatus corresponding to embodiment 2, and since it is substantially similar to embodiment 2, the description is relatively simple, and the relevant points will be referred to in the description of the method embodiment.

Embodiment 5, a test system, as shown in fig. 3, includes:

the system comprises a mock system 10, a plurality of clients 20 and proxy modules 30 corresponding to the clients 20 one by one, wherein the corresponding clients 20 are in signal connection with the proxy modules 30, and each proxy module 30 is in signal connection with the mock system 10;

Each proxy module 30 has an independent local domain name, and the proxy module 30 is configured to receive an API request initiated by a corresponding client 20, send the API request to the mock system 10, and receive mock data returned by the mock system 10, and send the mock data to the corresponding client 20;

The mock system 10 is configured to receive an API request sent by each proxy module 30, determine whether to perform a mock test based on the API request, generate corresponding mock data when performing the mock test, and return the corresponding mock data to the proxy module 30.

In this embodiment, the proxy module 30 hives all requests initiated by the corresponding client 20 by means of an intermediary proxy, and the intermediary proxy may be implemented in various ways, for example, the proxy may be implemented based on the request hijacking of the local HTTP SERVER (DEVSERVER) or the proxy may be implemented based on the existing devserver (webpack-dev-server), which is not limited in this embodiment.

Further:

The mock system 10 comprises a mock configuration service 12 and a mock service 11 which are connected through signals;

the mock configuration service 12 is configured to configure rule data and packet data, where the rule data includes corresponding API information and mock rules, and the packet data includes a mock configuration ID and a plurality of API information mapped with the mock configuration ID.

The API information may be ID data having global uniqueness, where the ID data corresponds to the rule data one by one;

In the actual use process, the rule data further includes API names, and the API names in different rule data may be the same, i.e. a plurality of mock rules may be configured for a certain API in advance, i.e. a plurality of pieces of rule data corresponding to the API are configured, and the developer of the client 20 maps one piece of rule data with the corresponding mock configuration ID according to the actual test requirement;

In the prior art, the corresponding mock rule is often pulled independently based on the API name, and the API name has global uniqueness at the moment, namely, one API only has one corresponding mock rule;

According to the embodiment, through the design of the rule data and the grouping data, all the required rule data can be directly pulled based on the mock configuration ID, so that the rule data can be efficiently managed, the uniqueness of the rule data corresponding to the mock configuration ID is only needed, and the effective isolation of different rule data corresponding to the same API is realized through the mock configuration ID.

Further, each client 20 and each proxy module 30 operate in a terminal device, and the corresponding client 20 and proxy module 30 operate in the same terminal device, the mock system 10 provided in this embodiment includes the following three modes:

① . A centralized mock service 11 and a mock configuration service 12:

That is, the number of the mock services 11 is one, all the proxy modules 30 and all the clients 20 are in signal connection with the mock services 11, and when the mock services 11 are abnormal, all the clients 20 cannot realize the mock test, so that the stability of the test system is poor.

The mock service 11 in this scheme is used to perform the mock method disclosed in embodiment 1.

② . A localized mock service 11 and a centralized mock configuration service 12, wherein the mock service 11 corresponds to the terminal equipment one by one;

Referring to fig. 4, in this solution, the number of the mock services 11 is multiple, and the mock services 11 are in one-to-one correspondence with the terminal devices, that is, one mock service 11 is deployed on a terminal device, where the mock service 11 is signal-connected with all the proxy modules 30 and the clients 20 on the terminal device, and when the mock service 11 is abnormal, all the clients 20 on the terminal device cannot implement the mock test.

The mock service 11 in this scheme is used to perform the mock method disclosed in embodiment 1 or embodiment 2.

③ . A localized mock service 11 and a centralized mock configuration service 12, and the mock service 11 corresponds to the client 20 one by one;

That is, a plurality of mock services 11 are deployed on the terminal device, the proxy modules 30 on the terminal device where the mock services 11 are located are connected in a one-to-one correspondence, and when the mock services 11 are abnormal, the mock test is not affected by other clients 20.

Note that, the mock service 11 and the client 20 do not interact, and only the mock service 11 reads data from the client 20, and the connection between the mock service 11 and the client 20 is omitted in fig. 4 and 5.

Referring to fig. 6, the detailed test flow is described below based on the mock method disclosed in embodiment 2, taking a mock test performed by a client 20 as an example:

1. the agent module 30 (DEVSERVER) starts;

2. The proxy module 30 initiates a pull notification containing the client 20 information, that is, after the proxy module 30 is started, notifies the corresponding mock service 11 to pull the mock configuration ID of the corresponding client 20.

3. After receiving the pull notification, the mock service 11 reads a mock configuration ID of the corresponding client 20 based on the client 20 information;

4. the client 20 returns its mock configuration ID to the mock service 11;

5. the mock service 11 acquires corresponding rule data from the mock configuration service 12 based on the read mock configuration ID;

6. The mock configuration service 12 returns corresponding rule data to the mock service 11 based on the mock configuration ID, specifically, the mock configuration service 12 acquires API information mapped with the mock configuration ID based on the mock configuration ID, and returns the rule data to the corresponding mock service 11 based on the rule data corresponding to the API information;

7. the mock service 11 performs local persistent storage on the obtained rule data to obtain a target rule group, wherein the target rule group comprises all rule data mapped with a mock configuration ID;

that is, the target rule set is made independent of the client 20 and is persisted in the local disk of the terminal device where it is located, so as to enable different clients 20 in the terminal device where it is located to share the target rule set.

8. Client 20 initiates an API request;

9. The proxy module 30 proxies the API request, i.e., intercepts the API request and sends the API request to the mock service 11;

10. The mock service 11 reads a mock configuration ID of the corresponding client 20 based on the client 20 information in the API request;

11. the client 20 returns its mock configuration ID to the mock service 11;

12. The mock service 11 reads a corresponding target rule set based on the obtained mock configuration ID, namely, the target rule set stored to the local disk in a lasting manner in step 7;

13. The mock service 11 reads API configuration data of the corresponding client 20 based on the client 20 information in the API request;

14. The client 20 returns its API configuration data to the mock service 11;

15. Merging the target rule set (the target rule set read in step 12) and the API configuration data (the API configuration data returned by the client 20 in step 14) to obtain a merged rule set;

Namely, based on mock starting information in API configuration data, reserving rule data corresponding to the API in a starting state in a target rule group, and obtaining a merging rule group;

16. Generating mock data:

inquiring corresponding rule data from the combined rule group based on the API request, executing the mock rule in the rule data, and obtaining corresponding mock data;

When the merging rule group does not have corresponding rule data, the API request is not required to be subjected to mock test, and the API request is sent to a corresponding real object at the moment so as to obtain a corresponding response result;

when the API request relates to a service domain name, such as a Cookie, the proxy module 30 corresponds to the client 20 one by one, and the proxy module 30 has independent local domain names, and isolation of mock data is achieved based on the local domain name of the proxy module 30, so that mutual pollution of the mock data is effectively avoided.

17. The mock service 11 returns the generated mock data to the corresponding proxy module 30;

18. The proxy module 30 returns the generated mock data to the corresponding client 20.

In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described by differences from other embodiments, and identical and similar parts between the embodiments are all enough to be referred to each other.

It will be apparent to those skilled in the art that embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It should be noted that:

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

In addition, all equivalent or simple changes of the structure, characteristics and principle described in the conception of the present invention are included in the protection scope of the present invention. Those skilled in the art may make various modifications or additions to the described embodiments or substitutions in a similar manner without departing from the scope of the invention as defined in the accompanying claims.

Claims

1. A mock method comprising the steps of:

acquiring an API request sent by a client through a proxy module, wherein the proxy module has an independent local domain name and only proxies the client, and the API request contains client information;

judging whether to perform a mock test or not based on the API request, generating corresponding mock data when the mock test is performed, sending the mock data to the proxy module, and returning the proxy module to the client;

judging whether to perform a mock test based on the API request, and generating corresponding mock data when performing the mock test comprises the following steps of:

reading a mock configuration ID of a corresponding client based on the client information, and acquiring corresponding rule data based on the mock configuration ID to obtain a target rule group, wherein the rule data comprises a corresponding API name and a mock rule;

2. The mock method of claim 1 wherein:

Carrying out data combination on the API configuration data and the target rule set to obtain a corresponding combination rule set;

3. The mock method according to any one of claims 1 to 2, further comprising an initialization step, before the API request sent by the client is obtained through the proxy module, of:

reading a mock configuration ID of a corresponding client based on the client information;

And pulling corresponding rule data based on the mock configuration ID, generating a target rule group corresponding to the mock configuration ID, and storing the target rule group.

4. A mock system comprising a plurality of mock services, the mock services comprising:

The system comprises a request receiving unit, a proxy module and a client, wherein the request receiving unit is used for acquiring an API request sent by the client through the proxy module, the proxy module has an independent local domain name and only proxies the client, and the API request comprises client information;

The processing unit is used for judging whether to perform a mock test or not based on the API request, generating corresponding mock data when the mock test is performed, sending the mock data to the proxy module, and returning the proxy module to the client;

the processing unit includes:

The processing subunit is used for extracting client information from the API request, and is also used for reading a mock configuration ID and API configuration data of a corresponding client based on the client information, wherein the API configuration data comprises an API name and mock starting information;

5. The mock system of claim 4 wherein:

the mock configuration service is used for configuring rule data and grouping data, and the grouping data is used for indicating the mapping relation between the mock configuration ID and the rule data.

6. The mock system of claim 4 or 5 wherein,

The mock service also comprises a notification receiving unit, a client information receiving unit and a client information receiving unit, wherein the notification receiving unit is used for receiving a pull notification sent by the proxy module;

7. A test system, comprising:

Each proxy module is provided with an independent local domain name, and is used for receiving an API request initiated by a corresponding client, wherein the API request comprises client information, sending the API request to the mock system, receiving mock data returned by the mock system, and sending the mock data to the corresponding client;

The mock system is used for receiving the API requests sent by the proxy modules, judging whether to perform a mock test or not based on the API requests, generating corresponding mock data when performing the mock test, and returning to the corresponding proxy modules;

The step of generating corresponding mock data when the mock test is carried out is as follows:

8. The test system of claim 7, wherein:

9. The test system of claim 8, wherein: