Mock platform construction method for travel saas platform

Abstract

The invention provides a mock platform construction method oriented to a travel saas platform. The mock platform construction method comprises the following steps: demand analysis: determining a target and a demand of a Mock platform; environment preparation: ensuring that the Java environment of the target SaaS platform meets the operation of the java byte code instrumentation technology; integration of a java byte code instrumentation technology: the java byte code instrumentation technology is integrated into an SaaS platform; according to the invention, a Java byte code instrumentation technology is utilized to construct a software as a service (SaaS) platform interface Mock platform which is powerful in function, flexible and easy to use, and the Mock platform can dynamically perform Mock on the interface of the SaaS platform without restarting an application, so that the development and test efficiency is greatly improved, and the development cost is reduced. And the Mock platform also has the characteristics of non-invasiveness, dynamic plugging, class isolation, flexible AOP support, self-definition, real-time monitoring and fault simulation, easiness in integration and use, safety, fault positioning and performance optimization.

Description

Technical Field

[0001] The present invention relates to a method for constructing a platform, specifically a method for constructing a mock platform for a travel SaaS platform, and belongs to the technical field of system development. Background Art

[0002] A travel SaaS platform refers to a solution for the travel industry that provides Software as a Service (SaaS). Such platforms are usually operated by third-party service providers and provide users with online travel service management tools to help enterprises or individuals efficiently plan and execute travel activities; the advantages of travel SaaS platforms lie in their convenience, flexibility, and cost-effectiveness. Users can access the services anytime and anywhere through the Internet.

[0003] An interface Mock platform is a service used to simulate API (Application Programming Interface) responses. It allows developers to test and debug their applications without actually accessing a real server. Such platforms usually provide tools for creating, testing, and simulating API interactions, enabling developers to test interfaces in a local environment without concerning themselves with the actual logic of the backend service.

[0004] Travel SaaS platforms need to be frequently integrated with various third-party services (such as map services, payment services, etc.). To reduce dependence on these services, a platform that can simulate the behavior of these service interfaces is required; while the interface Mock platform can provide a stable interface environment, enabling developers to work independently and helping to create various test cases to ensure that the system can operate properly in various situations, with characteristics such as improving development efficiency, simplifying parallel development, test case coverage, and cost savings.

[0005] However, the functions of existing interface Mock platforms are still relatively simple. Usually, they can only provide basic interface simulation and testing functions and cannot meet the requirements in complex scenarios. For example, they have insufficient support for asynchronous interfaces, dynamic data, and complex data structures; and there are problems such as poor user experience, poor scalability, performance issues, insufficient security, imperfect documentation and support, and lack of support for multiple data formats.

[0006] Therefore, a method for constructing a mock platform for a travel SaaS platform is proposed. Summary of the Invention

[0007] In view of this, the present invention provides a method for constructing a mock platform for a travel SaaS platform to solve or alleviate the technical problems existing in the prior art and at least provide a beneficial option.

[0008] The technical solution of the embodiment of the present invention is realized as follows: A method for constructing a mock platform for a travel SaaS platform, comprising the following steps:

[0009] Requirement analysis - clarify the goals and requirements of the Mock platform;

[0010] Environment preparation - ensure that the Java environment of the target SaaS platform meets the operation of the Java bytecode instrumentation technology;

[0011] Integration of Java bytecode instrumentation technology - integrate the Java bytecode instrumentation technology into the SaaS platform;

[0012] Module development - develop custom modules to implement specific Mock logic;

[0013] Add event listening and AOP - intercept specific methods and return Mock data;

[0014] Selectively add dynamic data support according to requirements;

[0015] Add isolation and multi-tenancy - complete the development of the Mock module;

[0016] Deployment and testing - deploy the developed Mock module to the test environment and conduct testing and verification;

[0017] Configure monitoring and logging for tracking the running status of the Mock platform and debugging problems;

[0018] Maintenance and iteration - continuously optimize and iterate the functions of the Mock platform according to test feedback and business development to meet changing requirements.

[0019] Further preferably, the goals and requirements include, but are not limited to, the types of interfaces to be simulated, the definition of the expected response data format, and whether dynamic data return is required;

[0020] Among them, the interface types include API interfaces, database interfaces, file processing interfaces, message queue interfaces, and third-party service interfaces;

[0021] Among them, the response data formats include JSON, XML, Plain Text, Protobuf, and custom formats.

[0022] Further preferably, the Java environment judgment criteria include, but are not limited to, the JDK version and the operating system version;

[0023] When the Java environment of the target SaaS platform does not meet the operation of the Java bytecode instrumentation technology, install necessary tools in the target SaaS platform to meet the requirements of the Java bytecode instrumentation technology;

[0024] Among them, the necessary tools include, but are not limited to, IDE tools and version control tools.

[0025] Further preferably, the integration of the Java bytecode instrumentation technology adopts the Java Agent technology, which is used to dynamically operate on the JVM process without restarting the application and can be loaded when the JVM starts or runs.

[0026] Further preferably, the specific Mock logic includes, but is not limited to, listening to the calls of specified methods and modifying behaviors, returning Mock data, recording logs, and modifying method return values.

[0027] Further preferably, the event listening and AOP utilize the event listening and aspect-oriented programming capabilities of the Java bytecode instrumentation technology to intercept specific methods and return Mock data without modifying the original business code;

[0028] Among them, the interception of specific methods includes interface request interception and sub-call interception;

[0029] Among them, sub-calls include MySql, Redis, Guava, HttpClient, message queue interception, and other microservices.

[0030] Further preferably, the addition of dynamic data support realizes dynamic responses based on request parameters by combining the dynamic bytecode generation ability of the Java bytecode instrumentation technology when dynamically generating response data.

[0031] Further preferably, the isolation and multi-tenant feature utilize the Java bytecode instrumentation technology to support module isolation and multi-tenant architectures, ensuring that the Mock configurations between different modules or users are independent of each other and do not affect each other.

[0032] Further preferably, the testing and verification are performed on the deployed Mock module through the command-line tool or HTTP API of the Java bytecode instrumentation technology.

[0033] Since the embodiments of the present invention adopt the above technical solutions, they have the following advantages:

[0034] The present invention utilizes Java bytecode instrumentation technology to construct a powerful, flexible and easy-to-use SaaS platform interface Mock platform, which can dynamically Mock the interfaces of the SaaS platform without restarting the application, greatly improving the efficiency of development and testing. Moreover, the Mock platform also has the characteristics of non-intrusiveness, dynamic plug-and-play, class isolation, flexible AOP support, customization, real-time monitoring and fault simulation, easy integration and use, security, fault location and performance optimization.

[0035] The above summary is only for the purpose of the specification and is not limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present invention will be readily apparent by reference to the drawings and the following detailed description. Brief Description of the Drawings

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

[0037] Figure 1 is the step flow chart of the present invention;

[0038] Figure 2 is the architecture diagram of the present invention;

[0039] Figure 3 is the service and interface flow chart for configuring mock in the present invention;

[0040] Figure 4 is the interception return flow chart of the mock platform of the present invention. Detailed Embodiments

[0041] In the following, only some exemplary embodiments are simply described. As those skilled in the art can recognize, the described embodiments can be modified in various different ways without departing from the spirit or scope of the present invention. Therefore, the drawings and the description are considered to be exemplary in nature rather than restrictive.

[0042] It should be noted that terms such as "first", "second", "symmetric", "array", etc. are only used for the purpose of distinguishing descriptions and position descriptions, and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, those limited by features such as "first", "symmetric", etc. may explicitly or implicitly include one or more such features; similarly, when there is no numerical limitation on certain features in the form of words such as "two", "three", etc., it should be noted that such features also explicitly or implicitly include one or more feature quantities.

[0043] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0044] As Figures 1 - 4 shown, the embodiments of the present invention provide a method for constructing a mock platform for a travel SaaS platform, including the following steps:

[0045] S1. Requirement analysis - clarify the goals and requirements of the Mock platform;

[0046] The goals and requirements include but are not limited to the types of interfaces to be simulated, defining the expected response data format, and whether to support dynamic data return;

[0047] Among them, the interface types include API interfaces, database interfaces, file processing interfaces, message queue interfaces, and third-party service interfaces;

[0048] Among them, the response data formats include JSON, XML, Plain Text, Protobuf, and custom formats;

[0049] First, clarify the goals and requirements of the required mock platform, and plan the functions that the mock platform finally needs to have according to the requirement analysis.

[0050] S2. Environment preparation - ensure that the Java environment of the target SaaS platform meets the operation of the Java bytecode instrumentation technology;

[0051] The Java environment judgment criteria include but are not limited to the JDK version and the operating system version;

[0052] When the Java environment of the target SaaS platform does not meet the operation of the Java bytecode instrumentation technology, install necessary tools in the target SaaS platform to meet the requirements of the Java bytecode instrumentation technology;

[0053] Among them, the necessary tools include but are not limited to IDE tools and version control tools;

[0054] By leveraging the Java bytecode instrumentation technology, developers are allowed to perform dynamic operations and monitoring on the JVM process without modifying the existing business code. This means that the integration of the Mock platform will not interfere with the existing system, making the Mock platform non-invasive. Moreover, due to its non-invasive nature, the security risks posed by the Mock platform to the original system are reduced, enabling testing and simulation without affecting the production environment and enhancing security.

[0055] S3, Integration of Java Bytecode Instrumentation Technology - Integrate the Java bytecode instrumentation technology into the SaaS platform;

[0056] The integration of Java bytecode instrumentation technology uses the Java Agent technology to dynamically operate on the JVM process without restarting the application and can be loaded when the JVM starts or runs.

[0057] By leveraging the Java bytecode instrumentation technology, the Mock platform supports dynamic loading and unloading of modules, enabling the activation or deactivation of Mock functions according to requirements at runtime, providing great flexibility and making the Mock platform feature dynamic plug-and-play.

[0058] Java bytecode instrumentation technology is a technology that, without modifying the original target program code, realizes the monitoring, analysis, and modification of the program's running behavior by dynamically modifying the program bytecode at runtime. The Java Agent is the way to implement this technology. An Agent is a program that runs on the Java Virtual Machine (JVM). It can be loaded into the target Java program and intercept specific method calls of the target program. In this way, the Agent can add additional functions, such as performance monitoring, logging, security checks, etc., without modifying the original code.

[0059] S4, Module Development - Develop custom modules to implement specific Mock logic;

[0060] Specific Mock logic includes but is not limited to listening for calls to specified methods and modifying behaviors, returning Mock data, logging, and modifying method return values;

[0061] Implement specific Mock logic by developing custom modules. These modules will use the APIs provided by the Java bytecode instrumentation technology, such as listening for specific method calls, modifying method behavior, returning Mock data, etc.; and the developed custom modules all use the APIs provided by the Java bytecode instrumentation technology, which can effectively ensure that the classes of the modules and the target application do not interfere with each other, avoid potential class conflict problems, and make the Mock platform have the characteristic of class isolation; it can also use the APIs provided by the Java bytecode instrumentation technology and modular design to make the Mock platform more convenient to integrate into the existing SaaS platform and quickly develop and deploy Mock functions.

[0062] S5. Add event listening and AOP - intercept specific methods and return Mock data;

[0063] Event listening and AOP utilize the event listening and aspect - oriented programming capabilities of the Java bytecode instrumentation technology to intercept specific methods and return Mock data without modifying the original business code;

[0064] Among them, the interception of specific methods includes interface request interception and sub - call interception;

[0065] Among them, sub - calls include MySql, Redis, Guava, HttpClient, message queue interception, and other microservices;

[0066] By using the developed custom modules, developers are allowed to listen for and respond to specific method call events, providing the Mock platform with powerful customization capabilities;

[0067] By using the dynamic bytecode enhancement technology based on Instrumentation combined with the Java bytecode instrumentation technology, flexible aspect - oriented programming (AOP) support is provided for the Mock platform, which can intercept and enhance methods at runtime, enabling the Mock platform to have flexible AOP support. The specific principle is as Figure 4 shown. The scheme of intercepting the JVM uses the Java bytecode instrumentation technology. The principle is to attach (or start in agent form) to the running JVM, use the Instrumentation Api provided by Java to load custom modules, pay attention to the corresponding interception points, and re - weave the bytecode into the running program;

[0068] The specific implementation method is as follows:

[0069] S51. Obtain the Instrumentation instance;

[0070] To use the Instrumentation API, you first need to obtain an Instrumentation instance. This is typically achieved by calling the Instrumentation.getInstance() method. However, this method is not directly provided in the Java standard library. Usually, this means that you need to use the JDK internal API or an additional library (such as j2agent) to obtain the Instrumentation instance;

[0071] S52. Load and initialize the custom module;

[0072] Once you have an Instrumentation instance, you can use it to load custom class loaders and classes. These classes contain the code for the enhancements (such as AOP logic) that you want to implant:

[0073] Instrumentation inst =...; / / Obtain the Instrumentation instance

[0074] ClassLoader targetLoader =...; / / The class loader of the target application

[0075] / / Create a custom class loader

[0076] ClassLoader agentLoader = new URLClassLoader(new URL[]{new URL("file:path / to / agent / lib / agent.jar")}, targetLoader);

[0077] / / Use the Instrumentation instance to load the custom class loader

[0078] inst.appendToSystemClassLoaderSearch(agentLoader);

[0079] S53. Determine the interception points;

[0080] Determine the methods you want to intercept through annotations, configuration files, or runtime analysis. This can be achieved through a custom class loader or other functions of the Instrumentation API;

[0081] S54. Weave in the enhancement code;

[0082] Use ASM, Javassist, or other bytecode manipulation tools to create a proxy class that contains the method enhancement logic you want to implant. Then, use the Instrumentation API to replace or enhance the methods in the target class:

[0083] / / Obtain the bytecode of the target class

[0084] CtClass cc = ClassPool.getDefault().get(targetClassName);

[0085] / / Create a proxy class

[0086] CtClass proxyClass = cc.makeClass("Proxy" + cc.getSimpleName());

[0087] / / Add enhancement logic to the proxy class

[0088] / / ...

[0089] / / Use the Instrumentation instance to reweave the target class

[0090] inst.redefineClasses(new Class[]{proxyClass.toClass()});

[0091] S55. Set up event listeners;

[0092] If necessary, set up event listeners to listen for events such as class loading and method unloading:

[0093]

[0094] S56. Start the application;

[0095] Finally, start the application and ensure that the Instrumentation instance can attach to the JVM at runtime:

[0096] / / Start the target application

[0097] Process process = Runtime.getRuntime().exec(new String[]{"java", "-agentlib:j2agent.so=optional_configuration"}, null, targetDir);

[0098] / / Wait for the target application to start

[0099] Thread.sleep(1000);

[0100] / / Now you can call the methods of the Instrumentation instance to intervene in the application;

[0101] Thus, the Mock platform can be used to monitor the application status in real time, simulate interface failures, and perform traffic playback by using the Java bytecode instrumentation technology, which helps with testing and debugging.

[0102] S6. Selectively add dynamic data support according to requirements;

[0103] Adding dynamic data support means that when dynamic response data needs to be generated, based on the dynamic bytecode generation ability of the Java bytecode instrumentation technology, dynamic responses based on request parameters are realized;

[0104] Responses are generated by using the Java bytecode instrumentation technology to dynamically create or modify methods at runtime. The following is a simple ASM-based example to illustrate this process:

[0105] S61. Define a class to be instrumented. This class has a method that will generate response data based on the incoming parameters:

[0106]

[0107]

[0108] S62. Use the ASM library to modify the bytecode at runtime. By traversing the structure of the class file, insert new code snippets at appropriate positions;

[0109]

[0110]

[0111] By running the above program, the generateResponse method is modified and it will always return a static response string instead of a response generated based on the incoming parameters. However, this instance is very basic and only serves to illustrate how to use the Java bytecode instrumentation technology. In actual applications, complex logic is required to dynamically generate bytecode, such as inserting new methods, modifying the behavior of existing methods, adding or modifying fields, etc.

[0112] S7. Add isolation and multi-tenancy - complete the development of the Mock module;

[0113] Isolation and multi-tenancy utilize Java bytecode instrumentation technology to support module isolation and multi-tenant architectures, ensuring that Mock configurations between different modules or users are independent and do not affect each other;

[0114] In a multi-tenant architecture, each tenant may have different requirements and configurations. Using Java bytecode instrumentation technology, corresponding configuration code can be dynamically inserted based on tenant information without affecting the configurations of other tenants. Similarly, in the scenario of module isolation, the Mock configurations of each module can also be independently managed through bytecode instrumentation technology without interfering with each other;

[0115] The key to implementing this function lies in designing a dynamic configuration mechanism. The following is a simplified example to illustrate how to use bytecode instrumentation technology to achieve tenant-based dynamic configuration:

[0116] S71. Define a class to be instrumented. This class has a method that will generate specific response data based on the tenant ID;

[0117]

[0118] S72. Use the ASM library to modify the bytecode at runtime and dynamically insert new code snippets based on the tenant ID;

[0119]

[0120]

[0121]

[0122] By running the above program, the generateResponse method is modified and it will return a response string containing the tenant ID; however, this instance is very basic. In actual applications, more complex logic is required to handle tenant configurations and module isolation. When implementing, it is necessary to ensure that the modifications of bytecode instrumentation do not violate the requirements of security and stability, and also consider that bytecode instrumentation may increase the complexity and maintenance cost of the code.

[0123] S8. Deployment and Testing - Deploy the developed Mock module to the test environment and conduct testing and verification;

[0124] Testing and verification are performed on the deployed Mock module through the command-line tool or HTTP API of Java bytecode instrumentation technology;

[0125] Testing and verifying the deployed Mock module by using the command-line tool:

[0126] It dynamically modifies bytecode during program runtime without involving the application's interfaces or network communication. The command-line tool directly operates on bytecode, eliminating the need for network requests, enabling precise control over the code locations to be instrumented, inserting specific test logic or monitoring code, and making minor adjustments to method behavior, such as adding logs or modifying return values. It can also be integrated with automated testing frameworks like JUnit to automate test script execution. Although instrumentation may slightly impact program performance, especially when instrumenting a large amount of code, the command-line tool, operating on bytecode, should theoretically minimize the performance impact.

[0127] Test and verify the deployed Mock module via the HTTP API:

[0128] It interacts with the deployed Mock module via network requests, commonly used to simulate HTTP service requests and test whether the module's external interfaces are correct. It can test different HTTP methods (GET, POST, PUT, DELETE, etc.), simulate various user behaviors, send request data in different formats (JSON, XML, etc.), and verify whether the module's responses meet expectations. It can be integrated with API testing frameworks like Postman to automate API calls and simulate complex user interactions and data flows through test scripts. HTTP API testing generally does not directly affect program performance as it does not involve the program's bytecode, but network communication introduces a certain latency that can be ignored.

[0129] The command-line tool or HTTP API using Java bytecode instrumentation technology can be selected according to actual requirements.

[0130] S9. Configure monitoring and logging for tracking the running status of the Mock platform and debugging issues.

[0131] By configuring monitoring and logging, the Mock platform has the following characteristics:

[0132] Troubleshooting:

[0133] When problems occur in the Mock platform, logging can provide error messages and exception stacks to help developers quickly locate the problem.

[0134] The monitoring system can capture signs of performance degradation or system exceptions in real time, facilitating rapid troubleshooting.

[0135] Performance analysis:

[0136] Logging can assist in analyzing the system's performance, such as recording response times, system loads, and resource usage.

[0137] The monitoring tool can set thresholds, and when the system performance metrics exceed the predetermined values, the system will automatically alarm;

[0138] Trend prediction:

[0139] By analyzing the logs and monitoring data, the future performance trends of the system can be predicted, providing a basis for system optimization and expansion;

[0140] The monitoring system can detect system bottlenecks, perform optimizations in advance, and avoid potential performance problems;

[0141] Compliance requirements:

[0142] Some industries or organizations have strict auditing and compliance requirements, and logging and monitoring are important means to meet these requirements;

[0143] Monitoring and logging can help organizations comply with data protection regulations and industry standards;

[0144] Real-time monitoring:

[0145] The monitoring system can display the health status of the system in real time, enabling the operation and maintenance personnel to understand the system operation status at any time;

[0146] Real-time monitoring helps to detect and solve problems in a timely manner, reducing the impact of system failures on the business;

[0147] Automatic response:

[0148] Advanced monitoring systems can automatically respond to detected problems, such as automatically restarting services or triggering alarms;

[0149] Automatic response can reduce the dependence on manual intervention and improve the stability and availability of the system;

[0150] Historical data analysis:

[0151] Logging provides historical data, which can help analyze the long-term behavior and performance evolution of the system;

[0152] Historical data is very important for understanding how the system changes over time and for long-term planning;

[0153] In summary, configuring monitoring and logging is a key measure to ensure the stable operation and effective debugging of the Mock platform. They provide valuable information for the operation and maintenance personnel to help them detect and solve problems in a timely manner, and also provide data support for the continuous improvement of the system.

[0154] S10. Maintenance and Iteration - Continuously optimize and iterate the functions of the Mock platform according to the test feedback and business development to meet the changing needs;

[0155] By continuously optimizing and iterating the functions of the Mock platform, it is a key measure to ensure its synchronization with business development, meet user needs, enhance product competitiveness, and support enterprise growth. Through such a strategy, enterprises can maintain the leading position of their products and provide users with a consistent high-quality experience.

[0156] In one embodiment, the services and interfaces for configuring mock of the present invention are specifically as Figure 3 shown and include the following:

[0157] Configure the IP address of the service that needs to be mocked in the background;

[0158] Configure the Java interfaces and methods that need to be mocked, and perform data isolation according to the tenant ID in the header;

[0159] The system automatically pushes the configured content to the agent of the target service;

[0160] External services request the interfaces and methods of the target service.

[0161] The above are only the specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of various changes or substitutions, and these should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for constructing a mock platform for a travel SaaS platform, characterized in that, It includes the following steps: Requirement analysis - clarify the goals and requirements of the Mock platform; Environment preparation - ensure that the Java environment of the target SaaS platform meets the running requirements of the Java bytecode instrumentation technology; Integration of Java bytecode instrumentation technology - integrate the Java bytecode instrumentation technology into the SaaS platform; Module development - develop custom modules to implement specific Mock logic; Add event listening and AOP - intercept specific methods and return Mock data; Selectively add dynamic data support according to requirements; Add isolation and multi-tenancy - complete the development of the Mock module; Deployment and testing - deploy the developed Mock module to the test environment and conduct testing and verification; Configure monitoring and logging for tracking the running status of the Mock platform and debugging problems; Maintenance and iteration - continuously optimize and iterate the functions of the Mock platform according to test feedback and business development to meet changing requirements.

2. The method for constructing a mock platform for the travel-oriented SaaS platform according to claim 1, wherein: The goals and requirements include but are not limited to the types of interfaces to be simulated, defining the expected response data format, and whether to support dynamic data return; Among them, the interface types include API interfaces, database interfaces, file processing interfaces, message queue interfaces, and third-party service interfaces; Among them, the response data formats include JSON, XML, Plain Text, Protobuf, and custom formats.

3. The method for constructing a mock platform for the travel-oriented SaaS platform according to claim 1, characterized in that: The judgment criteria for the Java environment include but are not limited to the JDK version and the operating system version; When the Java environment of the target SaaS platform does not meet the running requirements of the Java bytecode instrumentation technology, install necessary tools in the target SaaS platform to meet the requirements of the Java bytecode instrumentation technology; Among them, the necessary tools include but are not limited to IDE tools and version control tools.

4. The method for constructing a mock platform for a travel-oriented SaaS platform according to claim 1, wherein: The integration of the Java bytecode instrumentation technology adopts the Java Agent technology, which is used to dynamically operate on the JVM process without restarting the application and can be loaded when the JVM starts or runs.

5. The method for constructing a mock platform for a travel-oriented SaaS platform according to claim 1, wherein: The specific Mock logic includes but is not limited to listening for calls to specified methods and modifying behaviors, returning Mock data, recording logs, and modifying method return values.

6. The method for constructing a mock platform for the travel-oriented SaaS platform according to claim 2, wherein: The event listening and AOP utilize the event listening and aspect-oriented programming capabilities of the Java bytecode instrumentation technology to intercept specific methods and return Mock data without modifying the original business code; Among them, the interception of specific methods includes interface request interception and sub-call interception; Among them, sub-calls include MySql, Redis, Guava, HttpClient, message queue interception, and other microservices.

7. The method for constructing a mock platform for a travel-oriented SaaS platform according to claim 1, characterized in that: The addition of dynamic data support is to realize dynamic responses based on request parameters by combining the dynamic bytecode generation ability of the Java bytecode instrumentation technology when dynamically generating response data is required.

8. The method for constructing a mock platform for the travel-oriented SaaS platform according to claim 1, wherein: The isolation and multi-tenancy utilize the Java bytecode instrumentation technology to support module isolation and multi-tenant architectures, ensuring that the Mock configurations between different modules or users are independent of each other and do not affect each other.

9. The method for constructing a mock platform for a travel-oriented SaaS platform according to claim 1, characterized in that: The above-mentioned testing and verification are carried out on the deployed Mock module through a command-line tool or an HTTP API of the Java bytecode instrumentation technology.

Images