CN116107899A

CN116107899A - MOCK interface management method, device, terminal equipment and storage medium

Info

Publication number: CN116107899A
Application number: CN202310146031.7A
Authority: CN
Inventors: 杨健勇; 陈耀
Original assignee: Shenzhen Fulin Technology Co Ltd
Current assignee: Shenzhen Fulin Technology Co Ltd
Priority date: 2023-02-01
Filing date: 2023-02-01
Publication date: 2023-05-12

Abstract

The method comprises the steps of storing a plurality of MOCK interface data which are input in advance according to a preset interface template in a management platform, and analyzing a test request to obtain a corresponding interface request path and an input parameter when responding to the test request of a test system; forwarding the request to the MOCK interface service so that the MOCK interface service performs primary matching in the stored MOCK interface data based on the interface request path to determine a corresponding target interface; performing secondary matching in a response main body of the target interface by using the input parameters to obtain a response return value; and returning the response return value to the test system as an interface response of the test request. According to the method and the device, interface response matching can be carried out in the stored multiple MOCK interface data according to specific test requests, and unified management of platforms of the MOCK interface data is facilitated.

Description

MOCK interface management method, device, terminal equipment and storage medium

Technical Field

The present disclosure relates to the field of development testing technologies, and in particular, to a method and apparatus for managing a MOCK interface, a terminal device, and a storage medium.

Background

Most application software currently has a scenario of interfacing with external third party software, so before the application software is in online operation, it is often necessary to provide a corresponding environment for development and testing of a software system of the third party, and the dock technology is a technology for self development testing, which is commonly used at present, wherein the dock technology mainly creates a virtual object for testing.

The existing scheme mainly comprises the steps that code personnel independently and correspondingly develop and deploy all interfaces requiring MOCK, however, in the actual development process, problems are often brought, for example, because each MOCK interface needs to be independently developed, the development workload is large; moreover, when the demand changes, the corresponding MOCK needs to be modified again and the online deployment is performed, so that the maintenance is not easy; in addition, the MOCK development can be realized only by the corresponding code basis, so that the technical requirement is high, and the method is not friendly to testers.

Disclosure of Invention

In view of the foregoing, embodiments of the present application provide a method, an apparatus, a terminal device, and a storage medium for managing a dock interface, so as to solve at least one of the above problems.

In a first aspect, an embodiment of the present application provides a dock interface management method, which is applied to a management platform, where a plurality of dock interface data that are pre-recorded according to a preset interface template are stored in the management platform, where the method includes:

responding to a test request of a test system, and analyzing the test request to obtain a corresponding interface request path and an incoming parameter;

forwarding the test request to a MOCK interface service so that the MOCK interface service performs primary matching in a plurality of stored MOCK interface data based on the interface request path to determine a corresponding target interface; wherein each interface of the plurality of MOCK interface data is configured with a respective response body; performing secondary matching in a response main body of the target interface by using the input parameters to obtain a response return value;

and returning the response return value to the test system as an interface response of the test request.

In some embodiments, if the target interface in the dock interface data is further configured with asynchronous callback information, after obtaining the target return value, the method further includes:

starting an asynchronous thread to utilize the asynchronous callback information to carry out asynchronous callback on the interface response; the asynchronous callback information comprises a callback address, a callback request mode and a callback parameter.

In some embodiments, if the asynchronous callback information further includes a configured callback delay, the method further includes:

and detecting whether the callback delay setting time is reached, and executing the step of starting the asynchronous thread when the callback delay setting time is reached so as to utilize the asynchronous callback information to carry out asynchronous callback on the interface response.

In some embodiments, the test request further includes a corresponding interface request manner, and the determining a corresponding target interface based on the primary matching of the interface request path in the stored MOCK interface data includes:

traversing the stored MOCK interface data according to the interface request path and a preset sequence to match request path fields, and taking the interface obtained by matching as a target interface; or alternatively, the process may be performed,

traversing the stored MOCK interface data according to the interface request path and the interface request mode according to a preset sequence so as to match a request path field and an interface request mode field, and taking the interface obtained by matching as a target interface.

In some embodiments, the response body includes response return values of the interfaces under different response conditions, and the performing secondary matching in the response return values of the target interfaces by using the incoming parameters to obtain response return values includes:

traversing the response main body of the target interface according to a preset sequence, so as to match the response conditions according to the input parameters, and obtaining corresponding response return values.

In some embodiments, the plurality of dock interface data is pre-entered and stored according to a preset interface template, including:

and receiving each interface configuration information input by a user in a preset interface template of a front-end page of the system, and transmitting each interface configuration information to the back end of the system for storage by using a form.

In a second aspect, an embodiment of the present application provides a dock interface management device, which is applied to a management platform, where a plurality of dock interface data that are pre-recorded according to a preset interface template are stored in the management platform, where the device includes:

the request analysis module is used for responding to a test request of the test system and analyzing the test request to obtain a corresponding interface request path and an incoming parameter;

the response matching module is used for forwarding the test request to a MOCK interface service so that the MOCK interface service can perform primary matching in a plurality of stored MOCK interface data based on the interface request path to determine a corresponding target interface; wherein each interface of the plurality of MOCK interface data is configured with a respective response body; performing secondary matching in a response main body of the target interface by using the input parameters to obtain a response return value;

and the response return module is used for returning the response return value to the test system as the interface response of the test request.

In some embodiments, the dock interface management apparatus further comprises:

the data configuration module is used for receiving each interface configuration information input by a user in a preset interface template of a front-end page of the system, and transmitting each interface configuration information to the rear end of the system for storage in a form mode.

In a third aspect, an embodiment of the present application provides a terminal device, where the terminal device includes a processor and a memory, where the memory stores a computer program, and the processor is configured to execute the computer program to implement the foregoing dock interface management method.

In a fourth aspect, embodiments of the present application provide a readable storage medium storing a computer program, where the computer program implements the above-mentioned MOCK interface management method when executed on a processor.

The embodiment of the application has the following beneficial effects:

according to the MOCK interface management method, a plurality of MOCK interface data are stored in the system in advance according to a unified interface template, and when an interface test request is needed, the test request is analyzed to obtain a corresponding interface request path and an input parameter; then, the test request is forwarded to a MOCK interface service, so that the MOCK interface service performs primary matching in stored MOCK interface data based on the interface request path to determine a corresponding target interface; performing secondary matching in a response main body of the target interface by using the input parameters to obtain a response return value; and finally, returning the response return value to the test system. The response matching method is combined with the pre-stored MOCK data, so that interface response matching can be realized in the stored multiple MOCK interface data according to specific test requests, unified management of the MOCK interface data is facilitated, and compared with the existing scheme of independent development and maintenance of the MOCK interface, the method can reduce workload of testers, improve test efficiency and the like.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered limiting the scope, and that other related 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 a structure of a MOCK interface management platform according to an embodiment of the present application;

FIG. 2 shows a first flowchart of a MOCK interface management method according to an embodiment of the present application;

FIG. 3 shows a second flowchart of a MOCK interface management method of an embodiment of the present application;

FIG. 4 shows a third flowchart of a MOCK interface management method of an embodiment of the present application;

fig. 5 shows a schematic structural diagram of a dock interface management device according to an embodiment of the present application;

fig. 6 shows a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments.

The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, as provided in the accompanying drawings, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, are intended to be within the scope of the present application.

In the following, the terms "comprises", "comprising", "having" and their cognate terms may be used in various embodiments of the present application are intended only to refer to a particular feature, number, step, operation, element, component, or combination of the foregoing, and should not be interpreted as first excluding the existence of or increasing the likelihood of one or more other features, numbers, steps, operations, elements, components, or combinations of the foregoing. Furthermore, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and should not be construed as indicating or implying relative importance.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which various embodiments of this application belong. The terms (such as those defined in commonly used dictionaries) will be interpreted as having a meaning that is identical to the meaning of the context in the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein in connection with the various embodiments.

Some embodiments of the present application are described in detail below with reference to the accompanying drawings. The embodiments described below and features of the embodiments may be combined with each other without conflict.

Because the existing MOCK interfaces are often independently developed and maintained, development workload is increased, and requirements on testers are high, in order to solve the problems, the application provides a scheme that the MOCK interfaces are uniformly managed in a platform mode, for different MOCK requirements, corresponding interface configuration is only required to be added at the front end of the platform according to a general interface template, and technical requirements on code development of the testers are greatly reduced; in addition, a plurality of MOCK interfaces can be compatible on the platform, testers can modify existing configuration and the like at any time according to actual test requirements, and corresponding configuration information can be stored at the rear end of the platform. When the test is needed, the platform can use the stored MOCK interface data to perform response matching so as to realize the test purpose.

The method for managing the MOCK interface is mainly based on platform implementation, and the main structure of the MOCK interface management platform is briefly described.

As shown in fig. 1, the MOCK interface management platform mainly includes a system front end and a system back end, where the system front end mainly provides some front end pages to interact with a user and display related content. In one embodiment, the method can be implemented by adopting javascript technology and the like, and further, the front-end data entry and the interaction with the back-end are performed by using a form in the javascript technology. The system back end serves as a core of the platform, can interact with the system front end, and provides functions of data storage, query matching, response and the like, and for example, in one embodiment, the system back end can be realized by adopting a sprintMVC framework and the like.

For example, the front page may include, but is not limited to, an index interface, a configuration interface, an interface data operation interface, and the like. Further, the index interface (i.e. index. Jsp page) is used as an entry, and other interfaces are mainly integrated and displayed, and embedded jumping is prompted; the configuration interface (i.e. setting.jsp page) can be used for the user to set the storage format of the data, the storage path, the maximum number of interfaces and other relevant configuration information; the interface data operation interface can comprise functions of adding, modifying, deleting and the like to the interface data so as to maintain the stored MOCK interface data according to requirements.

For the back end of the system, for example, the data input by the user at the front end of the system may be received and stored by providing a value= "/add", method=request method. In addition, an @ RequestMapping (value= "/wait", method=requestmethod.post) interface may be provided to modify the stored MOCK interface data.

Note that the dock interface data stored in the present application may include, but is not limited to, a request path (requestUrl), a request method (requestMethod), and a response body (responseCondition), where the response body includes a response condition (responseCondition), a response return value (resValue), and the like. Such information will be used to match the responses of the MOCK interface test requests. In addition, if some cases need to perform asynchronous feedback on the data, the foregoing MOCK interface data may further include a callback address (return request method), a callback parameter (return parameter), a callback delay, etc. to meet the asynchronous callback requirement. The callback delay is mainly performed by delay processing before callback, so that the callback operation time can be controlled, and the reliability of a system and the like are improved.

The method for managing a dock interface will be described below with reference to specific embodiments, in the case where a plurality of dock interface data have been stored in the management platform formed by the system front end and the system back end in the above-described manner.

Fig. 2 shows a flowchart of a dock interface management method according to an embodiment of the present application.

The MOCK interface management method exemplarily comprises the following steps:

step S110, responding to a test request of a test system, and analyzing the test request to obtain a corresponding interface request path and an incoming parameter.

When testing is required, the test system can send a corresponding test request, namely a MOCK request, to the management platform, and the platform returns an interface response corresponding to the stored MOCK interface data matching the test request to the test system according to the test request, so as to complete the MOCK test.

In one embodiment, after receiving the test request, the management platform may perform preliminary interception through @ request mapping (value= "/x"), and then perform parsing processing on the test request to obtain relevant information of the test request, which may include, but is not limited to, an interface request path, an interface request manner, an incoming parameter, and so on. The test request may then be forwarded to the MOCK interface module for further processing using forwarding techniques, such as may be implemented by the statement return "forward:/MOCK". It can be understood that these test requests can be conveniently forwarded to the MOCK interface service for unified processing by interception, and meanwhile, the relevant information of the requests can be stored in a static field so as to be called at any time in the subsequent steps.

Step S120, the test request is forwarded to a MOCK interface service, so that the MOCK interface service performs primary matching in a plurality of stored MOCK interface data based on the interface request path to determine a corresponding target interface; and performing secondary matching in a response main body of the target interface by using the input parameters of the test request to obtain a response return value.

The dock interface service refers to a functional module in the platform that supports operations such as dock interface response, for example, may be a thread that implements dock interface service, which is not limited herein. Illustratively, the intercepted test request is forwarded to the dock interface service, whereby a response match of the dock interface is made by the dock interface service. The response matching process is mainly divided into two stages, namely primary matching and secondary matching, wherein the primary matching is mainly used for determining a target interface, the secondary matching is used for acquiring a final MOCK response return, namely determining a specific response return value, and finally returning the obtained response return value to the interface.

In one embodiment, as shown in fig. 3, the primary matching in the step S120 includes:

and step S210, traversing the stored MOCK interface data according to the interface request path and a preset sequence to match request path fields, and taking the interface obtained by matching as a target interface.

Illustratively, according to the interface request path of the test request, for example, the stored multiple MCOK interface data may be traversed in a top-to-bottom order, and if the same interface data as the request path is matched, the same interface data is used as the required target interface by matching the request path (requestUrl) field therein, and the downward traversal may be stopped at this time to reduce the matching time. It will be appreciated that the above-mentioned preset sequence is not limited to top-down, but may be alternatively searched in a grouping batch or the like, which is not limited herein.

Optionally, in addition to considering the interface request path, the first matching may be performed in combination with the interface request mode, specifically, according to the interface request path and the interface request mode of the test request, the stored multiple MOCK interface data may be traversed according to a preset sequence, so as to perform matching of a request path (request url) field and a request mode (request method) field, and finally, an interface obtained by matching is taken as a target interface. It can be understood that in some scenes with more interfaces and more complex functions, considering the situations of multiplexing functions of some interfaces, the matching accuracy can be ensured by matching two fields.

Based on the primary matching, after determining the target interface, to obtain the final MOCK response, in one embodiment, the secondary matching in step S120 includes:

and step S210, traversing the response main body of the target interface according to a preset sequence to match response conditions according to the input parameters so as to obtain corresponding response return values.

It can be understood that when the MOCK interface data is stored, the stored data includes a response body corresponding to the interface, and the response body includes response return values of the interface under different response conditions. Then, during the secondary matching, the parameters which are input according to the test request are matched one by one, and if the parameters can be matched to the same response condition (recondition) as the input parameters, the corresponding response return value (resValue) is selected as a required return value. Similarly, if a matching result is obtained, the current traversal operation may be stopped to reduce the response time.

To facilitate an understanding of the above two-pass matching process, a specific example is described herein in connection with a custom MOCK interface data. For example, the data of the MOCK interface stored by the management platform includes: the ID (000) of the interface, the request method (request method) is POST, the request path (request url) is "/reach", and the corresponding response body, where the response body includes 2 response conditions (such as page= =1 and page= =2), and each response condition is configured with a respective response return value, and in order to avoid no return value due to a matching failure, a default response return value may be set to return when the incoming parameter does not match the corresponding response condition. In addition, the data of the MOCK interface may also include asynchronous callback information and the like.

Based on the above, when a certain test request is obtained, the test request can be parsed to obtain relevant information of the test request, such as an interface request path, an interface request mode, an incoming parameter and the like. Assuming that the interface request path of the test request is "/seach" and the interface request mode is POST, traversing the MOCK interface data stored in the platform according to the interface request path (/ seach) and the interface request mode (POST) of the test request, matching the 'requestUrl' and 'requestMethod' fields in the MOCK interface data, and stopping traversing downwards after the MOCK interface data are matched; then, traversing the 'response condition' field for the response body in the interface data, if the input parameter is page 1, then determining to be matched with { "response condition": "/page= 1", "value": "{ \code\2 }" in the response body, and taking { \code\2 } as a response return value; or, if page is 2, return { "code":0}. Of course, if there are no identical matches, the value of true may be chosen by default to return { "code":999}. After that, step S130 is performed.

And step S130, returning the response return value to the test system as an interface response of the test request. For example, the response return value obtained is written into the HttpServletResponse for interface response, and the response is returned to the test system.

As an alternative, if the MOCK interface data is further configured with asynchronous callback information, for example, the asynchronous callback information may include, but is not limited to, a callback address (return request method), a callback request mode (return request method), a callback parameter (return parameter template), and the like.

After obtaining the target return value, as shown in fig. 4, the method further includes:

and step S140, starting an asynchronous thread to carry out asynchronous callback on the interface response by utilizing the asynchronous callback information.

The asynchronous thread is used for realizing asynchronous callback, and can be applied to a scene simulating data asynchronous feedback of third-party software. It can be understood that relevant configuration of asynchronous callback information is performed when MOCK interface data is configured, so that the management platform can cover more test scenes, and the utilization rate of the platform is improved.

The management platform may analyze the asynchronous callback information of the target interface at the same time after the target return value is found by traversing, and if an effective callback address exists, the asynchronous Thread (i.e., new Thread ()) may be started to perform callback by using the asynchronous callback information, i.e., return the corresponding callback parameter to the callback address according to the callback request mode.

Further optionally, if the asynchronous callback information further includes configured callback delay, the method further includes:

and detecting whether the callback delay setting moment is reached, and executing the step of starting the asynchronous thread to perform asynchronous callback on the interface response by using the asynchronous callback information when the callback delay setting moment is reached.

It can be appreciated that by setting callback delay, the time of asynchronous feedback can be controlled, and more test scenes can be further covered.

The MOCK interface management method provided by the embodiment uniformly manages MOCK interface data through the platform, wherein the method comprises the steps of setting a general interface configuration template so that testers can define and maintain the MOCK interface, and setting a general matching flow so that interface response matching can be carried out. When testing is needed, after receiving a test request, the management platform performs matching through a two-stage MOCK interface response matching process according to the specific test request so as to obtain an interface response result. The management platform can manage and use a plurality of MOCK interfaces simultaneously, does not need to be deployed separately, and can save resources; in addition, for the testers, the workload of developing the MOCK interface is greatly reduced, the maintenance and the modification are convenient in real time, and when the modification is needed, the process of developing before deploying on line and finally using is not needed, and the interface response can be directly modified on the management platform, so that the method is convenient and quick.

Fig. 5 shows a schematic structural diagram of a dock interface management device according to an embodiment of the present application. The dock interface management device is exemplarily applied to the management platform in the above embodiment, where the management platform stores a plurality of dock interface data that are pre-recorded according to a preset interface template, and the device includes:

a request parsing module 110, configured to parse a test request of a test system in response to the test request to obtain a corresponding interface request path and an incoming parameter;

a response matching module 120, configured to forward the test request to a dock interface service, so that the dock interface service performs primary matching in the stored multiple dock interface data based on the interface request path, so as to determine a corresponding target interface; wherein each interface of the plurality of MOCK interface data is configured with a respective response body; performing secondary matching in a response main body of the target interface by using the input parameters to obtain a response return value;

and the response return module 130 is configured to return the response return value to the test system as an interface response of the test request.

Further, the dock interface management apparatus further includes:

The front end of the system is mainly used for providing a display interface, providing configuration information input and the like, while the back end of the system is used for interacting with the front end and performing test response and other operations of the MOCK interface in the above embodiment, and for implementation and composition of the front end of the system and the back end of the system, reference may be made to relevant contents in the method of the above embodiment, and description thereof will not be repeated here.

It can be understood that the system of the present embodiment corresponds to the dock interface management method of the above embodiment, and the options in the above embodiment are also applicable to the present embodiment, so the description is not repeated here.

Fig. 6 is a schematic structural diagram of a terminal device according to an embodiment of the present application. For example, the terminal device may be, but not limited to, a desktop computer, a notebook, a smart phone, a tablet, etc., and its existence is not limited. The terminal device comprises a processor 11 and a memory 12, wherein the memory 12 stores a computer program, and the processor 11 executes the computer program to enable the terminal device to execute the MOCK interface management method or each functional module in the MOCK interface management module so as to realize unified management of MOCK interface data, thereby not only meeting the interface response test requirement, but also reducing the workload of testers, reducing the technical requirements on the testers, and the like.

The processor 11 may be an integrated circuit chip with signal processing capabilities. The processor may be a general purpose processor including at least one of a central processing unit (Central Processing Unit, CPU), a graphics processor (Graphics Processing Unit, GPU) and a network processor (Network Processor, NP), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like that may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application.

The Memory 12 may be, but is not limited to, random access Memory (Random Access Memory, RAM), read Only Memory (ROM), programmable Read Only Memory (Programmable Read-Only Memory, PROM), erasable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), electrically erasable Read Only Memory (Electric Erasable Programmable Read-Only Memory, EEPROM), etc. The memory is used for storing a computer program, and the processor can correspondingly execute the computer program after receiving the execution instruction.

In addition, the present application further provides a readable storage medium for storing the computer program used in the terminal device, where the computer program, when executed on a processor, implements the dock interface management method of the foregoing embodiment, and the method includes:

responding to a test request of a test system, and analyzing the test request to obtain a corresponding interface request path and an incoming parameter; forwarding the test request to a MOCK interface service so that the MOCK interface service performs primary matching in a plurality of stored MOCK interface data based on the interface request path to determine a corresponding target interface; the MOCK interface data are input in advance according to a preset interface template, and each interface is configured with a corresponding response body; performing secondary matching in a response main body of the target interface by using the input parameters to obtain a response return value; and returning the response return value to the test system as an interface response of the test request.

It will be appreciated that the alternatives in the method of the above embodiment are equally applicable to the present embodiment and will not be repeated here.

The readable storage medium may be a nonvolatile storage medium or a volatile storage medium. For example, the readable storage medium may include, but is not limited to,: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other manners as well. The apparatus embodiments described above are merely illustrative, for example, of the flow diagrams and block diagrams in the figures, which illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules or units in the embodiments of the present application may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a smart phone, a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application.

Claims

1. The MOCK interface management method is characterized by being applied to a management platform, wherein a plurality of MOCK interface data which are input in advance according to a preset interface template are stored in the management platform, and the method comprises the following steps:

2. The dock interface management method according to claim 1, wherein if the target interface in the dock interface data is further configured with asynchronous callback information, after obtaining the target return value, further comprising:

3. The dock interface management method of claim 2, wherein if the asynchronous callback information further includes a configured callback delay, the method further comprises:

4. The dock interface management method according to claim 1, wherein the test request further includes a corresponding interface request manner, the determining a corresponding target interface based on the initial matching of the interface request path in the stored dock interface data includes:

traversing the stored MOCK interface data according to the interface request path and the interface request mode according to a preset sequence so as to match the request path field and the request mode field, and taking the interface obtained by matching as a target interface.

5. The dock interface management method according to claim 1, wherein the response body includes response return values of the interfaces under different response conditions, the performing secondary matching in the response return values of the target interfaces by using the incoming parameters, to obtain response return values, includes:

6. The dock interface management method according to any one of claims 1 to 5, wherein the plurality of dock interface data are pre-entered and stored according to a preset interface template, including:

7. A dock interface management device, which is characterized in that it is applied to a management platform, where a plurality of dock interface data that are input in advance according to a preset interface template are stored, and the device includes:

8. The dock interface management apparatus according to claim 7, further comprising:

9. A terminal device, characterized in that it comprises a processor and a memory, the memory storing a computer program, the processor being adapted to execute the computer program to implement the dock interface management method of any one of claims 1 to 6.

10. A readable storage medium, characterized in that it stores a computer program which, when executed on a processor, implements the MOCK interface management method according to any one of claims 1-6.