Custom Mock platform and network request simulation processing method based on same

Abstract

The invention relates to a custom Mock platform and a network request simulation processing method based on the custom Mock platform, and the platform comprises a Mock rule management unit which obtains a configuration field of a Mock rule based on an interactive configuration interface; the extraction rule configuration unit is used for obtaining configuration fields of extraction rules based on the interactive configuration interface, extracted parameters are stored in a variable pool, and the parameters in the variable pool are used for being converted into dynamic variables; the custom variable unit is used for customizing a constant based on the interactive configuration interface and / or dynamically generating a custom variable by utilizing a custom function provided by the Mock platform; the user-defined function unit is used for receiving and approving the uploaded user-defined function and adding the user-defined function into a function library of the Mock platform; and the Mock response unit is used for editing based on the interactive configuration interface or generating dynamic response header information based on a self-defined function, and generating a response message based on a preset template. According to the invention, a complex business scene can be accurately simulated and responded in real time, so that the authenticity and effectiveness of the test are greatly improved.

Description

Technical Field

[0001] The present application relates to the technical field of software development, and in particular to a custom Mock platform and a network request simulation processing method based thereon. Background Art

[0002] With the increasing complexity of software development, especially with the widespread application of microservice architecture and front-end and back-end separation mode, Mock technology has become a key tool in the development and testing process. Mock technology simulates the behavior of service interfaces, allowing developers to continue development and functional testing when the actual service is not yet completed or unavailable. The current Mock platform meets the basic needs of developers to a certain extent. However, with the diversification and complexity of application scenarios, the existing Mock platform has gradually exposed some limitations and cannot fully meet the needs of developers in complex testing scenarios.

[0003] Existing mock platforms mainly rely on URL matching mechanisms to simulate service responses, but they are unable to cope with complex parameters and request header information. This simple matching method often does not provide sufficient flexibility when facing complex test scenarios that require accurate simulation of backend service behaviors. In addition, most existing platforms can only return predefined static responses and lack the ability to dynamically generate responses based on requests, which is obviously insufficient in simulating complex business logic and abnormal situations.

[0004] In addition, current mock platforms generally lack parameter extraction and reference functions. Key parameters and request header information in requests often need to be referenced in responses to achieve more accurate simulations. However, due to the lack of this function in existing platforms, developers have to perform repetitive manual operations, which increases the complexity of development and testing.

[0005] Existing mock platforms are also limited in their support for custom functions and variables. When dealing with complex business logic and abnormal scenarios, developers often need to rely on custom functions and variables. However, due to insufficient platform support, developers find it difficult to flexibly respond to these needs. In addition, the limitations of existing platforms in request header editing and HTTP status code setting further hinder their application in diverse testing and development needs. Summary of the invention

[0006] The embodiments of the present application provide a custom Mock platform and a network request simulation processing method based thereon to provide a more powerful, flexible and intelligent Mock service.

[0007] In a first aspect, an embodiment of the present application provides a custom mock platform, including:

[0008] A mock rule management unit obtains configuration fields of the mock rule based on an interactive configuration interface. The configuration fields of the mock rule include but are not limited to: request header, request body, request parameters, URL, and cookie;

[0009] The extraction rule configuration unit obtains the configuration fields of the extraction rules based on the interactive configuration interface, and stores the extracted parameters in a variable pool. The parameters in the variable pool are used to convert into dynamic variables for Mock response. The configuration fields of the extraction rules include but are not limited to: simple extraction rules and parsing extraction rules. The simple extraction rules are configured with field values ​​to be extracted and a default value. If the field value is not extracted, it is set to the default value. The parsing extraction rules extract parameters based on JSONPath expressions.

[0010] A custom variable unit is used to customize constants based on the interactive configuration interface, and / or dynamically generate custom variables using custom functions provided by the Mock platform. The variables are used to store in the variable pool for Mock response after the Mock rule is triggered. The variables in the variable pool are used to construct the response header and response message;

[0011] The custom function unit is used to receive and approve uploaded custom functions and add them to the function library of the Mock platform;

[0012] The mock response unit is used to edit the dynamic response header information based on the interactive configuration interface or generate the dynamic response header information based on the custom function, and generate the response message based on the preset template. The extracted parameters and custom variables and custom functions are allowed to be referenced in the response header information and the response message. Specifically, the value can be dynamically taken from the variable pool according to the variable name and replaced with the corresponding real value. The user can easily create and edit the message template, thereby improving the development efficiency.

[0013] In some embodiments, the reference of the custom variables and custom functions in the response message is realized by referencing the variable name in the variable pool or the function name in the function library, which is expressed in the form of $variable name or ${function name}, which provides higher flexibility and dynamism for message generation and helps to adapt to various complex business scenarios and requirements. The format of the response message includes but is not limited to: Text, Json, Xml, Html, to meet the needs of different business scenarios.

[0014] In some embodiments, the platform further comprises:

[0015] The cache unit is used to store the visited Mock rules and their matching results. The cache unit is configured to adopt a key-value pair storage structure and / or a hierarchical cache structure.

[0016] In some embodiments, the primary key of the key-value pair storage structure includes the URL and the request method, the value includes the identifier of the mock rule and its mock response, the hierarchical cache structure includes a local cache and a distributed cache, the local cache is used to store high-frequency access data, for example but not limited to the use of LRU cache (Least Recently Used, LRU), the distributed cache is used to store large-scale or shared data across multiple service instances, for example but not limited to the use of Redis, Memcached;

[0017] In distributed caching, cache data can be shared among multiple service instances through shared cache to improve the utilization of cache data and the overall performance of the platform.

[0018] In some of the embodiments, in the cache unit, the cache data is configured with an expiration time, and a cache refresh mechanism is established based on the expiration time, allowing the cache to be cleared manually or automatically based on the expiration time when the Mock rules are updated so as to regenerate a new cache.

[0019] In some of the embodiments, the Mock platform adopts a copy-on-write strategy when updating the Mock rules, which can ensure that when the data is modified, it will not directly affect the old data being accessed, thereby avoiding data inconsistency or access conflict problems.

[0020] In some of the embodiments, the Mock rule update and cache refresh are configured with a subscription and notification mechanism. When the Mock rule changes, the cache unit is informed to update the relevant cache items through a message queue or other notification mechanism.

[0021] In a second aspect, an embodiment of the present application provides a network request simulation processing method, based on the custom Mock platform described in the first aspect above, including:

[0022] Request initiation step: use the Mock platform to initiate a Mock request;

[0023] Request matching step: receiving the Mock request and checking whether the corresponding URL exists in the cache unit. If so, it is judged as a cache hit, and rule matching is performed to determine the Mock rule or directly return the Mock response stored in the cache unit; otherwise, a database query is performed;

[0024] A database query step, based on the Mock request, obtains query results in the database according to the established index conditions, and determines the Mock rules by rule matching based on the query results, wherein a composite index is configured for the key fields in the Mock rules in the database table, and the key fields include URL and request method, so as to quickly locate the possibly related Mock rule set in the database, and then further accurately match, and when the value of the request method field is less than the value of the URL field, the request method field is configured in front of the composite index;

[0025] The dynamic message generation step performs parameter extraction, custom variable parsing, custom function parsing, response header parsing and replacement, and response message parsing and replacement in sequence based on the matched Mock rules, and returns the response information. Otherwise, it returns the unmatched result. The Mock platform makes real-time judgment and starts the transparent transmission mechanism. The transparent transmission mechanism uses efficient network forwarding technology to quickly and accurately forward the Mock request to the backend service for processing, avoiding problems such as test failure or data loss caused by improper configuration of Mock rules.

[0026] In some embodiments, the dynamic message generation step further includes:

[0027] Parameter extraction step: parse the configuration fields in the Mock rule and extract the parameters of the configuration fields;

[0028] Custom variable parsing step: check whether the custom variable is referenced in the Mock rule. If the custom variable is referenced, get the corresponding variable value from the variable pool and replace it with the position specified in the Mock rule;

[0029] Custom function parsing step, check whether the custom function is used in the Mock rule; if the custom function is used, call the corresponding function in the function library and replace the function return value to the position specified in the Mock rule;

[0030] Response header parsing and replacement step: parse the response header defined in the Mock rule. If the response header references parameters, custom variables or custom functions, corresponding replacements are performed. After the replacement, the response header will be added to the response information.

[0031] The response message parsing and replacement step parses the response message defined in the Mock rule. If the response message references parameters, custom variables or custom functions, corresponding replacements are performed. The response message after replacement is used as the main part of the response information.

[0032] Through the above steps, based on the matched Mock rules, the platform can dynamically generate and return response information to meet various complex testing requirements.

[0033] In some embodiments, the rule matching is performed layer by layer based on the field level until the matched Mock rule is determined and stored in the cache unit for responding to repeated Mock requests. If the Mock rule cannot be matched, the unmatched result is returned. The field level is configured based on the request header, request body, etc. The Mock rules include: simple field matching rules, regular expression matching rules, and JSONPath expression matching rules. If there are still multiple Mock rules at the request header level, they are further matched according to the content in the request body, and so on.

[0034] The simple field matching in the above-mentioned embodiment is to directly set matching rules for simple fields in the request (such as URL parameters, request header fields, Cookies, request parameters, etc.), and the matching conditions include: equal to, not equal to, between, contains, does not contain, empty, non-empty and other relationships. Equal to means that the field value must be completely equal to the specified value; not equal to means that the field value cannot be equal to the specified value; between means that the field value of the numeric type field is set between two specified values ​​(including the boundary value); contains is used to check whether the field value of the string type field contains the specified substring; does not contain is used to check whether the field value does not contain the specified substring; empty is used to check whether the field value is empty or null; conversely, non-empty is used to check whether the field value is not empty.

[0035] The regular expression matching rules in the above embodiment are applicable to scenarios that require complex pattern matching, and can be implemented using the regular expression provided by the Mock platform. The JSONPath expression matching rules are applicable to request bodies in JSON format, and JSONPath expressions can be used to specify specific locations in the JSON document, thereby extracting the field value setting rules that need to be matched.

[0036] This application provides users with comprehensive and flexible Mock rule customization capabilities. This enables the Mock platform to better meet users' testing needs in various complex scenarios.

[0037] In some of the embodiments, in the request matching step, Mock rules are stored and searched based on a hash table to significantly improve the matching efficiency in massive requests, and the search operation can be completed within constant time or logarithmic time complexity.

[0038] In some embodiments, the Mock rule is configured with a priority, and when there are multiple matching rules, the rule with a higher priority will be applied first. If there are multiple matching rules with the same priority, further sorting and selection can be performed based on the creation time, update time or other custom fields of the rule.

[0039] Compared with related technologies, the custom mock platform and the network request simulation processing method based thereon provided in the embodiments of the present application can simulate and respond to various complex business scenarios in real time and accurately through efficient matching and extraction technology, thereby greatly improving the authenticity and effectiveness of the test. Developers can more confidently rely on mock data for front-end and back-end functional development and integration testing, reducing development delays and errors caused by unready services or inconsistent data;

[0040] Secondly, the ability to customize variables and functions gives developers great flexibility. They can quickly create customized rules based on business needs and easily build a realistic and complex test environment. This personalized simulation not only helps to discover potential errors and performance issues, but also helps the team better understand business logic and interaction processes;

[0041] In addition, the platform provides a user interface and API interface to facilitate users to configure and manage Mocks; it adopts an extensible architecture design to support the rapid development and integration of new functions. Users can also develop custom functions and extension libraries according to their own needs to meet personalized needs.

[0042] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0044] Figure 1 is a flowchart of a network request simulation processing method according to an embodiment of the present application;

[0045] Figure 2 It is a step-by-step flowchart of the network request simulation processing method according to an embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0047] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complicated and lengthy, for ordinary technicians in this field related to the content disclosed in this application, some changes in design, manufacturing or production based on the technical content disclosed in this application are just conventional technical means, and should not be understood as insufficient content disclosed in this application.

[0048] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0049] This embodiment provides a custom mock platform. As used below, the terms "module", "unit", "subunit", etc. can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated. Specifically, the custom mock platform includes:

[0050] A mock rule management unit, based on an interactive configuration interface, obtains configuration fields of the mock rule set by the user, where the configuration fields of the mock rule include but are not limited to: request header, request body, request parameters, URL, and cookie;

[0051] The extraction rule configuration unit obtains the configuration fields of the extraction rules set by the user based on the interactive configuration interface, and stores the extracted parameters in a variable pool. The parameters in the variable pool are used to convert into dynamic variables for Mock response, which improves the flexibility and dynamism of the Mock platform and enables the platform to better simulate data and behaviors in real scenarios; the configuration fields of the extraction rules include but are not limited to: simple extraction rules and parsing extraction rules. The simple extraction rules configure the field values ​​to be extracted and configure a default value. If the field value is not extracted, it is set to the default value; the parsing extraction rules extract parameters based on JSONPath expressions. Among them, the variable pool adopts a caching mechanism. When the Mock rule is triggered, variables can be quickly generated or retrieved. The cache is managed using strategies such as LRU to ensure the timeliness and space efficiency of the data.

[0052] The custom variable unit allows users to customize constants based on the interactive configuration interface according to business needs, and / or use the custom functions provided by the Mock platform to dynamically generate custom variables according to business logic. The variables are used to store in the variable pool for Mock response after the Mock rule is triggered. The variables in the variable pool are used to build response headers and response messages, making the simulated data more realistic and dynamic, and quickly access and use variables based on the variable pool; among them, custom constant types include but are not limited to: strings, numbers, Boolean values, JSON objects, and XML strings, which not only meet basic data needs, but also increase the expressiveness of data. Each custom constant is named and assigned a value based on the preset naming specification to improve the readability and maintainability of the code. Based on the above configuration, users can define constants through an intuitive graphical interface without writing code, which reduces the threshold for use.

[0053] The custom function unit is used to receive and approve uploaded custom functions and add them to the function library of the Mock platform, so that users can generate dynamic variables or simulate a series of complex operations. Custom functions can be generated based on Java or Python.

[0054] The Mock response unit is used to edit dynamic response header information based on the interactive configuration interface or generate dynamic response header information based on a custom function, and generate response messages based on a preset template. Extracted parameters, custom variables, and custom functions are allowed to be referenced in the response header information and response messages. Specifically, values ​​can be dynamically taken from the variable pool according to the variable name and replaced with the corresponding real value. Users can easily create and edit message templates to improve development efficiency. Custom variables and custom functions are referenced in response messages by referencing the variable name in the variable pool or the function name in the function library, expressed in the form of $variable name or ${function name}, which provides higher flexibility and dynamism for message generation and helps to adapt to various complex business scenarios and requirements. The formats of response messages include but are not limited to: Text, Json, Xml, Html, to meet the needs of different business scenarios. The mock response unit of the present application allows the user to dynamically edit in the mock configuration or use the custom function in the function library provided by the platform to generate dynamic response header information. When the user enters the response header value, it provides auxiliary input for variable selection, or allows the user to directly enter the variable format. When generating the response, the variables in the response header are parsed and the corresponding values ​​are obtained from the variable pool for replacement.

[0055] The cache unit is used to store the Mock rules that have been accessed and their matching results, so that after receiving repetitive Mock requests, the corresponding matching information can be directly matched based on the cache unit to avoid repeated calculations and improve response efficiency. The cache unit is configured to adopt a key-value pair storage structure and / or a hierarchical cache structure. In the cache unit, the cache data is configured with an expiration time, and a cache refresh mechanism is established based on the expiration time, allowing the cache to be cleared manually or automatically based on the expiration time when the Mock rules are updated, so as to regenerate a new cache.

[0056] Among them, the primary key of the key-value pair storage structure includes the URL and the request method, and the value includes the identifier of the Mock rule and its Mock response. The key-value pair storage structure can facilitate the rapid retrieval of the cached Mock results based on the URL. The hierarchical cache structure includes local cache and distributed cache. The local cache is used to store frequently accessed data, such as but not limited to the LRU cache (Least Recently Used, LRU). The distributed cache is used to store large-scale data or data shared across multiple service instances, such as but not limited to Redis and Memcached.

[0057] In the above embodiment, custom constants are divided into global constants and local constants according to their scope. The scope of global constants is the entire Mock platform, which is convenient for sharing across projects, interfaces and rules. The scope of local constants is valid in the current project, interface or Mock rule, providing more fine-grained control.

[0058] Custom variables are divided into temporary variables and persistent variables according to their life cycle. Temporary variables are destroyed after the response is generated and are suitable for one-time or short-life cycle data; persistent variables may remain valid across multiple requests or sessions and are suitable for data that needs to be stored or shared for a long time.

[0059] In the above embodiment, the custom variable unit provides the Mock platform with powerful customization capabilities and flexibility. Users can define various constants and functions according to business needs, and use caching mechanisms and improve performance. At the same time, through the management of scope and life cycle, the correctness and validity of data can be ensured. This enables the Mock platform to better simulate data and behavior in real scenarios and meet the testing requirements of various complex scenarios.

[0060] In another embodiment, the response header information also includes authentication information such as session and cookie. When generating a response, these security information are added to the response header to ensure the compliance and security of the request.

[0061] This flexible response header editing function can greatly improve the efficiency and accuracy of Mock testing. Through dynamic editing, reference mechanism and security information setting, users can easily simulate various complex test scenarios to ensure the correctness and stability of front-end applications in a variety of situations. When implementing, it is necessary to focus on the friendliness and ease of use of the user interface, as well as the security and stability of the functions.

[0062] In the above embodiment, when the cache unit is distributed caching, cache data sharing between multiple service instances is achieved through shared cache to improve the utilization of cache data and the overall performance of the platform. Specifically, the distributed cache is deployed in a location accessible to multiple service instances to ensure that all service instances can connect to the cache; the connection information of the distributed cache is configured in each service instance to ensure that the service instance can correctly connect to the cache unit and obtain or store data, and the acquisition, storage and sharing of cache data are achieved in the service instance through the API or client library provided by the distributed cache. When a service instance needs to access cached data, it can obtain it directly from the distributed cache; when the cached data needs to be updated, it can also store the new data in the distributed cache for sharing by other service instances.

[0063] In another embodiment, the cache unit can also analyze the collected historical request data, identify URLs with high access frequency, use data mining, machine learning or statistical methods to establish a prediction model, and predict URLs that may be frequently accessed in the future. A list containing URLs that may be frequently accessed is generated based on the prediction results. For each URL in the prediction list, a corresponding Mock response is prepared, and the URLs in the prediction list and their Mock responses are loaded into the cache unit. Furthermore, the actual request data is monitored and compared with the prediction results, and the prediction model and cache data are adjusted based on the comparison results.

[0064] In some of the embodiments, the Mock platform adopts a copy-on-write strategy when updating the Mock rules, which can ensure that when modifying the data, the old data being accessed will not be directly affected, thereby avoiding data inconsistency or access conflicts. Specifically, before modifying the Mock rules, a copy of the current old data is first copied to the cache unit. The copy operation is atomic, ensuring that it will not be interrupted by other operations during the copy process; then, the new Mock rules are modified based on the copied old data. This modification process is performed in an independent environment and will not affect the old data being accessed. When the new data modification is completed and takes effect, the old cache item needs to be marked as invalid or deleted. This can be achieved by adding a version number or timestamp to the cache item. When the cache item is accessed, this version number or timestamp is checked. If it is outdated, it is considered invalid. Finally, the modified new data is added to the cache and the relevant version number or timestamp is updated. At this time, the new Mock rule data begins to take effect for subsequent service instances to access. After a certain period of time, the old data marked as invalid can be cleaned up to release cache space.

[0065] Based on the above configuration, by adopting the write-time copy strategy, the cache consistency can be maintained when the Mock rules are updated, ensuring that the service instance will not encounter data inconsistency when accessing the cache. At the same time, this strategy can also improve the cache hit rate and the overall performance of the system.

[0066] In some of the embodiments, the Mock rule update and cache refresh are configured with a subscription and notification mechanism. When the Mock rule changes, the cache unit is informed to update the relevant cache items through the message queue or other notification mechanism. Specifically, a Mock rule update event is defined, which includes the identifier of the Mock rule, the updated timestamp, and the specific change content. A suitable message queue (such as RabbitMQ, Kafka, etc.) or other notification mechanism (such as Webhooks, WebSocket, etc.) is selected to transmit the Mock rule update event. An event publisher is implemented in the Mock rule management unit. When the Mock rule changes, it triggers and publishes a Mock rule update event to the message queue or notification mechanism. A subscriber is implemented in the cache unit, which listens to the Mock rule update event in the message queue or notification mechanism. When the subscriber receives an update event, it parses the event content, determines the cache item that needs to be updated, finds the corresponding cache item in the cache unit and updates it.

[0067] By implementing such a subscription and notification mechanism, it can be ensured that when the Mock rules change, the cache unit can be notified in time and update the relevant cache items, thereby maintaining the consistency and effectiveness of the cache.

[0068] In another embodiment, the cache unit monitors key indicators such as cache hit rate, miss rate, cache size, etc. in real time to timely discover and solve potential performance problems. In-depth analysis of cache access data is performed to understand user request patterns and access hotspots, providing data support for optimizing cache strategies and pre-fetch strategies.

[0069] In order to ensure that the platform can run stably in high-concurrency scenarios, the platform of this embodiment also adopts load balancing technology; in addition, the platform supports data backup and disaster recovery functions to ensure data security and reliability, provides detailed logging functions to facilitate users to track problems and conduct audit analysis, and also provides rich help documents and cases to lower the user threshold.

[0070] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0071] This embodiment also provides a network request simulation processing method. Figure 1 to Figure 2 is a flowchart of a network request simulation processing method according to an embodiment of the present application. Figure 1 to Figure 2 As shown, the process includes the following steps:

[0072] Request initiation step S1, using the Mock platform to initiate a Mock request;

[0073] Request matching step S2, receiving the Mock request, querying whether the corresponding URL exists in the cache unit, if so, it is determined to hit the cache, and rule matching is performed to determine the Mock rule or directly return the Mock response stored in the cache unit; otherwise, a database query is performed;

[0074] Database query step S3, based on the Mock request, obtains the query result in the database according to the established index condition, and determines the Mock rule by rule matching based on the query result, wherein a composite index is configured for the key fields in the Mock rule in the database table, and the key fields include URL and request method, so as to quickly locate the possibly related Mock rule set in the database, and then further accurately match, when the value of the request method field is less than the value of the URL field, the request method field is configured in front of the composite index;

[0075] In the dynamic message generation step S4, the deep parsing engine performs parameter extraction, custom variable parsing, custom function parsing, response header parsing and replacement, and response message parsing and replacement in sequence based on the matched Mock rules, and returns the response information. Otherwise, it returns the unmatched result. The Mock platform makes a real-time judgment and starts the transparent transmission mechanism. The transparent transmission mechanism uses efficient network forwarding technology to quickly and accurately forward the Mock request to the backend service for processing, avoiding problems such as test failure or data loss caused by improper configuration of Mock rules.

[0076] Based on the above request matching steps and database query steps, a preliminary screening is first performed based on the URL and request method of the cache unit or index condition to narrow the matching scope, and then an in-depth match is performed in the rule matching. Multi-layer matching is supported to ensure that matching Mock rules are found quickly and accurately in massive requests, thereby improving the overall performance and user experience of the platform.

[0077] In some embodiments, the dynamic message generating step S4 further comprises:

[0078] Parameter extraction step S41, parsing the configuration field in the Mock rule and extracting the parameters of the configuration field;

[0079] The custom variable parsing step S42 checks whether the custom variable is referenced in the Mock rule. If the custom variable is referenced, the corresponding variable value is obtained from the variable pool and replaced to the position specified in the Mock rule;

[0080] The custom function parsing step S43 checks whether the custom function is used in the Mock rule; if the custom function is used, the corresponding function in the function library is called, and the function return value is replaced to the position specified in the Mock rule;

[0081] Response header parsing and replacement step S44, parsing the response header defined in the Mock rule, if the response header references a parameter, a custom variable or a custom function, then a corresponding replacement is performed, and the response header after the replacement is completed will be added to the response information;

[0082] The response message parsing and replacing step S45 parses the response message defined in the Mock rule. If the response message references parameters, user-defined variables or user-defined functions, corresponding replacements are performed. The response message after the replacement is completed will be used as the main body of the response information.

[0083] Through the above steps, based on the matched Mock rules, the platform can dynamically generate and return response information, and generate more complex and diverse response data by referencing variables or calling functions to meet various complex testing requirements. Users can configure Mock rules more concisely. Complex Mock logic can be implemented without writing complex codes or scripts, and developers and testers can create and manage Mock data more efficiently. This helps shorten the development cycle, improve testing efficiency, and thus accelerate the overall progress of the project.

[0084] In some embodiments, rule matching is performed layer by layer based on the field level until the matched Mock rule is determined and stored in the cache unit for responding to repeated Mock requests. If the Mock rule cannot be matched, the unmatched result is returned. The field level is configured based on the request header, request body, etc. The Mock rules include: simple field matching rules, regular expression matching rules, and JSONPath expression matching rules. If there are still multiple Mock rules at the request header level, they are further matched according to the content in the request body, and so on.

[0085] The simple field matching in the above-mentioned embodiment is to directly set matching rules for simple fields in the request (such as URL parameters, request header fields, Cookies, request parameters, etc.), and the matching conditions include: equal to, not equal to, between, contains, does not contain, empty, non-empty and other relationships. Equal to means that the field value must be completely equal to the specified value; not equal to means that the field value cannot be equal to the specified value; between means that the field value of the numeric type field is set between two specified values ​​(including the boundary value); contains is used to check whether the field value of the string type field contains the specified substring; does not contain is used to check whether the field value does not contain the specified substring; empty is used to check whether the field value is empty or null; conversely, non-empty is used to check whether the field value is not empty.

[0086] The regular expression matching rules in the above embodiment are applicable to scenarios that require complex pattern matching, and can be implemented using the regular expression provided by the Mock platform. The JSONPath expression matching rules are applicable to request bodies in JSON format, and JSONPath expressions can be used to specify specific locations in the JSON document, thereby extracting the field value setting rules that need to be matched.

[0087] This application provides users with comprehensive and flexible Mock rule customization capabilities, which enables the Mock platform to better meet users' testing needs in various complex scenarios.

[0088] In some of the embodiments, in the request matching step S2, Mock rules are stored and searched based on a hash table to significantly improve the matching efficiency in massive requests, and the search operation can be completed within constant time or logarithmic time complexity.

[0089] In some of the embodiments, the Mock rules are configured with priorities. When there are multiple matching rules, the rules with higher priorities will be applied first. If there are multiple matching rules with the same priority, they can be further sorted and selected according to the creation time, update time or other custom fields of the rules, thereby improving the matching efficiency. By setting different priorities, multiple rules can be flexibly managed, making the application of rules more orderly and efficient.

[0090] It should be noted that the steps shown in the above process or the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0091] The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0092] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A custom mock platform, characterized in that: include: A mock rule management unit, which obtains configuration fields of mock rules based on an interactive configuration interface; An extraction rule configuration unit, which obtains configuration fields of the extraction rule based on the interactive configuration interface, stores the extracted parameters in a variable pool, and the parameters in the variable pool are used to be converted into dynamic variables; A custom variable unit is used to customize constants based on the interactive configuration interface, and / or dynamically generate custom variables using custom functions provided by the Mock platform. The variables are used to store in the variable pool for Mock response after the Mock rule is triggered. The variables in the variable pool are used to construct the response header and response message; The custom function unit is used to receive and approve uploaded custom functions and add them to the function library of the Mock platform; The mock response unit is used to edit the dynamic response header information based on the interactive configuration interface or generate the dynamic response header information based on the custom function, and generate the response message based on the preset template, allowing the extracted parameters and custom variables and custom functions to be referenced in the response header information and the response message.

2. The custom mock platform according to claim 1, characterized in that: The custom variables and custom functions referenced in the response message are implemented by referencing the variable names in the variable pool or the function names in the function library, which are expressed in the form of $variable name or ${function name}.

3. The custom mock platform according to claim 1, characterized in that: Also includes: The cache unit is used to store the visited Mock rules and their matching results. The cache unit is configured to adopt a key-value pair storage structure and / or a hierarchical cache structure.

4. The custom mock platform according to claim 1 or 2, characterized in that: The Mock platform adopts a copy-on-write strategy when updating Mock rules.

5. The custom mock platform according to claim 4, characterized in that: Mock rule updates and cache refresh configurations have subscription and notification mechanisms.

6. A network request simulation processing method, based on the custom mock platform described in any one of claims 1 to 5, characterized in that: include: Request initiation step: use the Mock platform to initiate a Mock request; Request matching step, receiving the Mock request, querying whether the corresponding URL exists in the cache unit, if so, it is judged as a cache hit, and rule matching is performed to determine the Mock rule or directly return the Mock response stored in the cache unit; otherwise, a database query is performed; A database query step, obtaining query results in the database according to the established index conditions based on the Mock request, and performing rule matching based on the query results to determine the Mock rules, wherein a composite index is configured in the database table for the key fields in the Mock rules; The dynamic message generation step performs parameter extraction, custom variable parsing, custom function parsing, response header parsing and replacement, response message parsing and replacement in sequence based on the matched Mock rules, and returns the response information.

7. The network request simulation processing method according to claim 6, characterized in that: The dynamic message generation step further comprises: Parameter extraction step: parse the configuration fields in the Mock rule and extract the parameters of the configuration fields; Custom variable parsing step: check whether the custom variable is referenced in the Mock rule. If the custom variable is referenced, get the corresponding variable value from the variable pool and replace it with the position specified in the Mock rule; Custom function parsing step, check whether the custom function is used in the Mock rule; if the custom function is used, call the corresponding function in the function library and replace the function return value to the position specified in the Mock rule; Response header parsing and replacement step: parse the response header defined in the Mock rule. If the response header references parameters, custom variables or custom functions, corresponding replacements are performed. After the replacement, the response header will be added to the response information. The response message parsing and replacement step parses the response message defined in the Mock rule. If the response message references parameters, custom variables or custom functions, corresponding replacements are performed. The response message after replacement is used as the main part of the response information.

8. The network request simulation processing method according to claim 7, characterized in that: The rule matching is performed layer by layer based on the field level in turn until the matched Mock rule is determined and stored in the cache unit. The Mock rule includes: simple field matching rule, regular expression matching rule, and JSONPath expression matching rule.

9. The network request simulation processing method according to claim 7, characterized in that: In the request matching step, Mock rules are stored and searched based on a hash table.

10. The network request simulation processing method according to claim 9, characterized in that: The Mock rule is configured with a priority. When there are multiple matching rules, the rule with a higher priority will be applied first.

Images