Mock Methods, Mock Systems, and Testing Systems

Abstract

The present invention discloses a Mock method, a mock system and a test system. The Mock method includes the following steps: obtaining 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; determining whether to perform a mock test based on the API request, generating corresponding mock data when performing the mock test, and sending the mock data to the proxy module, and the proxy module returns it to the client. The present invention designs that the proxy module corresponds to the client one by one, and each proxy module has an independent local domain name, effectively avoiding mutual contamination of mock data.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a mock method, a mock system, and a test system. Background Art

[0002] Due to different divisions of labor in modern software development systems, usually the client and the server are developed by different development roles to undertake the corresponding functions, that is, the client developers are responsible for the design and implementation of the UI interface, interaction logic, and data requests, and the server developers are responsible for the implementation of the business logic related to data persistent storage. In this R & D mode, the server developers need to provide APIs for the client developers to achieve the interaction between the client and the server.

[0003] Before the API development on the server side is completed, the API is unavailable. In theory, the client developers need to wait until the server-side API is completed before they can perform the docking and development of the API to ensure that the client and the server can achieve the same function according to the consistent goal. However, this development method is relatively slow; therefore, after the API design is completed and before the development is completed, the ability of the API is simulated through the mock method to assist the development of the client, realize the parallel development of the client and the server, and thus improve the overall R & D efficiency.

[0004] The APIs provided by the server are usually HTTP APIs, but the current mock solutions are not applicable to scenarios involving service domain names. Summary of the Invention

[0005] Aiming at the disadvantages of the large limitations of the mock solution in the prior art and its inapplicability to test scenarios involving service domain names, the present invention provides a mock technology and a test technology.

[0006] To solve the above technical problems, the present invention is solved by the following technical solutions:

[0007] A mock method includes the following steps:

[0008] Obtain the API request sent by the client through a proxy module. The proxy module has an independent local domain name, that is, the local domain names of each proxy module are different from each other, and the proxy module only proxies the client;

[0009] Based on the API request, determine whether to perform a mock test. When performing a mock test, generate corresponding mock data and send the mock data to the proxy module, and the proxy module returns it to the client.

[0010] As an implementable manner, before obtaining the API request sent by the client through the proxy module, an initialization step is further included, and the specific steps are:

[0011] Receive the pull notification sent by the receiving agent module, where the pull notification contains client information;

[0012] Read the mock configuration ID corresponding to the client based on the client information. The mock configuration ID is unique and is mapped to multiple rule data;

[0013] Pull the corresponding rule data based on the mock configuration ID, generate a target rule group corresponding to the mock configuration ID and save it. The rule data includes the corresponding API name and mock rules.

[0014] As an implementable manner, the API request contains client information. The steps of determining whether to perform a mock test based on the API request and generating corresponding mock data when performing a mock test are as follows:

[0015] Read the mock configuration ID corresponding to the client based on the client information, and obtain the corresponding rule data based on the mock configuration ID to obtain a target rule group;

[0016] Read the API configuration data of the client based on the client information. The API configuration data includes the API name and mock start information;

[0017] Determine whether to perform a mock test based on the API configuration data and the API request. When performing a mock test, obtain the corresponding rule data from the target rule group based on the API request, and generate corresponding mock data based on the rule data.

[0018] As an implementable manner:

[0019] Perform data merging on the API configuration data and the target rule group to obtain a corresponding merged rule group, that is, filter the rule data in the target rule group based on the API configuration data, so that the rule data in the obtained merged rule group are all the rule data of the APIs that need to be mock-tested in the corresponding client.

[0020] Query whether there is rule data corresponding to the API request in the merged rule group. When there is no such rule data, it is determined that no mock test is performed. When there is such rule data, it is determined that a mock test is performed, and corresponding mock data is generated based on the rule data.

[0021] The present invention also proposes a mock system, including a mock service, and the mock service includes:

[0022] A request receiving unit, 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;

[0023] A processing unit, configured to determine whether to perform a mock test based on the API request. When performing a mock test, generate corresponding mock data and send the mock data to the proxy module, and the proxy module returns it to the client.

[0024] As an implementable manner:

[0025] The mock system further includes a mock configuration service that is connected to each mock service by signals;

[0026] The mock configuration service is configured to configure rule data and grouping data, and the grouping data is used to indicate the mapping relationship between the mock configuration ID and the rule data;

[0027] The mock service further includes:

[0028] A notification receiving unit, configured to receive a pull notification sent by the proxy module, where the pull notification contains client information;

[0029] A first pulling unit, configured to read the mock configuration ID of the corresponding client based on the client information;

[0030] A second pulling unit, configured to pull corresponding rule data from the mock configuration service based on the mock configuration ID, generate a target rule group corresponding to the mock configuration ID and save it, where the rule data includes the corresponding API name and mock rules.

[0031] As an implementable manner, the processing unit includes:

[0032] A processing subunit, configured to extract client information from the API request, and further configured to cause the first pulling unit to read the mock configuration ID and API configuration data of the corresponding client based on the client information, where the API configuration data includes the API name and mock start information;

[0033] An extraction subunit, configured to obtain corresponding rule data based on the mock configuration ID to obtain a target rule group;

[0034] An execution subunit, configured to determine whether to perform a mock test based on the API configuration data and the API request. 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.

[0035] The present invention also provides a test system, including:

[0036] A mock system, a plurality of clients, and proxy modules corresponding to the clients one by one. The corresponding client and proxy module are connected by signals, and each proxy module is connected to the mock system by signals;

[0037] Each proxy module has an independent local domain name. The proxy module is used to receive an API request initiated by the corresponding client, send the API request to the mock system, and also receive mock data returned by the mock system and send the mock data to the corresponding client;

[0038] The mock system is used to receive the API requests sent by each proxy module, determine whether to perform a mock test based on the API requests, and generate corresponding mock data and return it to the corresponding proxy module when performing the mock test.

[0039] As an implementable mode:

[0040] The mock system includes a mock configuration service and a plurality of mock services connected by signals, and each mock service is connected to the mock configuration service by signals;

[0041] The mock configuration service is used to configure rule data and grouping data. The rule data includes corresponding API information and mock rules, and the grouping data includes a mock configuration ID and a plurality of API information mapped to the mock configuration ID.

[0042] As an implementable mode:

[0043] Each client and each proxy module run in a terminal device, and the corresponding client and proxy module run in the same terminal device;

[0044] The mock services correspond to the terminal devices one by one, or the mock services correspond to the clients one by one;

[0045] When the mock services correspond to the terminal devices one by one, the mock services are respectively connected to each client group and each proxy module running in the terminal device by signals;

[0046] When the mock services correspond to the clients one by one, the mock services are connected to the clients and the proxy modules corresponding to the clients by signals.

[0047] That is, the number of mock services in the present invention can be one or more.

[0048] Due to the adoption of the above technical solutions, the present invention has remarkable technical effects:

[0049] In the present invention, the proxy modules and the clients are in one-to-one correspondence, and each proxy module has an independent local domain name design, effectively avoiding the mutual contamination of mock data.

[0050] In the present invention, the design of separating the mock service and the mock configuration service combines the centralized mock configuration service and the localized mock service. The centralized mock configuration service can meet the sharing of mock data, and the localized mock service can improve the system stability.

[0051] In the present invention, the design of the mock configuration ID enables multiple clients to share a target rule group, effectively avoiding data redundancy.

[0052] In the present invention, the design of the API configuration data facilitates the mock test identification of API requests and accurately determines whether mock testing is required. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0054] Figure 1 is a schematic diagram of the module connection of the mock service in a mock system of the present invention;

[0055] Figure 2 is another schematic diagram of the module connection of the mock service in a mock system of the present invention;

[0056] Figure 3 is a schematic diagram of the module connection of a test system of the present invention;

[0057] Figure 4 is a schematic diagram of the module connection of the test system when the mock service 11 corresponds to the terminal device;

[0058] Figure 5 is a schematic diagram of the module connection of the test system when the mock service 11 corresponds to the client 20;

[0059] Figure 6 is a timing diagram of the mock test performed by the test system. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0060] The present invention will be further described in detail below in conjunction with embodiments. The following embodiments are explanations of the present invention, and the present invention is not limited to the following embodiments.

[0061] Embodiment 1. A mock method includes the following steps:

[0062] S100. Obtain 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 proxies the client;

[0063] S200. Determine whether to perform a mock test based on the API request. When performing a mock test, generate corresponding mock data and send the mock data to the proxy module, which returns it to the client.

[0064] When the mock data is associated with a domain name, the mock data will be isolated based on the local domain name of the proxy module.

[0065] The mock method provided by the prior art has relatively high limitations. When the mock test involves a service domain name, there is a phenomenon of data pollution, which is difficult to meet the test requirements in the current software development process;

[0066] In the prior art, each client sends an API request to a mock service (mockserver). When the mock service performs corresponding mocks based on a fixed domain name (mockserver.com), the mock data related to this fixed domain name of each client will cover and pollute each other;

[0067] Taking HTTP Cookie as an example for detailed introduction:

[0068] The first client sends an API request to simulate a Cookie. At this time, the mock service will write a corresponding Cookie, that is, cookie1, based on the fixed domain name (mockserver.com);

[0069] At this time, the second client also sends an API request to simulate a Cookie. At this time, the mock service will also write a corresponding Cookie, that is, cookie2, based on the fixed domain name (mockserver.com);

[0070] Since cookie1 and cookie2 are written under the same fixed domain name, cookie2 will cover cookie1, resulting in the mock data covering and polluting each other.

[0071] Regarding the problem that mock data related to service domain names can be mutually overwritten and polluted, different mockserver domain names can be enabled for different requests to isolate Cookies, so as to avoid mutual pollution of mock data. However, this solution requires a dedicated domain name to be enabled for each API, which has extremely high implementation costs and is not practical.

[0072] In the present invention, the proxy module and the client are in one-to-one correspondence, and the proxy module has an independent local domain name. When receiving an API request sent by the proxy module, mock data isolation can be achieved based on the local domain name of the proxy module, so that no matter what type of data is mocked, it will not cause any pollution to the actual service. Taking the mock of the above HTTP Cookie as an example, the Cookies corresponding to different clients will be isolated based on the local domain name of the corresponding proxy module.

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

[0074] S210. Read the mock configuration ID of the corresponding client based on the client information, and obtain the corresponding rule data based on the mock configuration ID to obtain a target rule group;

[0075] S220. Read the API configuration data of the client based on the client information, and the API configuration data includes the API name and mock start information;

[0076] S230. Determine whether to perform a mock test based on the API configuration data and the API request. When performing the mock test, obtain the corresponding rule data from the target rule group based on the API request, and generate corresponding mock data based on the rule data.

[0077] The rule data includes API information and corresponding mock rules. Executing the mock rules can obtain the corresponding mock data. This is prior art and will not be described in detail in this specification.

[0078] Since the rule data corresponding to the mock configuration ID is not all the rule data required by the corresponding client, during the actual test process, for the API requests corresponding to the APIs that have completed the mock test, the real response results need to be returned instead of mock data;

[0079] For example:

[0080] After the first client completes the mock test of the first API, the client developer changes the mock startup information of the first API to close to indicate that the mock test will no longer be performed. When the first client initiates an API request corresponding to the first API again, it is automatically determined not to perform the mock test based on the mock startup information.

[0081] The present invention designs API configuration data so that client developers can configure the API configuration data of the corresponding client according to actual needs. After the mock service receives the API request, it pulls the API configuration data of the corresponding client and determines whether to execute the mock test based on the API configuration data.

[0082] Furthermore, the specific steps of determining whether to perform a mock test based on the API configuration data and the API request in step S230 are:

[0083] S231, merging the API configuration data and the target rule group to obtain a corresponding merged rule group;

[0084] The API configuration data has a higher priority than the target rule group. The rule data in the target rule group is extracted based on the mock startup information in the API configuration data, so that the merged rule group contains the rule data corresponding to the API that the client needs to perform mock testing on.

[0085] S232, query whether there is rule data corresponding to the API request in the merged rule group, if not, determine not to perform mock testing, if yes, determine to perform mock testing, and generate corresponding mock data based on the rule data.

[0086] Embodiment 2: In Embodiment 1, an initialization step S300 is added, and the rest is the same as Embodiment 1. Specifically, before obtaining the API request sent by the client through the proxy module in step S100, the following steps are performed:

[0087] S310, receiving a pull notification sent by the proxy module, wherein the pull notification includes client information;

[0088] The client information is the client information of the client represented by the proxy module.

[0089] In this embodiment, each proxy module initiates a pull notification when it is initialized. Those skilled in the art may also enable each proxy module to initiate a pull notification at a fixed time according to actual needs, which will not be described in detail in this embodiment;

[0090] S320, reading the mock configuration ID of the corresponding client based on the client information;

[0091] The mock configuration ID is the mock configuration ID configured by the client staff and is unique.

[0092] The mock configuration ID is mapped to a number of rule data, and the rule data includes the corresponding API name and mock rule, where the mock rule is used to define the data mock method that the mock service can recognize and process and is stored in JSON data format.

[0093] S330. Pull the corresponding rule data based on the mock configuration ID, generate a target rule group corresponding to the mock configuration ID, and save it.

[0094] Note that those skilled in the art can set the mapping relationship between the mock configuration ID and the rule data according to actual needs. The client can have at least one mock configuration ID. The mock configuration IDs of each client in the same terminal device can be the same or different, and the present invention does not make detailed limitations on this.

[0095] The mock method disclosed in this embodiment is executed in the terminal device.

[0096] In this embodiment, the corresponding rule data is pulled in advance based on the mock configuration ID of the client, and the target rule group corresponding to the mock configuration ID is generated and saved to facilitate the extraction of the corresponding mock rule during the mock test.

[0097] Multiple clients and the corresponding proxy modules can run in one terminal device. There is overlap in the rule data required by each client in the same terminal device. If a mock configuration ID is configured separately for each client, and thus a corresponding target rule group is pulled separately for each client and saved, it will cause data redundancy.

[0098] Therefore, the client developer can construct one or more mock configuration IDs according to the APIs of all clients in the current terminal device to reduce data redundancy, and then configure API configuration data for each client to ensure that the rule data can be shared between different clients on the premise of normal mock testing.

[0099] For example:

[0100] All clients in the current terminal device share a mock configuration ID, and the API mapped to this mock configuration ID is the intersection of the APIs corresponding to all clients, specifically as follows:

[0101] The first client and the second client run on the same terminal device. The first client corresponds to 100 APIs, and the second client corresponds to 120 APIs (including the 100 APIs corresponding to the first client).

[0102] Create a mock configuration ID mapped to the 120 APIs corresponding to the second client, such as "00001". At this time, the mock configuration IDs corresponding to the first client and the second client are both "00001".

[0103] It can be seen that the target rule group pulled based on the mock configuration ID "00001" contains 120 rule data. At this time, 100 rule data required by the first client can be enabled through the API configuration data.

[0104] Moreover, through the design of the API configuration data, the present invention can meet the different requirements of each client for rule data while sharing the rule data.

[0105] Embodiment 3. A mock system includes a mock service, as Figure 1 shown. The mock service includes:

[0106] A request receiving unit 100, configured to obtain 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 proxies the client.

[0107] A processing unit, configured to determine whether to perform a mock test based on the API request. When performing a mock test, generate corresponding mock data, and send the mock data to the proxy module, and the proxy module returns it to the client.

[0108] Further:

[0109] The mock system further includes a mock configuration service that is signal-connected to each mock service;

[0110] The mock configuration service is configured to configure rule data and grouping data. The grouping data is used to indicate the mapping relationship between the mock configuration ID and the rule data;

[0111] Further, the processing unit 120 includes:

[0112] A processing subunit 121, configured to extract client information from the API request, and also configured to read the mock configuration ID and API configuration data corresponding to the client based on the client information. The API configuration data includes an API name and mock start information;

[0113] An extraction subunit 122, configured to obtain corresponding rule data based on the mock configuration ID, so as to obtain a target rule group;

[0114] An execution subunit 123, configured to determine whether to perform a mock test based on the API configuration data and the API request. 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.

[0115] This embodiment is the device embodiment corresponding to Embodiment 1. Since it is basically similar to Embodiment 1, the description is relatively simple. For related parts, refer to the partial description of the method embodiment.

[0116] Embodiment 4. Refer to Figure 2 , a notification receiving unit 130, a first pulling unit 140, and a second pulling unit 150 are added to the mock service of Embodiment 3, and the rest are the same as Embodiment 3;

[0117] The notification receiving unit 130 is configured to receive a pulling notification sent by the proxy module, where the pulling notification includes client information;

[0118] The first pulling unit 140 is configured to read the mock configuration ID of the corresponding client based on the client information;

[0119] The second pulling unit 150 is configured to pull corresponding rule data from the mock configuration service based on the mock configuration ID, generate a target rule group corresponding to the mock configuration ID, and save it. The rule data includes corresponding API names and mock rules.

[0120] In this embodiment, the mock service is a local mock service, which runs on each terminal device and is signal-connected to the proxy module and the client in the corresponding terminal device.

[0121] This embodiment is the device embodiment corresponding to Embodiment 2. Since it is basically similar to Embodiment 2, the description is relatively simple. For related parts, refer to the partial description of the method embodiment.

[0122] Embodiment 5. A test system, as Figure 3 shown, includes:

[0123] A mock system 10, several clients 20, and proxy modules 30 corresponding to the clients 20 one by one. The corresponding clients 20 and proxy modules 30 are signal-connected, and each proxy module 30 is signal-connected to the mock system 10;

[0124] Each proxy module 30 has an independent local domain name. The proxy module 30 is used to receive API requests initiated by the corresponding client 20, send the API requests to the mock system 10, and also receive mock data returned by the mock system 10 and send the mock data to the corresponding client 20;

[0125] The mock system 10 is used to receive API requests sent by each proxy module 30, determine whether to perform a mock test based on the API requests, and generate corresponding mock data and return it to the corresponding proxy module 30 when a mock test is performed.

[0126] In this embodiment, the proxy module 30 hijacks all requests initiated by the corresponding client 20 through the method of man-in-the-middle proxy. There are various implementations of this man-in-the-middle proxy. For example, it can be a request hijacking proxy based on a local HTTP Server (DevServer), or it can also be implemented based on an existing devserver (webpack-dev-server). This embodiment does not specifically limit it.

[0127] Furthermore:

[0128] The mock system 10 includes a mock configuration service 12 and a mock service 11 that are connected by signals;

[0129] The mock configuration service 12 is used to configure rule data and grouping data. The rule data includes corresponding API information and mock rules. The grouping data includes a mock configuration ID and multiple API information mapped to the mock configuration ID.

[0130] The above API information can be ID data with global uniqueness, and the ID data corresponds one-to-one with the rule data;

[0131] In actual use, the rule data also includes an API name. The API names in different rule data can be the same. That is, multiple mock rules can be pre-configured for a certain API, that is, several rule data corresponding to the API are configured. Developers of the client 20 can map one of the rule data to the corresponding mock configuration ID according to actual test needs;

[0132] In the prior art, mock rules are often pulled separately based on the API name. At this time, the API name has global uniqueness, that is, an API has only one corresponding mock rule;

[0133] In this embodiment, through the design of rule data and grouping data, various required rule data can be directly pulled based on the mock configuration ID, achieving efficient management of rule data. Moreover, in this embodiment, it is only necessary to ensure the uniqueness of the rule data corresponding to the mock configuration ID, and effective isolation of different rule data corresponding to the same API can be achieved through the mock configuration ID.

[0134] Further, each client 20 and each proxy module 30 run in the terminal device, and the corresponding client 20 and proxy module 30 run in the same terminal device. The mock system 10 provided in this embodiment includes the following three modes:

[0135] ①. Centralized mock service 11 and mock configuration service 12:

[0136] That is, the number of mock services 11 is one, and all proxy modules 30 and all clients 20 are signal-connected to this mock service 11. When the mock service 11 has an exception, all clients 20 cannot perform mock tests, and the stability of the test system is relatively poor.

[0137] In this solution, the mock service 11 is used to execute the mock method disclosed in Embodiment 1.

[0138] ②. Localized mock service 11 and centralized mock configuration service 12, and the mock service 11 corresponds to the terminal device one by one;

[0139] Refer to Figure 4 , in this solution, the number of mock services 11 is multiple, and the mock service 11 corresponds to the terminal device one by one. That is, one mock service 11 is deployed on the terminal device. At this time, the mock service 11 is signal-connected to all proxy modules 30 and clients 20 on the terminal device where it is located. When the mock service 11 has an exception, all clients 20 on the terminal device where it is located cannot perform mock tests.

[0140] In this solution, the mock service 11 is used to execute the mock method disclosed in Embodiment 1 or Embodiment 2.

[0141] ③. Localized mock service 11 and centralized mock configuration service 12, and the mock service 11 corresponds to the client 20 one by one;

[0142] That is, multiple mock services 11 are deployed on the terminal device, and the proxy modules 30 on the terminal device where the mock service 11 is located are connected one by one. When the mock service 11 has an exception, it does not affect other clients 20 to perform mock tests, and the stability of this solution system is the best.

[0143] In this solution, the mock service 11 is used to execute the mock method disclosed in Embodiment 1 or Embodiment 2.

[0144] Note that there is no interaction between the mock service 11 and the client 20. Only the mock service 11 reads data from the client 20. Figure 4 and Figure 5 the connection line between the mock service 11 and the client 20 is omitted in

[0145] Refer to Figure 6 , the following takes the mock method disclosed in Embodiment 2 as an example, and takes a mock test of a client 20 as an example to introduce the specific test process in detail:

[0146] 1. The proxy module 30 (DevServer) starts.

[0147] 2. The proxy module 30 initiates a pull notification containing the information of the client 20. That is, after the proxy module 30 starts, it notifies the corresponding mock service 11 to pull the mock configuration ID of the corresponding client 20.

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

[0149] 4. The client 20 returns its mock configuration ID to the mock service 11.

[0150] 5. The mock service 11 obtains the corresponding rule data from the mock configuration service 12 based on the read mock configuration ID.

[0151] 6. The mock configuration service 12 returns the corresponding rule data to the mock service 11 based on the mock configuration ID. Specifically, the mock configuration service 12 obtains the API information mapped to the mock configuration ID based on the mock configuration ID, and then returns the rule data to the corresponding mock service 11 based on the rule data corresponding to the API information.

[0152] 7. The mock service 11 performs local persistent storage on the obtained rule data to obtain a target rule group, and the target rule group contains each rule data mapped to the mock configuration ID.

[0153] That is, the target rule group is made independent of the client 20 and is persistently stored in the local disk of the terminal device where it is located, so as to realize the sharing of the target rule group by different clients 20 in the terminal device where it is located.

[0154] 8. The client 20 initiates an API request.

[0155] 9. The proxy module 30 proxies the API request, that is, intercepts the API request and sends the API request to the mock service 11;

[0156] 10. The mock service 11 reads the mock configuration ID corresponding to the client 20 based on the client 20 information in the API request;

[0157] 11. The client 20 returns its mock configuration ID to the mock service 11;

[0158] 12. The mock service 11 reads the corresponding target rule group based on the obtained mock configuration ID, that is, the target rule group persistently stored on the local disk in step 7;

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

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

[0161] 15. Merge the target rule group (the target rule group 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 group;

[0162] That is, based on the mock start information in the API configuration data, retain the rule data corresponding to the APIs in the target rule group that are in the start state to obtain a merged rule group;

[0163] 16. Generate mock data:

[0164] Query the corresponding rule data from the merged rule group based on the API request, execute the mock rules in the rule data to obtain the corresponding mock data;

[0165] When there is no corresponding rule data in the merged rule group, it means that the API request does not need to be mock - tested. At this time, the API request is sent to the corresponding real object to obtain the corresponding response result;

[0166] When the API request involves a service domain name, such as Cookie, the proxy module 30 corresponds to the client 20 one - by - one, and the proxy module 30 has an independent local domain name. The mock data is isolated based on the local domain name of the proxy module 30, effectively avoiding cross - contamination of mock data.

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

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

[0169] Each embodiment in this specification is described in a progressive manner. The key point of each embodiment is the difference from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other.

[0170] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a device, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0171] The present invention is described with reference to the flowcharts and / or block diagrams of methods, terminal devices (systems), and computer program products according to the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as the combination of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal devices generate a device for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0172] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0173] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device, so that a series of operation steps are executed on the computer or other programmable terminal device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable terminal device provide steps for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0174] It should be noted that:

[0175] Although the preferred embodiments of the present invention have been described, additional changes and modifications can be made by those skilled in the art once they learn the basic creative concept. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications that fall within the scope of the present invention.

[0176] In addition, equivalent or simple changes made according to the structure, features, and principles described in the inventive concept of this patent are all included within the protection scope of this patent. Those skilled in the technical field to which the present invention pertains can make various modifications or supplements to the described specific embodiments or use similar ways for substitution, as long as they do not deviate from the structure of the present invention or exceed the scope defined by this claims book, they should all fall within the protection scope of the present invention.

Claims

1. A mock method, characterized in that, Including the following steps: Obtain the API request sent by the client through the proxy module. The proxy module has an independent local domain name, and the proxy module only proxies the client. The API request contains client information; Based on the API request, determine whether to perform a mock test. When performing a mock test, generate corresponding mock data and send the mock data to the proxy module, which returns it to the client; Among them, the step of determining whether to perform a mock test based on the API request and generating corresponding mock data when performing a mock test is: Read the mock configuration ID of the corresponding client based on the client information, and obtain the corresponding rule data based on the mock configuration ID to obtain a target rule group. The rule data includes the corresponding API name and mock rules; Read the API configuration data of the client based on the client information. The API configuration data includes the API name and mock start information; Based on the API configuration data and the API request, determine whether to perform a mock test. When performing a mock test, obtain the corresponding rule data from the target rule group based on the API request, and generate corresponding mock data based on the rule data.

2. The mock method according to claim 1, wherein: Perform data merging on the API configuration data and the target rule group to obtain a corresponding merged rule group; Query whether there is rule data corresponding to the API request in the merged rule group. When there is no such rule data, determine not to perform a mock test. When there is such rule data, determine to perform a mock test and generate corresponding mock data based on the rule data.

3. The mock method according to any one of claims 1 to 2, characterized in that, Before obtaining the API request sent by the client through the proxy module, an initialization step is further included. The specific steps are: Receive the pull notification sent by the proxy module. The pull notification contains client information; Read the mock configuration ID of the corresponding client based on the client information; Pull the corresponding rule data based on the mock configuration ID, generate a target rule group corresponding to the mock configuration ID and save it.

4. A mock system, characterized in that, Including several mock services, the mock services include: A request receiving unit for obtaining the API request sent by the client through the proxy module. The proxy module has an independent local domain name, and the proxy module only proxies the client. The API request contains client information; A processing unit for determining whether to perform a mock test based on the API request. When performing a mock test, generate corresponding mock data and send the mock data to the proxy module, which returns it to the client; The processing unit includes: A processing subunit for extracting client information from the API request, and also for reading the mock configuration ID and API configuration data of the corresponding client based on the client information. The API configuration data includes the API name and mock start information; An extraction subunit, configured to obtain corresponding rule data based on the mock configuration ID to obtain a target rule group; An execution subunit, configured to determine whether to perform a mock test based on the API configuration data and the API request. 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.

5. The mock system according to claim 4, wherein: The mock system further includes a mock configuration service signal-connected to each mock service; The mock configuration service is configured to configure rule data and grouping data, and the grouping data is used to indicate the mapping relationship between the mock configuration ID and the rule data.

6. The mock system according to claim 4 or 5, wherein The mock service further includes: a notification receiving unit, configured to receive a pull notification sent by the proxy module, where the pull notification includes client information; A first pull unit, configured to read the mock configuration ID of the corresponding client based on the client information; A second pull unit, configured to pull corresponding rule data from the mock configuration service based on the mock configuration ID, generate a target rule group corresponding to the mock configuration ID, and save it. The rule data includes corresponding API names and mock rules.

7. A test system, characterized in that, including: A mock system, a plurality of clients, and proxy modules corresponding to the clients one by one. The corresponding clients and proxy modules are signal-connected, and each proxy module is signal-connected to the mock system; Each proxy module has an independent local domain name. The proxy module is configured to receive an API request initiated by the corresponding client, where the API request includes client information, and send the API request to the mock system, and is further configured to receive the mock data returned by the mock system and send the mock data to the corresponding client; The mock system is configured to receive the API requests sent by each proxy module, determine whether to perform a mock test based on the API requests, and generate corresponding mock data and return it to the corresponding proxy module when performing a mock test; wherein, the step of the mock system determining whether to perform a mock test based on the API request and generating corresponding mock data when performing a mock test is: Reading the mock configuration ID of the corresponding client based on the client information, and obtaining corresponding rule data based on the mock configuration ID to obtain a target rule group. The rule data includes corresponding API names and mock rules; Reading the API configuration data of the client based on the client information, where the API configuration data includes an API name and mock start information; Determining whether to perform a mock test based on the API configuration data and the API request. When performing a mock test, obtaining corresponding rule data from the target rule group based on the API request, and generating corresponding mock data based on the rule data.

8. The test system according to claim 7, wherein: The mock system includes a mock configuration service and a plurality of mock services that are signal-connected. Each mock service is signal-connected to the mock configuration service; The mock configuration service is used to configure rule data and grouping data. The rule data includes corresponding API information and mock rules, and the grouping data includes a mock configuration ID and a plurality of API information mapped to the mock configuration ID.

9. The test system according to claim 8, wherein: Each client and each proxy module run in a terminal device, and the corresponding client and proxy module run in the same terminal device; The mock services correspond to the terminal devices one by one, or the mock services correspond to the clients one by one; When the mock services correspond to the terminal devices one by one, the mock services are respectively signal-connected to each client group and each proxy module running in the terminal device; When the mock services correspond to the clients one by one, the mock services are signal-connected to the clients and the proxy modules corresponding to the clients.

Images