MOCK processing methods, devices, electronic equipment and storage media for all scenarios

Abstract

This disclosure provides a full-scenario MOCK processing method, apparatus, electronic device, and storage medium. First, MOCK recording is initiated, with a recording engine intercepting and recording the entire process of requests to the target service. The recording information obtained by the recording engine is then output online by the recording server. Next, after obtaining the Wiremock mappings file, response template file, and response replacement rule file based on the recorded information, a Wiremock service for the MOCK management platform can be started based on these files. Furthermore, the MOCK management platform processes the Wiremock service in a configured operating mode, including either a normal mode or a microservice mode. Based on this invention, a full-scenario MOCK solution is achieved using Wiremock + MOCK recording + MOCK management platform.

Description

Technical Field

[0001] This disclosure relates to the field of software technology, and more specifically, to a method, apparatus, electronic device, and storage medium for handling MOCK in all scenarios. Background Technology

[0002] With the rapid increase in user numbers and business growth in recent years, ensuring high-quality delivery has become a significant challenge for development and testing teams. Many development teams adopt service-oriented architectures to reduce coupling between services and modules, especially in the era of microservices and other complex architectures. However, this has led to increased costs for development and testing teams due to issues such as handling external dependencies. Furthermore, teams frequently encounter the following difficulties and problems in their daily work:

[0003] 1) When upstream and downstream services with dependencies need to be developed in parallel, the upstream and downstream services need to decouple their dependencies through Mock and finally achieve integration;

[0004] 2) When conducting performance testing, the external services we rely on need to mock various business scenarios or complex data. How can we efficiently and quickly capture and create data?

[0005] 3) Development or testing environments need to be switched to Mock environments frequently as needed. Too much operation and maintenance support will inevitably lead to communication and manpower costs. A unified platform is needed to enable testing, development, and operation and maintenance to quickly switch to Mock environments.

[0006] There are many Mock service solutions on the market, but most of them only solve a portion of the scenarios, and there is no unified solution for the problems mentioned above. Summary of the Invention

[0007] In view of this, to solve the above problems, this disclosure provides a full-scenario MOCK processing method, device, electronic device, and storage medium, the technical solution of which is as follows:

[0008] A method for handling MOCKs across all scenarios, the method comprising:

[0009] Start MOCK recording and output the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of the request to the target service.

[0010] Obtain the Wiremock mappings file, response template file, and response replacement rule file written based on the recorded information, and start the Wiremock service for the MOCK management platform based on the obtained files;

[0011] The Wiremock service is processed through the MOCK management platform in a configured operating mode, which includes normal mode or microservice mode.

[0012] Preferably, the online output of the recording information obtained by the recording engine through the recording server includes:

[0013] The recording engine is deployed in the target service, and the target address corresponding to the target service is modified to point to the MOCK management platform;

[0014] The recording engine is associated with the target service by using the attach command;

[0015] The recording server modifies the recording configuration information of the MOCK recording and pushes the recording configuration information to the recording engine.

[0016] The recording engine intercepts and records the entire process of requests to the target address based on the recording configuration information, and the recording information obtained by the recording engine is output online through the recording server.

[0017] Preferably, the method further includes:

[0018] The recording server outputs the health status and application status reported by the target service online.

[0019] Preferably, the method further includes:

[0020] While obtaining the mapping file, the response template file, and the response replacement rule file, obtain the documentation for the MOCK script.

[0021] Preferably, the method further includes:

[0022] The MOCK management platform provides online statistics on the health status and external service performance of the Wiremock service.

[0023] A full-scene MOCK processing device, the device comprising:

[0024] The recording startup module is used to start MOCK recording and output the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of the request to the target service.

[0025] The service startup module is used to obtain the Wiremock mapping file, response template file and response replacement rule file written based on the recorded information, and to start the Wiremock service for the MOCK management platform based on the obtained files;

[0026] The service operation module is used to process the Wiremock service through the MOCK management platform in a configured operation mode, which includes normal mode or microservice mode.

[0027] Preferably, the recording startup module, used for outputting recording information obtained by the recording engine online via the recording server, is specifically used for:

[0028] The recording engine is deployed in the target service, and the target address corresponding to the target service is modified to point to the MOCK management platform; the recording engine is associated with the target service using the attach command; the recording configuration information of the MOCK recording is modified by the recording server and pushed to the recording engine; the recording engine intercepts and records the entire process of requests to the target address based on the recording configuration information, and the recording information obtained by the recording engine is output online by the recording server.

[0029] Preferably, the device further includes:

[0030] The information output module is used to output the health status and application status reported by the target service online through the recording server.

[0031] An electronic device includes: at least one memory and at least one processor; the memory stores an application program, and the processor calls the application program stored in the memory, the application program being used to implement the full-scene MOCK processing method.

[0032] A storage medium storing computer program code, which, when executed, implements the full-scene MOCK processing method.

[0033] Compared to existing technologies, the beneficial effects achieved by this disclosure are as follows:

[0034] This disclosure provides a full-scenario MOCK processing method, apparatus, electronic device, and storage medium. First, MOCK recording is initiated, with a recording engine intercepting and recording the entire process of requests to the target service. The recording information obtained by the recording engine is then output online by the recording server. Next, after obtaining the Wiremock mappings file, response template file, and response replacement rule file based on the recorded information, a Wiremock service for the MOCK management platform can be started based on these files. Furthermore, the MOCK management platform processes the Wiremock service in a configured operating mode, including either normal mode or microservice mode. Based on this invention, a full-scenario MOCK solution is implemented using Wiremock + MOCK recording + MOCK management platform, which can effectively simplify the workload of various teams and significantly reduce the complexity of daily development, testing, and maintenance work and processes, thereby improving work efficiency. Attached Figure Description

[0035] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0036] Figure 1 A flowchart illustrating the full-scenario MOCK processing method provided in this embodiment of the disclosure;

[0037] Figure 2 A partial flowchart of the full-scenario MOCK processing method provided in the embodiments of this disclosure;

[0038] Figure 3 A global flowchart of the full-scenario MOCK provided in this embodiment of the disclosure;

[0039] Figure 4 A schematic diagram of the structure of the full-scenario MOCK processing device provided in the embodiments of this disclosure;

[0040] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0041] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0042] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0043] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0044] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0045] To facilitate understanding of this disclosure, some concepts related to this disclosure will be explained below:

[0046] MOCK is a virtual object defined to ensure that a test passes.

[0047] Wiremock is an open-source emulator (service) based on the HTTP protocol.

[0048] JVM SANDBOX REPEATER is a traffic recording and playback tool based on Alibaba's open-source platform.

[0049] A Java agent is a JDK technique for modifying bytecode without restarting the application.

[0050] The ATTACH API is a technique for dynamically loading proxy classes.

[0051] The Java API is an interface based on Java.

[0052] See Figure 1 , Figure 1 The present disclosure provides a flowchart of a full-scene MOCK processing method, which includes the following steps:

[0053] S10, start MOCK recording, and output the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of the request to the target service.

[0054] In this embodiment, to facilitate the writing of MOCK scripts, JVM SANDBOX REPEATER is used as the recording engine for MOCK recording, and its corresponding server is further developed to serve as the recording server for MOCK recording. The secondary-developed JVM SANDBOX REPEATER server is integrated into the MOCK management platform.

[0055] Therefore, the traffic recording tool, which consists of a recording engine and a recording server, serves as the core of the recording process. It is non-intrusive, pluggable, highly versatile, and easily scalable. Moreover, this tool can not only intercept common HTTP requests, but also intercept and record TCP, UDP, Dubbo, and other protocol messages and various methods.

[0056] The recording engine is composed of the JVM SANDBOX REPEATER plugin. Its working principle involves using JAVAAGENT and calling the ATTACH API. By specifying the JAVA AGENT to the REPEATER AGENT package and the ATTACH to the JAVA process ID in the startup script, it uses dynamic proxy mode with bytecode injection techniques such as ASM to intercept the entire process of requests to the target service or even methods. The intercepted recording information is then uploaded to the recording server. Furthermore, JVM SANDBOX REPEATER supports recording multiple protocols and is easy to deploy and extend.

[0057] The recording server has an online traffic function. When the recording engine processes a request, it sends the intercepted request and response recording information to the recording server, which then displays it in the online traffic.

[0058] In the specific implementation process, step S10, "outputting the recording information obtained by the recording engine online through the recording server," can be performed using the following steps, as shown in the flowchart below. Figure 2 As shown:

[0059] S101, deploy the recording engine in the target service, and modify the target address corresponding to the target service to point to the MOCK management platform.

[0060] In this embodiment of the disclosure, MOCK recording is initiated, and the recording configuration is configured according to specific business requirements. The recording engine operates the business system or interface to record the required business requests, return information, and dependent information, thereby obtaining recording information.

[0061] First, the relevant components of the recording engine need to be deployed to the target service, and the address of the target service needs to be modified so that the target address points to the MOCK management platform.

[0062] S102 associates the recording engine with the target service using the attach command.

[0063] Secondly, by using the attach command, the recording engine can be dynamically attached to the target service, thus associating the recording engine with the target service.

[0064] S103 modifies the recording configuration information of MOCK recording through the recording server and pushes the recording configuration information to the recording engine.

[0065] Next, modify the MOCK recording configuration management on the recording server and push the configuration to the recording engine with one click.

[0066] In this embodiment of the disclosure, the recording server also has configuration management functions. The recording server can configure the recording configuration information for the target.

[0067] MOCK recording not only helps developers / testers quickly understand an interface and its internal call chain information, but also provides data support for writing MOCK scripts based on the recorded request return information.

[0068] See Table 1 below, which provides an example of recording configuration information.

[0069]

[0070] S104 intercepts the entire process of requests to the recording target address based on the recording configuration information through the recording engine, and outputs the recording information obtained by the recording engine online through the recording server.

[0071] Finally, the recording engine records the entire request process to the target address based on the recording configuration information, thereby obtaining recording information, and uploads the recording information to the recording server, which then outputs the recording information online in the online process interface.

[0072] Based on this, the recording server also has the function of recording applications. The full-scenario MOCK processing method provided in this embodiment of the disclosure further includes the following steps:

[0073] The health status and application status reported by the target service are recorded online by the server.

[0074] In this embodiment of the disclosure, when the upstream service, i.e. the target service, starts, it will automatically report its own health status and application status. The application status can be configured through environment variables, and the recording server can output the monitoring status and application status of the target service online in the recording application interface.

[0075] S20: Obtain the Wiremock mappings file, response template file, and response replacement rule file written based on the recorded information, and start the Wiremock service for the MOCK management platform based on the obtained files.

[0076] Wiremock offers features such as HTTP response stub, URL, header, and body content pattern matching, request condition proxying, request authentication, fault injection, stateful behavior simulation, and fluent configuration via Java API, JSON files, and JSON over HTTP, covering most mock use cases. In this embodiment, Wiremock is used as a service simulator to decouple complex business logic from services. A mapping file (directory 'mappings') defines request matching rules. Requests are routed to the corresponding response template file (directory '_files') and a response replacement rule file (currently supporting XSL and Java script formats) based on these mapping files. The mapping files, response template files, and response replacement rule files together form a complete Wiremock service.

[0077] To address this, by referring to the steps above to intercept and record the recording information, as well as the business scenarios that need to be covered, you can write Wiremock mapping files, response template files, and response replacement rule files (you can also add corresponding rule jar packages in the lib package). Configure the data reporting to the MOCK management platform address and start the Wiremock service on the startup script, that is, modify the startup script to start and point it to the MOCK management platform and start the Wiremock service.

[0078] While Wiremock offers advantages such as matching HTTP response stubs, URLs, header and body content patterns, request condition proxying, request authentication, fault injection, stateful behavior simulation, and fluent configuration via Java API, JSON files, and JSON over HTTP, it also has some drawbacks for full-scenario mock applications. For example, the XSL language is difficult to understand, and related documentation is scarce, making it difficult to extend and maintain; the inability to communicate with the mock management service leads to the inability to monitor mock status. To address these shortcomings, this disclosure adds a mock script documentation (MOCK DOC) feature. The full-scenario mock processing method also includes the following steps:

[0079] While retrieving the mapping files, response template files, and response replacement rule files, also retrieve the documentation for the MOCK script.

[0080] To make MOCK scripts easier to understand, this disclosure includes a MOCK DOC to explain them. The explanation elements include the business scenarios supported by the script, script description, matching rules, and examples of requests and responses. The MOCK DOC uses Markdown syntax to supplement the explanation of the script's use cases and detailed parameters. Markdown syntax is convenient, efficient, has stronger visual logic, and is easy to maintain, making it more user-friendly for both editors and users.

[0081] The S30 handles the Wiremock service through the MOCK management platform in a pre-configured operating mode, which includes normal mode or microservice mode.

[0082] In this embodiment, the MOCK management platform can handle MOCK switching, using the MOCK switching function to allow for one-click switching to different environments based on varying test scopes. MOCK switching operates in two modes: normal mode and microservice mode.

[0083] The normal mode adds a proxy service between the client and the mock and real environments. By modifying the proxy service configuration, users can control whether the proxy service forwards to the mock or real environment, achieving one-click switching between the mock and real environments. Currently supported protocols include TCP, UDP, and HTTP.

[0084] The microservice model first uses Wiremock's MOCK service to implement simulated microservices. Then, by operating the microservice registry, it manages the online / offline status of services between the real and MOCK services based on the current state of user operations, achieving one-click switching between the MOCK and real environments.

[0085] This allows for easy expansion and contraction of the testing scope, enabling the testing environment to be reused throughout its entire lifecycle with a single configuration.

[0086] To address this, either a normal mode or a microservice mode is selected based on the proxy requirements. The MOCK management platform then handles the Wiremock service according to the chosen operating mode. In normal mode, the MOCK address and the real environment address need to be added and switched on the MOCK management platform, while in microservice mode, the registry address of the target service is configured. At this point, the MOCK service is integrated into the MOCK management platform and can function normally.

[0087] Based on this, the MOCK management platform can also be responsible for MOCK health reporting and usage statistics. In this embodiment, the full-scenario MOCK processing method further includes the following steps:

[0088] The MOCK management platform allows for online monitoring of the health status and external service performance of the Wiremock service.

[0089] In this embodiment, the MOCK management platform also provides operational monitoring functionality, enabling the collection of the health status of the Wiremock service and the statistical analysis of its external service status, thereby covering all use cases of MOCK. Specifically, the health status of the Wiremock service can be displayed in a multi-dimensional manner, showing the usage, number of services, and call volume of the currently associated MOCK services; the external service status of the Wiremock service can be displayed through application call statistics, call volume ranking, latency ranking, and call IP ranking. Furthermore, the MOCK management platform can be extended to implement Java to compensate for the shortcomings of XSL.

[0090] The above functions cover all scenarios of MOCK usage, achieving the effect of one-time configuration for multiple reuse, which speeds up work efficiency while saving costs.

[0091] See Figure 3 , Figure 3 This is a global flowchart of the full-scenario MOCK provided in the embodiments of this disclosure. It should be noted that... Figure 3The server-side component is integrated into the MOCK management platform. Therefore, the MOCK management platform provides server-side recording applications, configuration management, and online workflow functions through an interactive interface. Furthermore, it also offers its own runtime monitoring, MOCK switching (i.e., switching runtime modes), script writing (i.e., writing mapping files, response template files, response replacement rule files, and MOCK script documentation), script management (i.e., managing mapping files, response template files, response replacement rule files, and MOCK script documentation, such as creating, modifying, and deleting), and runtime configuration (i.e., configuring runtime modes). In addition, the MOCK management platform can store information related to these functions in a relevant database.

[0092] See also Figure 3 For MOCK recording, the upstream service (the target service is the upstream service) and the recording engine can be associated in the form of ATTACH (i.e., attach) or AGENT. The recording engine intercepts and records the entire process of the upstream service's requests, obtains the recording data, and uploads it to the MOCK management platform.

[0093] See also Figure 3 The MOCK management platform allows users to switch between two operating modes: normal mode and microservice mode.

[0094] For normal mode (i.e.) Figure 3 The MOCK service (or MOCK service in general) handles common web requests and switches between services through routing. Specifically, before use, the user clicks the MOCK toggle button on the page. Upon successful operation, the MOCK service automatically modifies its routing configuration to specify whether the request should be sent to the Wiremock extension or a downstream service for processing. When an upstream service sends a request to the MOCK service, the MOCK service routes the request according to the previous MOCK switching operation, thus achieving the MOCK switch.

[0095] For microservices (i.e.) Figure 3 The MOCK microservice (in the context of microservices) is specifically designed for microservice frameworks. It switches between services by operating on the registry center. Specifically, before use, the user clicks the MOCK button on the page. Upon successful operation, the MOCK microservice takes the selected service offline and brings the specified microservice plugin or downstream service online. When an upstream service makes a request, the currently online service (microservice plugin or downstream service) will handle the request, thus achieving MOCK switching.

[0096] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The full-scenario MOCK processing method provided in this disclosure uses a repeater as the recording engine to record interface service applications, an extended WireMock as the MOCK service, a MOCK DOC format to explain the purpose of the MOCK script, MOCK runtime management to manage proxy services and one-click switching, MOCK statistics to quantify MOCK service capabilities, and integration with DevOps pipelines to provide MOCK service capabilities for automated testing. In summary, it currently covers all scenarios used in MOC (Multi-Card Execution) and provides convenience and improves work efficiency in daily development and testing.

[0098] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0099] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0100] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0101] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0102] Based on the full-scene MOCK processing method provided in the above embodiments, this disclosure provides an apparatus for executing the above full-scene MOCK processing method, the structural schematic diagram of which is shown below. Figure 4 As shown, it includes:

[0103] The recording startup module 10 is used to start MOCK recording. It outputs the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of the request to the target service.

[0104] Service startup module 20 is used to obtain the Wiremock mappings file, response template file and response replacement rule file written based on the recorded information, and to start the Wiremock service for the MOCK management platform based on the obtained files;

[0105] Service running module 30 is used to process Wiremock services through the MOCK management platform in a configured running mode, including normal mode or microservice mode.

[0106] Optionally, the recording startup module 10, used to output the recording information obtained by the recording engine online through the recording server, is specifically used for:

[0107] Deploy the recording engine in the target service and modify the target address of the target service to point to the MOCK management platform; associate the recording engine with the target service using the attach command; modify the recording configuration information of MOCK recording through the recording server and push the recording configuration information to the recording engine; intercept the entire process of the recording engine's request to the target address based on the recording configuration information, and output the recording information obtained by the recording engine online through the recording server.

[0108] Optionally, the above-mentioned device further includes:

[0109] The information output module is used to record and output the health status and application status reported by the target service online.

[0110] Optionally, service startup module 20 is also used for:

[0111] While retrieving the mapping files, response template files, and response replacement rule files, also retrieve the documentation for the MOCK script.

[0112] Optionally, the above-mentioned device further includes:

[0113] The information statistics module is used to statistically analyze the health status and external service status of the Wiremock service online through the MOCK management platform.

[0114] It should be noted that the detailed functions of each module in this embodiment can be found in the corresponding disclosure section of the above-mentioned user distributed authentication method embodiment, and will not be repeated here.

[0115] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0116] Based on the full-scenario MOCK processing method provided in the above embodiments, this disclosure also provides an electronic device, characterized in that the electronic device includes: at least one memory and at least one processor; the memory stores an application program, and the processor calls the application program stored in the memory, the application program being used to implement the full-scenario MOCK processing method.

[0117] The following is for reference. Figure 5 This diagram illustrates a structural schematic of an electronic device 600 suitable for implementing embodiments of the present disclosure. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0118] like Figure 5As shown, electronic device 500 may include a processing unit (e.g., central processing unit, graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 506 into random access memory (RAM) 503. RAM 5603 also stores various programs and data required for the operation of electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0119] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0120] Based on the full-scenario MOCK processing method provided in the above embodiments, this disclosure also provides a storage medium, characterized in that the storage medium stores computer program code, and the computer program code implements the full-scenario MOCK processing method when executed.

[0121] In the context of this disclosure, a storage medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A storage medium can be a machine-readable signal medium or a machine-readable storage medium. Storage media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0122] It should be noted that the storage medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0123] The aforementioned storage medium may be included in the aforementioned electronic device; or it may exist independently and not be assembled into the electronic device.

[0124] According to one or more embodiments of this disclosure, a full-scene MOCK processing method is provided, the method comprising:

[0125] Start MOCK recording. The recording information obtained by the recording engine is output online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of requests to the target service.

[0126] Obtain the Wiremock mappings file, response template file, and response replacement rule file written based on the recorded information, and start the Wiremock service for the MOCK management platform based on the obtained files;

[0127] The Wiremock service is handled through the MOCK management platform in a pre-configured running mode, which includes normal mode or microservice mode.

[0128] According to one or more embodiments of this disclosure, a full-scenario MOCK processing method is provided, which outputs recording information obtained by the recording engine online through a recording server, including:

[0129] Deploy the recording engine in the target service and modify the target address corresponding to the target service to point to the MOCK management platform;

[0130] The recording engine is associated with the target service by using the attach command;

[0131] Modify the recording configuration information of MOCK recording on the recording server and push the recording configuration information to the recording engine;

[0132] The recording engine intercepts the entire process of requests to the target address based on the recording configuration information, and the recording information obtained by the recording engine is output online through the recording server.

[0133] According to one or more embodiments of this disclosure, a full-scene MOCK processing method is provided, the method further comprising:

[0134] The health status and application status reported by the target service are recorded online by the server.

[0135] According to one or more embodiments of this disclosure, a full-scene MOCK processing method is provided, the method further comprising:

[0136] While retrieving the mapping files, response template files, and response replacement rule files, also retrieve the documentation for the MOCK script.

[0137] According to one or more embodiments of this disclosure, a full-scene MOCK processing method is provided, the method further comprising:

[0138] The MOCK management platform allows for online monitoring of the health status and external service performance of the Wiremock service.

[0139] According to one or more embodiments of this disclosure, a full-scenario MOCK processing device is provided, the device comprising:

[0140] The recording startup module is used to start MOCK recording. It outputs the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of requests to the target service.

[0141] The service startup module is used to obtain the Wiremock mappings file, response template file, and response replacement rule file written based on the recorded information, and to start the Wiremock service for the MOCK management platform based on the obtained files;

[0142] The service execution module is used to process the Wiremock service through the MOCK management platform in a configured running mode, which includes normal mode or microservice mode.

[0143] According to one or more embodiments of this disclosure, a full-scenario MOCK processing device is provided, used as a recording startup module for online output of recording information obtained by the recording engine through a recording server, specifically for:

[0144] Deploy the recording engine in the target service and modify the target address of the target service to point to the MOCK management platform; associate the recording engine with the target service using the attach command; modify the recording configuration information of MOCK recording through the recording server and push the recording configuration information to the recording engine; intercept the entire process of the recording engine's request to the target address based on the recording configuration information, and output the recording information obtained by the recording engine online through the recording server.

[0145] According to one or more embodiments of this disclosure, a full-scenario MOCK processing device is provided, the device further comprising:

[0146] The information output module is used to record and output the health status and application status reported by the target service online.

[0147] According to one or more embodiments of this disclosure, an electronic device is provided, comprising: at least one memory and at least one processor; the memory stores an application program, and the processor invokes the application program stored in the memory, the application program being used to implement a full-scene MOCK processing method.

[0148] According to one or more embodiments of the present disclosure, a storage medium is provided that stores computer program code, which, when executed, implements a full-scenario MOCK processing method.

[0149] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

[0150] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0151] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. A method for handling MOCKs across all scenarios, characterized in that, The method includes: Start MOCK recording and output the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of the request to the target service. Obtain the Wiremock mappings file, response template file, and response replacement rule file written based on the recorded information, and start the Wiremock service for the MOCK management platform based on the obtained files; The Wiremock service is processed through the MOCK management platform in a configured operating mode, including normal mode and microservice mode. The normal mode adds a proxy service between the client and the MOCK environment and the real environment. By modifying the proxy service configuration, the proxy service can be controlled to forward to the MOCK environment or the real environment, thus achieving one-click switching between the MOCK environment and the real environment. The microservice model uses Wiremock's MOCK service to simulate microservices. By operating the microservice registry, it manages the online / offline status of services between the real and MOCK services based on the current state of user operations, achieving one-click switching between the MOCK and real environments.

2. The method according to claim 1, characterized in that, The recording information obtained by the recording engine and output online through the recording server includes: The recording engine is deployed in the target service, and the target address corresponding to the target service is modified to point to the MOCK management platform; The recording engine is associated with the target service by using the attach command; The recording server modifies the recording configuration information of the MOCK recording and pushes the recording configuration information to the recording engine. The recording engine intercepts and records the entire process of requests to the target address based on the recording configuration information, and the recording information obtained by the recording engine is output online through the recording server.

3. The method according to claim 2, characterized in that, The method further includes: The recording server outputs the health status and application status reported by the target service online.

4. The method according to claim 1, characterized in that, The method further includes: While obtaining the mapping file, the response template file, and the response replacement rule file, obtain the documentation for the MOCK script.

5. The method according to claim 1, characterized in that, The method further includes: The MOCK management platform provides online statistics on the health status and external service performance of the Wiremock service.

6. A full-scene MOCK processing device, characterized in that, The device includes: The recording startup module is used to start MOCK recording and output the recording information obtained by the recording engine online through the recording server. The recording information is obtained by the recording engine intercepting and recording the entire process of the request to the target service. The service startup module is used to obtain the Wiremock mapping file, response template file and response replacement rule file written based on the recorded information, and to start the Wiremock service for the MOCK management platform based on the obtained files; The service operation module is used to process the Wiremock service through the MOCK management platform in a configured operating mode. The operating modes include normal mode and microservice mode. In normal mode, a proxy service is added between the client and the MOCK environment and the real environment. By modifying the proxy service configuration, the forwarding of the proxy service to the MOCK environment or the real environment is controlled, achieving one-click switching between the MOCK environment and the real environment. In microservice mode, a simulated microservice is implemented using Wiremock's MOCK service. By operating the microservice registry, the real service and the MOCK service are brought online or offline according to the current state of the user operation, achieving one-click switching between the MOCK environment and the real environment.

7. The apparatus according to claim 6, characterized in that, The recording startup module, used for outputting recording information obtained by the recording engine online via the recording server, is specifically used for: The recording engine is deployed in the target service, and the target address corresponding to the target service is modified to point to the MOCK management platform; The recording engine is associated with the target service by using the attach command; The recording server modifies the recording configuration information of the MOCK recording and pushes the recording configuration information to the recording engine. The recording engine intercepts and records the entire process of requests to the target address based on the recording configuration information, and the recording information obtained by the recording engine is output online through the recording server.

8. The apparatus according to claim 7, characterized in that, The device further includes: The information output module is used to output the health status and application status reported by the target service online through the recording server.

9. An electronic device, characterized in that, The electronic device includes: at least one memory and at least one processor; the memory stores an application program, and the processor calls the application program stored in the memory, the application program being used to implement the full-scene MOCK processing method according to any one of claims 1-5.

10. A storage medium, characterized in that, The storage medium stores computer program code, which, when executed, implements the full-scene MOCK processing method according to any one of claims 1-5.

Images