Request response method and device, equipment and medium

Abstract

The invention belongs to the field of research and development, and relates to a request response method which comprises the following steps: receiving a test request; according to the identifier in the test request, configuration information is obtained from a system cache, and the configuration information comprises request type data, parameter processing data and response result configuration information; matching a test request type in the test request with a request type indicated by the request type data; if the test request type is matched with the request type, processing parameter information in the test request according to the parameter processing data to obtain a complete request parameter; and generating response data corresponding to the test request based on the request parameter and the response result configuration information. The invention further provides a request response device, equipment and a medium. In addition, the invention also relates to a block chain technology, and the configuration information can be stored in a block chain. The test efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of R & D technology, and particularly to a request response method, apparatus, device and medium. Background Art

[0002] In the current system development process, it has become normal to achieve data interaction between systems through HTTP(S) requests. However, when docking with HTTP(S) interfaces provided by third parties, developers and testers often face many challenges. For example, inconsistent development progress between the two parties may lead to delays in interface docking, or the need to temporarily write fake data code, which not only affects the development progress but also increases the complexity of the code. In addition, when one party's interface is still under development while the other party needs to conduct tests, there is a lack of an effective simulated response mechanism. To verify the system processing logic, testers often need to rely on extreme scenario response data provided by the other party, but the acquisition of such data is often inconvenient, affecting the efficiency and accuracy of function verification.

[0003] To solve the above problems, the mock service came into being. The mock service can simulate the response results of HTTP(S) interfaces, facilitating developers and testers to call at any time, and setting response data according to test scenarios to verify various extreme business scenarios. However, there are many deficiencies in current mock service products in the industry. Some products require registration and payment to use, which is not only inconvenient but also has potential data security risks. Open-source products, on the other hand, have a large number of functions, complex deployment, and a high learning threshold, which is particularly unfriendly to white-box testers who are not familiar with programming and results in low testing efficiency. Summary of the Invention

[0004] The purpose of the embodiments of this application is to propose a request response method, apparatus, device and medium to solve the problems of existing mock services having a large number of functions, complex deployment, and low testing efficiency.

[0005] To solve the above technical problems, the embodiments of this application provide a request response method, which adopts the following technical solutions:

[0006] Receive a test request; according to the identifier in the test request, obtain configuration information from the system cache, where the configuration information includes request type data, parameter processing data, and response result configuration information; match the test request type in the test request with the request type indicated by the request type data; if there is a match between the test request type and the request type, process the parameter information in the test request according to the parameter processing data to obtain complete request parameters; generate response data corresponding to the test request based on the request parameters and the response result configuration information.

[0007] Further, the step of processing the parameter information in the test request according to the parameter processing data to obtain complete request parameters specifically includes:

[0008] Parse and process the parameter processing data to obtain the parameter parsing result, and extract parameter information from the test request; compare the parameter parsing result with the parameter information to determine whether the parameter information is complete; if the parameter information is incomplete, supplement the missing parameters in the parameter information according to the parameter parsing result to obtain the complete request parameters.

[0009] Further, the step of generating the response data corresponding to the test request based on the request parameters and the response result configuration information specifically includes:

[0010] Identify the processing mode indicated by the response result configuration information; if the processing mode indicated by the response result configuration information is the template return mode, obtain the preset first template data based on the request parameters, and use the first template data as the response data corresponding to the test request; if the processing mode indicated by the response result configuration information is the template matching mode, obtain the preset request field values based on the request parameters, match the request field values with the field values of the preset template data to obtain the matching second template data, and use the second template data as the response data; if the processing mode indicated by the response result configuration information is the script processing mode, obtain the preset logic processing script based on the request parameters, input the request parameters into the logic processing script for processing to obtain the result data after logic processing, and use the result data as the response data.

[0011] Further, before the step of obtaining the configuration information from the system cache according to the identifier in the test request, it further includes:

[0012] Judge whether the test request has an identifier; if the test request does not have an identifier, generate an exception message, encapsulate the exception message into a preset format to obtain the encapsulated exception message; return the encapsulated exception message to the sender of the test request.

[0013] Further, after the step of generating the response data corresponding to the test request based on the request parameters and the response result configuration information, it further includes:

[0014] Judge whether the response time is set in the configuration information; if the response time is set, obtain the start time and the current time of the test request, and calculate the time difference between the start time and the current time; if the time difference is less than the response time, wait for the remaining time by thread sleep until the response time is reached, and return the response data to the sender of the test request.

[0015] Further, after the step of generating the response data corresponding to the test request based on the request parameters and the response result configuration information, it further includes:

[0016] Determine whether callback information is set in the configuration information; if callback information is set, obtain the callback address, callback data, and callback interval time from the callback information; create a scheduled task based on the callback interval time; when the scheduled task is triggered, initiate a callback request through the callback address and pass the callback data into the callback request.

[0017] Further, after the step of obtaining the configuration information from the system cache according to the identifier in the test request, it further includes:

[0018] If a flow limiting parameter is set in the configuration information, obtain the queries per second rate of the current request; determine whether the queries per second rate reaches a preset flow limiting threshold; if the queries per second rate reaches the flow limiting threshold, process the test request according to a preset exception handling strategy;

[0019] The step of matching the test request type in the test request with the request type indicated by the request type data specifically includes:

[0020] If the queries per second rate does not reach the flow limiting threshold, match the test request type in the test request with the request type indicated by the request type data.

[0021] To solve the above technical problems, an embodiment of the present application further provides a request response device, which adopts the following technical solutions:

[0022] A receiving module, used to receive a test request;

[0023] A first obtaining module, used to obtain configuration information from the system cache according to the identifier in the test request, where the configuration information includes request type data, parameter processing data, and response result configuration information;

[0024] A first matching module, used to match the test request type in the test request with the request type indicated by the request type data;

[0025] A first processing module, used to if there is a match between the test request type and the request type, process the parameter information in the test request according to the parameter processing data to obtain complete request parameters;

[0026] A generating module, used to generate response data corresponding to the test request based on the request parameters and the response result configuration information.

[0027] To solve the above technical problems, an embodiment of the present application further provides a computer device, including a memory and a processor, where computer-readable instructions are stored in the memory, and when the processor executes the computer-readable instructions, the steps of the above request response method are implemented.

[0028] To solve the above technical problems, an embodiment of the present application further provides a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor, so that at least one processor executes the steps of the request response method as described above.

[0029] Compared with the prior art, the embodiments of the present application mainly have the following beneficial effects: Through an innovative baffle service design, the system development and testing processes are significantly optimized. Specifically, it can receive test requests and quickly retrieve the corresponding configuration information from the system cache according to the identifiers in the test requests. This configuration information not only covers the request type, parameter processing rules, but also clearly defines the format requirements of the response data, thereby achieving an accurate simulation of the response results of HTTP(S) interfaces. After matching the test request type in the test request with the request class indicated by the request type data, it can intelligently improve the parameter information according to the parameter processing data to ensure the authenticity and effectiveness of the test environment. In this process, there is no need for cumbersome registration or additional code writing, greatly reducing the usage threshold and improving the testing efficiency. It can dynamically generate the response data corresponding to the test requests based on the request parameters and response result configuration information. This function not only supports the simulation of complex business scenarios, but also allows developers and testers to flexibly set the response content according to actual needs, thereby comprehensively verifying the correctness and stability of the system processing logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] To more clearly illustrate the solutions in the present application, the following will briefly introduce the drawings required for the description of the embodiments of the present application. Obviously, the following drawings are 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.

[0031] Figure 1 is an exemplary system architecture diagram to which the present application can be applied;

[0032] Figure 2 is a flowchart of a request response method provided by the present application;

[0033] Figure 3 is a structural diagram of a request response device provided by the present application;

[0034] Figure 4 is a structural diagram of a computer device provided by the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0035] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field to which this application belongs; the terms used in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above drawings are intended to cover non-exclusive inclusion. The terms "first", "second", etc. in the specification and claims of this application or the above drawings are used to distinguish different objects and not to describe a specific order.

[0036] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in connection with the embodiments can be included in at least one embodiment of this application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0037] To enable those skilled in the technical field to better understand the solution of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0038] As Figure 1 shown, the system architecture 100 may include a terminal device 101, a network 102, and a server 103. The terminal device 101 may be a laptop computer 1011, a tablet computer 1012, or a mobile phone 1013. The network 102 is a medium for providing a communication link between the terminal device 101 and the server 103. The network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0039] A user may use the terminal device 101 to interact with the server 103 through the network 102 to receive or send messages, etc. Various communication client applications may be installed on the terminal device 101, such as a web browser application, a shopping application, a search application, an instant messaging tool, an email client, a social platform software, etc.

[0040] The terminal device 101 can be various electronic devices with a display screen and supporting web browsing. In addition to the laptop computer 1011, the tablet computer 1012, or the mobile phone 1013, the terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV) player, a laptop portable computer, a desktop computer, and the like.

[0041] The server 103 can be a server that provides various services, such as a background server that supports the pages displayed on the terminal device 101.

[0042] It should be noted that the request response method provided by the embodiments of the present application is generally executed by the server. Correspondingly, the request response device is generally set in the server.

[0043] It should be understood that Figure 1 the numbers of the terminal devices, the network, and the server in

[0044] are merely illustrative. According to the implementation requirements, there can be any number of terminal devices, networks, and servers. Figure 2 Continuing to refer to

[0045] shows a flowchart of an embodiment of the request response method according to the present application. The request response method includes the following steps:

[0046] In this embodiment, the electronic device (such as Figure 1 the server shown) on which the request response method runs can receive the test request through a wired connection method or a wireless connection method. It should be noted that the above wireless connection method can include but is not limited to 3G / 4G / 5G connection, WiFi connection, Bluetooth connection, WiMAX connection, Zigbee connection, UWB (ultrawideband) connection, and other currently known or future-developed wireless connection methods.

[0047] Among them, the test request refers to an HTTP request sent by a test system or a tester to the baffle service, which is used to simulate the actual business scenario. The test request contains key information such as the request method (such as GET, POST, etc.), the request URL, and the request parameters, which are used to trigger the baffle service to generate and return the corresponding response data.

[0048] Step S202: Obtain configuration information from the system cache according to the identifier in the test request. The configuration information includes request type data, parameter processing data, and response result configuration information.

[0049] Among them, the identifier is the characteristic information used to uniquely identify the request and its corresponding interface in the test request. It can be a part of the request URL, a certain field in the request header, or a specific parameter in the request body. Through the identifier, the baffle service can identify and process the corresponding test request. For example, a test request for an API interface may contain a specific interface name as the identifier.

[0050] Among them, the system cache refers to the memory area used to store temporary data to improve data access speed. The system cache is used to store configuration information, including request type data, parameter processing data, and response result configuration information, etc. These data are frequently accessed during the test request processing, and using the cache can improve the processing efficiency. For example, the system cache may store the configuration information of multiple interfaces.

[0051] Among them, the configuration information refers to the data set used to guide the baffle service on how to process the test request. It includes request type data (such as GET, POST, etc.), parameter processing data (such as parameter verification rules, default values, etc.), and response result configuration information. The configuration information can be set by developers or testers according to actual needs.

[0052] Among them, the request type data refers to the HTTP method type used by the test request, such as GET, POST, PUT, DELETE, etc. It is used to identify the operation type of the test request, such as reading data, submitting data, updating data, or deleting data. For example, a test request for querying user information can use the GET method.

[0053] Among them, the parameter processing data refers to the data set for parsing, verifying, converting, etc. the parameters in the test request. It may contain information such as the name, type, verification rules, default values, etc. of the parameters. The parameter processing data is used to ensure that the parameters in the test request meet the expected requirements. For example, a parameter processing data may require a certain parameter to be of integer type and not be empty.

[0054] Among them, the response result configuration information refers to a set of parameters or rules in the baffle service's configuration information used to set how to generate and return the response data corresponding to the test request. This information determines how the baffle service generates the response data according to the preset method and returns it to the sender of the test request after receiving the test request.

[0055] Step S203: Match the test request type in the test request with the request type indicated by the request type data.

[0056] Among them, the test request type refers to the parameter that is clearly specified in the test request and is used to describe the HTTP method or request method used in this test request. The test request type determines how the baffle service parses and processes the received test request, including how to parse request parameters, how to generate response data, etc.

[0057] Among them, the request type refers to the parameter that is preset in the configuration information of the baffle service and is used to describe the HTTP method or request method used in the expected received test request. The request type in the configuration information is not used to describe the actually received test request, but to match and filter test requests. The baffle service will judge whether the actually received test request meets the expectations according to the request type in the configuration information, so as to decide how to process this request. If the test request type in the test request matches the request type in the configuration information, then the baffle service will generate and process response data according to other parameters in the configuration information (such as parameter processing data, response data configuration information, etc.). If they do not match, the baffle service will return an exception message or perform other specified operations.

[0058] Among them, matching refers to the process of comparing the test request type in the test request with the request type data in the configuration information to determine whether they are the same. After successful matching, the baffle service will process the test request according to the rules in the configuration information.

[0059] Step S204, if there is a match between the test request type and the request type, process the parameter information in the test request according to the parameter processing data to obtain complete request parameters.

[0060] Among them, the parameter information refers to the data carried in the test request for interacting with the baffle service. It may include request headers, parameters in the request body, etc. The parameter information is used to transfer user input data or instructions to the baffle service. For example, the parameter information of a login request may include a username and a password.

[0061] Among them, the request parameter refers to the parameter information that has been processed and meets the requirements of the parameter processing data in the configuration information. It can contain parameter values after verification, conversion, and default value filling. The request parameter is used to ensure that the parameters in the test request meet the expected requirements so that the baffle service can correctly generate response data. For example, a processed request parameter contains a verified username and password.

[0062] Step S205, generate response data corresponding to the test request based on the request parameters and the response result configuration information.

[0063] Among them, the response data refers to the data generated by the baffle service according to the test request and configuration information and returned to the sender of the test request. It can include status codes, message bodies, etc. The response data is used to simulate the response results of HTTP(S) interfaces so that testers can verify the correctness of the system processing logic. For example, a response data may contain the results of simulating successful or failed logins.

[0064] The embodiments of this application can significantly optimize the system development and testing processes through innovative baffle service designs. Specifically, it can receive test requests and quickly retrieve the corresponding configuration information from the system cache based on the identifiers in the test requests. This configuration information not only covers request types, parameter processing rules, but also clarifies the format requirements of the response data, thus achieving accurate simulation of the response results of HTTP(S) interfaces. After matching the test request type in the test request with the request class indicated by the request type data, it can intelligently improve the parameter information according to the parameter processing data to ensure the authenticity and effectiveness of the test environment. In this process, there is no need for cumbersome registration or additional code writing, greatly reducing the usage threshold and improving the testing efficiency. It can dynamically generate the response data corresponding to the test request based on the request parameters and response result configuration information. This function not only supports the simulation of complex business scenarios, but also allows developers and testers to flexibly set the response content according to actual needs, thus comprehensively verifying the correctness and stability of the system processing logic.

[0065] In some alternative implementation manners of this embodiment, before obtaining the configuration information from the system cache according to the identifier in the test request in step 202, the following steps are further included:

[0066] Judge whether the test request has an identifier; if the test request does not have an identifier, generate an exception message, encapsulate the exception message into a preset format to obtain the encapsulated exception message; return the encapsulated exception message to the sender of the test request.

[0067] Among them, the exception message refers to the information generated by the baffle service during the processing of the test request and used to indicate that an error has occurred. It can include error codes, error messages, etc. The exception message is used to help developers or testers locate and solve problems. For example, an exception message can indicate that necessary parameters are missing in the test request.

[0068] In one example, assume that a financial trading system is simulating tests on a trading interface. The test requests are sent by the test team to the mock server corresponding to the mock service. The mock server receives a test request, which is used to simulate the payment function of the test trading interface. It is determined whether the test request contains an identifier, such as the transaction type code "PAY001". If the identifier is missing from the request, the nature and purpose of the test request cannot be accurately identified. Since the identifier is missing from the test request, an exception message is generated. The exception message includes the exception type "Missing Identifier", the exception code "ERR001", and the exception description "The necessary identifier is missing from the test request and processing cannot continue". Subsequently, this exception message is encapsulated in JSON format for subsequent processing and transmission. The encapsulated exception message is returned to the sender of the test request, i.e., the test team. The test team can understand the processing result of the test request based on the returned exception message and make corresponding adjustments or corrections, such as resending the test request after adding the missing identifier.

[0069] In the embodiments of the present application, by determining whether an identifier exists in the test request, invalid requests caused by missing identifiers can be effectively identified and processed, avoiding waste of test resources due to incorrect request formats. When a request without an identifier is detected, an exception message is generated and encapsulated in a unified format and then returned. This not only ensures the standardization and readability of the exception message, but also helps testers quickly locate the problem, reducing the time cost of troubleshooting errors.

[0070] In some optional implementation manners of this embodiment, in step 204, the parameter information in the test request is processed according to the parameter processing data to obtain complete request parameters, which specifically includes the following steps:

[0071] The parameter processing data is parsed to obtain a parameter parsing result, and the parameter information is extracted from the test request; the parameter parsing result is compared with the parameter information to determine whether the parameter information is complete; if the parameter information is incomplete, the missing parameters in the parameter information are supplemented according to the parameter parsing result to obtain complete request parameters.

[0072] Among them, the parameter information being incomplete means that the parameter information in the test request does not meet the requirements of the parameter processing data in the configuration information, such as missing necessary parameters, parameter type mismatches, or parameter values not meeting expectations, etc. Incomplete parameter information may cause the mock service to be unable to correctly generate response data. For example, a login request may be missing the username or password parameter.

[0073] In one example, an HTTP POST request is set as a test request, which is intended to send a product listing request to the product information interface of an e-commerce platform. The test request contains key parameters such as product ID, name, price, and inventory. First, after the baffle service receives the test request, it parses and processes the parameter processing data in the request body, using a JSON format parsing algorithm to obtain the parameter parsing result. Subsequently, the actual parameter information is extracted from the test request. For example, the product ID is "12345", the name is "New Mobile Phone", and the price is "1999 yuan", but the inventory parameter is missing. Next, the baffle service compares the parameter parsing result with the extracted parameter information and finds that the inventory parameter is missing. At this time, according to the preset parameter parsing result library, the baffle service automatically supplements the default value of "100 pieces" for the inventory parameter to obtain a complete set of request parameters. The request parameters after completion are used by the baffle service to simulate the generation of responses, ensuring the integrity and effectiveness of the test request.

[0074] In the embodiment of the present application, by parsing and processing the parameter processing data, extracting parameter information from the test request, and comparing the parameter information with the preset parameter parsing result, the integrity of the parameter information can be quickly determined. When it is found that the parameter information is missing, the missing parameter can be intelligently supplemented according to the parameter parsing result to ensure the comprehensiveness and accuracy of the request parameters. In this process, no manual intervention is required, which reduces the workload of testers and improves the test efficiency. At the same time, since the missing parameters can be automatically completed, the test failure caused by incomplete parameters is avoided, further improving the accuracy and reliability of the test.

[0075] In some optional implementation manners of this embodiment, in step S205, based on the request parameters and the response result configuration information, the response data corresponding to the test request is generated, which specifically includes the following steps:

[0076] Identify the processing mode indicated by the response result configuration information; if the processing mode indicated by the response result configuration information is the template return mode, obtain the preset first template data based on the request parameters, and use the first template data as the response data corresponding to the test request; if the processing mode indicated by the response result configuration information is the template matching mode, obtain the preset request field value based on the request parameters, match the request field value with the field value of the preset template data to obtain the matched second template data, and use the second template data as the response data; if the processing mode indicated by the response result configuration information is the script processing mode, obtain the preset logic processing script based on the request parameters, input the request parameters into the logic processing script for processing to obtain the result data after logic processing, and use the result data as the response data.

[0077] Among them, the processing mode refers to different ways or strategies used by the mock service to generate response data. It includes the template return mode, the template matching mode, the script processing mode, etc. The selection of the processing mode depends on the type of the test request and the requirements in the configuration information.

[0078] Among them, the template return mode refers to the processing mode in which the mock service directly obtains the preset template data according to the request parameters and returns it as the response data to the sender of the test request. This mode is applicable to the situation where the response data format is fixed and does not require dynamic generation.

[0079] Among them, the first template data refers to the preset template data directly obtained by the mock service according to the request parameters in the template return mode. It usually contains fixed fields and values and is used to simulate the response results of HTTP(S) interfaces.

[0080] Among them, the template matching mode refers to the processing mode in which the mock service obtains the preset request field values according to the request parameters and matches them with the field values of the template data to generate the response data that meets the requirements. This mode is applicable to the situation where the response data needs to be dynamically generated according to the request parameters.

[0081] Among them, the request field value refers to the data carried in the test request and used to match the field values of the template data. The request field value is used to determine which field data should be returned in the template data.

[0082] Among them, the template data refers to the preset data set used by the mock service to match the request field values in the template matching mode. It usually contains multiple fields and corresponding values and is used to simulate the response results of HTTP(S) interfaces.

[0083] Among them, the second template data refers to the response data that meets the requirements obtained by the mock service after matching the request field values with the field values of the template data in the template matching mode.

[0084] Among them, the script processing mode refers to the processing mode in which the mock service obtains the preset logic processing script according to the request parameters and inputs the request parameters into the script for processing to generate the response data that meets the requirements. This mode is applicable to the situation where the response data needs to be dynamically generated according to complex logic.

[0085] Among them, the logic processing script refers to the custom script used by the mock service to process the request parameters and generate the response data in the script processing mode. The logic processing script is used to implement complex business logic processing.

[0086] Among them, the result data refers to the data obtained after the logic processing script processes the request parameters. The result data is used as the response data to be returned to the sender of the test request.

[0087] In one example, when the configuration information indicates the template return mode, the corresponding first template data is retrieved from the preset template database according to the key fields in the request parameters. For example, if the test request is a request to query user information, the standard template data containing the user information can be obtained from the template library based on the user ID field and directly returned as the response data to the sender of the test request. This mode is applicable to scenarios that do not require complex logic processing and can quickly generate standard response data.

[0088] When the configuration information indicates the template matching mode, specific request field values are obtained according to the request parameters, such as product ID, order number, etc. Then, these field values are matched with the field values in the preset template data to find the second template data that best matches the current request. For example, if the test request is to query the details of a specific product, the product details template that best matches can be found according to the product ID and returned to the sender of the test request. This mode is applicable to scenarios that require dynamic adjustment of response data according to request parameters.

[0089] When the configuration information indicates the script processing mode, the preset logic processing script is obtained according to the request parameters, and the request parameters are input into the script for processing. After the script processing is completed, the processing result is returned as the response data to the sender of the test request. For example, if the test request is to simulate the user payment process, the payment logic script can be called to simulate the payment process according to the request parameters (such as payment amount, user information, etc.) and generate the payment result data as the response.

[0090] The embodiments of the present application can flexibly simulate the response data of HTTP(S) interfaces by providing three processing modes: template return, template matching, and script processing. This not only reduces the development and testing costs, but also improves the testing efficiency and accuracy, providing strong support for system development and testing work.

[0091] In some optional implementation manners of this embodiment, after generating the response data corresponding to the test request based on the request parameters and the response result configuration information in step S205, the following steps are further included:

[0092] Judge whether a response time is set in the configuration information; if the response time is set, obtain the start time and the current time of the test request, and calculate the time difference between the start time and the current time; if the time difference is less than the response time, wait for the remaining time by thread sleep until the response time is reached, and return the response data to the sender of the test request.

[0093] Among them, the response time refers to the time required for the baffle service to process the test request and generate the response data. It can be set in the configuration information to simulate the response delay of the HTTP(S) interface.

[0094] Among them, the start time refers to the time point when the baffle service starts to process the test request. It is used to compare with the current time to calculate the response time. The start time can be automatically recorded by the baffle service when processing the test request. For example, a start time may be a timestamp.

[0095] Among them, the current time refers to the instant time point recorded or obtained by the system when the baffle service processes the test request. This time point is used to calculate the time taken to process the test request, determine whether the preset response time is reached, etc.

[0096] In an example, the baffle service receives an HTTP(S) test request from the test system and obtains configuration information from the system cache. If the response time is clearly set in the configuration information, the baffle service will record the start time of the test request and obtain the current time in real time. Then, it calculates the time difference between the start time and the current time, and determines whether the time difference is less than the set response time. If the time difference is less than the response time, the baffle service will start the thread sleep mechanism and wait for the remaining time until the preset response time is reached. For example, if the preset response time is 5 seconds and only 2 seconds have passed after the test request arrives, the baffle service will sleep for 3 seconds and then continue to process. After reaching the set response time, the baffle service returns the predefined response data to the sender of the test request. This mechanism enables testers to accurately simulate various delay scenarios and verify the processing logic of the system under different response times.

[0097] When simulating the response of the HTTP(S) interface, the baffle service in the embodiment of the present application can intelligently and accurately control according to the response time setting in the configuration information. When a test request arrives, it first determines whether the response time is specified in the configuration. If it is set, it calculates the time difference between the current time and the request start time through precise time calculation. If the time difference is less than the set response time, it will intelligently start the thread sleep mechanism and wait until the preset response time before returning the response data. This mechanism ensures that the test request can simulate the delayed response in the real scenario, providing a more realistic test environment for developers and testers. At the same time, this solution does not require complex programming or additional configuration, reducing the usage threshold and improving the test efficiency.

[0098] In some optional implementation manners of this embodiment, after generating the response data corresponding to the test request based on the request parameters and the response result configuration information in step S205, the following steps are further included:

[0099] Determine whether callback information is set in the configuration information; if callback information is set, obtain the callback address, callback data, and callback interval time from the callback information; create a scheduled task based on the callback interval time; when the scheduled task is triggered, initiate a callback request through the callback address and pass the callback data into the callback request.

[0100] Among them, the callback information refers to a set of parameters preset in the configuration information of the baffle service for triggering callback operations under specific conditions. These parameters include the callback address, callback data, and callback interval time, etc., and are used to send a callback request containing specific data to the specified address after the test request is processed. For example, when the test request is processed successfully and another system needs to be notified, the baffle service will initiate a callback request based on the callback data.

[0101] Among them, the scheduled task refers to a task preset in the baffle service that automatically executes according to a specific time interval or condition. In the callback mechanism of the baffle service, the scheduled task is usually used to trigger a callback request when the callback interval time arrives. For example, when the callback information and callback interval time are set in the configuration information, the baffle service will create a scheduled task and initiate a callback request through the callback address when the scheduled task is triggered.

[0102] Among them, the callback request refers to a request sent by the baffle service to the specified callback address under specific conditions according to the callback data. The request contains the callback data and is used to provide detailed information about the test request processing situation to the system receiving the callback data. For example, in the payment interface test, the baffle service will send a callback request containing payment status and other information to the e-commerce platform according to the payment result.

[0103] In one example, when the baffle service receives configuration information, it will perform a preliminary parsing to determine whether it contains the setting of callback information. Callback information usually includes a callback address (i.e., the server address for receiving callback requests), callback data (i.e., the data content to be passed in the callback request), and a callback interval time (i.e., the time interval for triggering callback requests). If the callback information is indeed set in the configuration information, the baffle service will create a scheduled task based on this information. The creation of the scheduled task is based on the callback interval time to ensure that the callback request is triggered at the specified time point. This mechanism allows testers to simulate the asynchronous callback process in a real business scenario, thereby verifying the system's processing ability for asynchronous responses. When the scheduled task is triggered, the baffle service will initiate an HTTP(S) callback request through the previously obtained callback address and pass the callback data as the request body or parameters. During this process, the baffle service can simulate different network latencies, error codes, etc. to comprehensively test the system's performance under different conditions. For example, taking an actual e-commerce system as an example, assume that its payment interface needs to be docked with a third-party payment platform. Before the payment interface is actually docked with the third-party payment platform, testers can use the baffle service in this embodiment to configure a simulated payment success callback. By setting the callback address, callback data (such as payment success information, order number, etc.), and callback interval time (such as immediately callback after simulating payment success), testers can verify the processing logic of the e-commerce system after receiving the payment success callback, such as updating the order status, sending notifications, etc.

[0104] The embodiment of the present application can flexibly handle test scenarios that require two-way communication by intelligently judging the callback settings in the configuration information. Once the existence of callback information is detected, the key callback address, callback data, and callback interval time can be automatically parsed without manual intervention, reducing the possibility of configuration errors. Creating a scheduled task based on the parsed interval time ensures the accurate sending of callback requests and simulates the asynchronous interaction process in a real business scenario. When the scheduled task is triggered, it can automatically initiate a request through the specified callback address and carry the preset callback data. This mechanism greatly facilitates the verification of the system's asynchronous response processing logic by testers.

[0105] In some optional implementation manners of this embodiment, in step S202, after the step of obtaining the configuration information from the system cache according to the identifier in the test request, the following steps are further included:

[0106] If a traffic limiting parameter is set in the configuration information, obtain the queries per second rate of the current request; determine whether the queries per second rate reaches a preset traffic limiting threshold; if the queries per second rate reaches the traffic limiting threshold, process the test request according to a preset exception handling strategy;

[0107] Step S202, the step of matching the test request type in the test request with the request type indicated by the request type data, may specifically include the following steps:

[0108] If the queries per second rate does not reach the throttling threshold, match the test request type in the test request with the request type indicated by the request type data.

[0109] Among them, the throttling parameter refers to the threshold parameter in the configuration information of the baffle service for controlling the queries per second (QPS). By setting the throttling parameter, the baffle service can limit the processing speed of test requests to prevent system crashes or performance degradation caused by excessive requests.

[0110] Among them, the exception handling strategy refers to a set of rules or methods preset in the baffle service for handling exception situations that occur during the processing of test requests.

[0111] In one example, a throttling parameter is set in the configuration information. This throttling parameter is used to control the access frequency to the baffle service to prevent service instability or resource exhaustion caused by excessive requests. During system operation, the baffle service will obtain the current request's QPS in real time and compare it with the preset throttling threshold. For example, if the preset throttling threshold is 100 QPS, when the actual QPS reaches or exceeds this value, the baffle service will activate the preset exception handling strategy, such as returning an error code, delaying the response, or simulating service overload, etc., to simulate the throttling scenario in a real environment. If the QPS does not reach the threshold, the baffle service will continue to process the test request, match the test request type (such as GET, POST, etc.) in the test request with the request type pre-stored in the request type data to determine what simulated response to return.

[0112] When the embodiment of the present application clearly sets a throttling parameter in the configuration information, it can capture and calculate the queries per second rate of the current request in real time. This dynamic monitoring ability ensures the stability and security of the service. By accurately judging whether the queries per second rate reaches the preset throttling threshold, it can automatically adopt the preset exception handling strategy during peak traffic periods, such as delaying the response or simulating an abnormal return, effectively avoiding service crashes caused by request overload, and improving the reliability and authenticity of the test. At the same time, if the throttling threshold is not reached, fine-grained matching is performed based on the request type data to ensure that the simulated response can accurately meet different types of test requirements, significantly improving the work efficiency of developers and testers.

[0113] It should be emphasized that, to further ensure the privacy and security of the request type data, parameter processing data, and response result configuration information of the above configuration information, the request type data, parameter processing data, and response result configuration information of the above configuration information can also be stored in a node of a blockchain.

[0114] The blockchain referred to in this application is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain, in essence, is a decentralized database, a string of data blocks generated by using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. The blockchain can include the blockchain underlying platform, the platform product service layer, and the application service layer, etc.

[0115] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above various methods. Among them, the aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a Read-Only Memory (ROM), etc., or a Random Access Memory (RAM), etc.

[0116] It should be understood that although the steps in the flowchart of the accompanying drawings are shown in sequence according to the arrows, these steps do not necessarily have to be executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings can include multiple sub-steps or multiple stages. These sub-steps or stages do not necessarily have to be executed at the same moment, but can be executed at different moments. Their execution order does not necessarily have to be sequential, but can be executed alternately or in turn with at least a part of other steps or sub-steps or stages of other steps.

[0117] Further referring to Figure 3 As an implementation of the method shown above Figure 2 This application provides an embodiment of a request response device. This device embodiment corresponds to the method embodiment shown in Figure 2 This device can be specifically applied to various electronic devices.

[0118] Such as Figure 3As shown in the figure, the request response device 400 of this embodiment includes: a receiving module 401, a first obtaining module 402, a first matching module 403, a first processing module 404, and a generating module 405. Among them:

[0119] The receiving module 401 is configured to receive a test request;

[0120] The first obtaining module 402 is configured to obtain configuration information from the system cache according to the identifier in the test request, where the configuration information includes request type data, parameter processing data, and response result configuration information;

[0121] The first matching module 403 is configured to match the test request type in the test request with the request type indicated by the request type data;

[0122] The first processing module 404 is configured to, if there is a match between the test request type and the request type, process the parameter information in the test request according to the parameter processing data to obtain complete request parameters;

[0123] The generating module 405 is configured to generate response data corresponding to the test request based on the request parameters and the response result configuration information.

[0124] In an embodiment of the present application, through an innovative baffle service design, the system development and testing processes can be significantly optimized. Specifically, it can receive test requests and quickly retrieve corresponding configuration information from the system cache according to the identifiers in the test requests. This configuration information not only covers request types and parameter processing rules but also clarifies the format requirements of response data, thereby achieving accurate simulation of the response results of HTTP(S) interfaces. After matching the test request type in the test request with the request type indicated by the request type data, it can intelligently improve the parameter information according to the parameter processing data to ensure the authenticity and effectiveness of the test environment. In this process, there is no need for cumbersome registration or additional code writing, which greatly reduces the usage threshold and improves the testing efficiency. It can dynamically generate response data corresponding to the test request based on the request parameters and the response result configuration information. This function not only supports the simulation of complex business scenarios but also allows developers and testers to flexibly set the response content according to actual needs, thereby comprehensively verifying the correctness and stability of the system processing logic.

[0125] In one embodiment, the first processing module 404 includes:

[0126] The parsing sub-module is configured to parse the parameter processing data to obtain a parameter parsing result and extract parameter information from the test request;

[0127] The comparison sub-module is configured to compare the parameter parsing result with the parameter information to determine whether the parameter information is complete;

[0128] A supplementary sub-module, configured to, if the parameter information is incomplete, supplement the missing parameters in the parameter information according to the parameter parsing result to obtain complete request parameters.

[0129] In an embodiment of the present application, by parsing and processing the parameter processing data, extracting parameter information from the test request, and comparing the parameter information with the preset parameter parsing result, the integrity of the parameter information can be quickly determined. When it is found that the parameter information is missing, the missing parameters can be intelligently supplemented according to the parameter parsing result to ensure the comprehensiveness and accuracy of the request parameters. During this process, no manual intervention is required, which reduces the workload of testers and improves the test efficiency. At the same time, since the missing parameters can be automatically completed, the test failure caused by incomplete parameters is avoided, further improving the accuracy and reliability of the test.

[0130] In an embodiment, the generation module 405 includes:

[0131] An identification sub-module, configured to identify the processing mode indicated by the response result configuration information;

[0132] A first acquisition sub-module, configured to, if the processing mode indicated by the response result configuration information is the template return mode, acquire preset first template data based on the request parameters and use the first template data as the response data corresponding to the test request;

[0133] A second acquisition sub-module, configured to, if the processing mode indicated by the response result configuration information is the template matching mode, acquire preset request field values based on the request parameters, match the request field values with the field values of the preset template data to obtain the matched second template data, and use the second template data as the response data;

[0134] A third acquisition sub-module, configured to, if the processing mode indicated by the response result configuration information is the script processing mode, acquire a preset logic processing script based on the request parameters, input the request parameters into the logic processing script for processing to obtain the result data after logic processing, and use the result data as the response data.

[0135] In an embodiment of the present application, by providing three processing modes of template return, template matching, and script processing, the flexible simulation of the response data of the HTTP(S) interface is realized. It not only reduces the development and test costs, but also improves the test efficiency and accuracy, providing strong support for system development and test work.

[0136] In an embodiment, the request response device 400 further includes:

[0137] A first judgment module, configured to judge whether an identifier exists in the test request;

[0138] An encapsulation module, which is used to generate an exception message if the test request does not have an identifier, encapsulate the exception message into a preset format to obtain the encapsulated exception message;

[0139] A first return module, which is used to return the encapsulated exception message to the sender of the test request.

[0140] In the embodiment of the present application, by judging whether the test request has an identifier, it can effectively identify and process those invalid requests caused by the lack of identifiers, avoiding the waste of test resources due to incorrect request formats. When a request without an identifier is detected, an exception message is generated and encapsulated into a unified format and then returned. This not only ensures the standardization and readability of the exception message, but also helps testers quickly locate the problem, reducing the time cost of troubleshooting errors.

[0141] In one embodiment, the request response device 400 further includes:

[0142] A second judgment module, which is used to judge whether the response time is set in the configuration information;

[0143] A calculation module, which is used to obtain the start time and the current time of the test request and calculate the time difference between the start time and the current time if the response time is set;

[0144] A second return module, which is used to wait for the remaining time through thread sleep until the response time is reached and return the response data to the sender of the test request if the time difference is less than the response time.

[0145] In the embodiment of the present application, when simulating the HTTP(S) interface response, the baffle service of the present application can be intelligently and precisely controlled according to the response time setting in the configuration information. When a test request arrives, it first judges whether the response time is specified in the configuration. If it is set, the time difference between the current time and the request start time is determined through accurate time calculation. If the time difference is less than the set response time, the thread sleep mechanism will be intelligently started to wait until the preset response time and then return the response data. This mechanism ensures that the test request can simulate the delayed response in the real scenario, providing a more realistic test environment for developers and testers. At the same time, this solution does not require complex programming or additional configuration, reducing the usage threshold and improving the test efficiency.

[0146] In one embodiment, the request response device 400 further includes:

[0147] A third judgment module, which is used to judge whether the callback information is set in the configuration information;

[0148] A second acquisition module, which is used to obtain the callback address, callback data, and callback interval time from the callback information if the callback information is set;

[0149] A creation module, configured to create a scheduled task based on a callback interval time;

[0150] An incoming module, configured to initiate a callback request through a callback address and pass callback data into the callback request when the scheduled task is triggered.

[0151] Embodiments of the present application can flexibly handle test scenarios that require two-way communication by intelligently judging the callback settings in the configuration information. Once the existence of callback information is detected, the key callback address, callback data, and callback interval time can be automatically parsed without manual intervention, reducing the possibility of configuration errors. Creating a scheduled task based on the parsed interval time ensures the accurate sending of callback requests and simulates the asynchronous interaction process in a real business scenario. When the scheduled task is triggered, a request can be automatically initiated through the specified callback address and carry the preset callback data, which greatly facilitates the verification by testers of the system's asynchronous response logic processing.

[0152] In one embodiment, the request response device 400 further includes:

[0153] A third acquisition module, configured to acquire the queries per second rate of the current request if a flow limiting parameter is set in the configuration information;

[0154] A fourth judgment module, configured to judge whether the queries per second rate reaches a preset flow limiting threshold;

[0155] A second processing module, configured to process the test request according to a preset exception handling strategy if the queries per second rate reaches the flow limiting threshold;

[0156] A second matching module, configured to match the test request type in the test request with the request type indicated by the request type data if the queries per second rate does not reach the flow limiting threshold.

[0157] When a flow limiting parameter is clearly set in the configuration information in embodiments of the present application, the queries per second rate of the current request can be captured and calculated in real time. This dynamic monitoring ability ensures the stability and security of the service. By accurately judging whether the queries per second rate reaches the preset flow limiting threshold, a preset exception handling strategy can be automatically adopted during peak traffic periods, such as delaying the response or simulating an abnormal return, effectively avoiding service crashes caused by request overload and improving the reliability and authenticity of the test. At the same time, if the flow limiting threshold is not reached, fine matching is performed based on the request type data to ensure that the simulated response can accurately meet different types of test requirements, significantly improving the work efficiency of developers and testers.

[0158] To solve the above technical problems, embodiments of the present application also provide a computer device. For details, please refer to Figure 4 ,Figure 4 This is the basic structural block diagram of the computer device in this embodiment.

[0159] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are communicatively connected to each other via a system bus. It should be noted that only the computer device 6 with the memory 61, the processor 62, and the network interface 63 is shown in the figure. However, it should be understood that it is not required to implement all the shown components, and more or fewer components can be alternatively implemented. Among them, those skilled in the art of this technology can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0160] The computer device can be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The computer device can perform human-computer interaction with the user through a keyboard, a mouse, a remote control, a touchpad, or a voice control device, etc.

[0161] The memory 61 includes at least one type of readable storage medium. The readable storage medium includes flash memory, hard disks, multimedia cards, card-type memories (such as SD or DX memories, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memories, magnetic disks, optical disks, etc. In some embodiments, the memory 61 can be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 can also be an external storage device of the computer device 6, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 6. Of course, the memory 61 can also include both the internal storage unit and the external storage device of the computer device 6. In this embodiment, the memory 61 is generally used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions of the request response method. In addition, the memory 61 can also be used to temporarily store various data that have been output or will be output.

[0162] The processor 62 may be a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips in some embodiments. The processor 62 is generally used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to run the computer-readable instructions stored in the memory 61 or process data, such as running the computer-readable instructions of the request response method.

[0163] The network interface 63 may include a wireless network interface or a wired network interface, and this network interface 63 is generally used to establish a communication connection between the computer device 6 and other electronic devices.

[0164] The embodiment of the present application can significantly optimize the system development and testing processes through an innovative baffle service design. Specifically, it can receive a test request and quickly retrieve the corresponding configuration information from the system cache according to the identifier in the test request. This configuration information not only covers the request type, parameter processing rules, but also specifies the format requirements of the response data, thus achieving an accurate simulation of the HTTP(S) interface response result. After matching the test request type in the test request with the request class indicated by the request type data, it can intelligently improve the parameter information according to the parameter processing data to ensure the authenticity and effectiveness of the test environment. In this process, there is no need for cumbersome registration or additional code writing, greatly reducing the usage threshold and improving the test efficiency. It can dynamically generate the response data corresponding to the test request based on the request parameters and response result configuration information. This function not only supports the simulation of complex business scenarios, but also allows developers and testers to flexibly set the response content according to actual needs, thereby comprehensively verifying the correctness and stability of the system processing logic.

[0165] The present application also provides another implementation manner, that is, to provide a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor, so that at least one processor executes the steps of the request response method as described above.

[0166] Embodiments of the present application can significantly optimize the system development and testing processes through innovative baffle service designs. Specifically, it can receive test requests and quickly retrieve corresponding configuration information from the system cache based on the identifiers in the test requests. This configuration information not only covers the request type, parameter processing rules, but also specifies the format requirements of the response data, thereby achieving accurate simulation of the HTTP(S) interface response results. After matching the test request type in the test request with the request class indicated by the request type data, it can intelligently improve the parameter information according to the parameter processing data to ensure the authenticity and effectiveness of the test environment. In this process, there is no need for cumbersome registration or additional code writing, greatly reducing the usage threshold and improving the testing efficiency. It can dynamically generate the response data corresponding to the test request based on the request parameters and response result configuration information. This function not only supports the simulation of complex business scenarios, but also allows developers and testers to flexibly set the response content according to actual needs, thereby comprehensively verifying the correctness and stability of the system processing logic.

[0167] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc) and includes several instructions to enable a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present application.

[0168] Obviously, the above-described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The accompanying drawings show the preferred embodiments of the present application, but do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosed content of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the foregoing embodiments, for those skilled in the art, they can still modify the technical solutions recorded in the foregoing specific embodiments, or perform equivalent replacements for some of the technical features. Any equivalent structures directly or indirectly using the content of the specification and drawings of the present application in other related technical fields are equally within the scope of the patent protection of the present application.

Claims

1. A request response method, characterized in that: The steps include: Receive test requests; According to the identifier in the test request, obtain configuration information from the system cache, the configuration information including request type data, parameter processing data and response result configuration information; Matching a test request type in the test request with a request type indicated by the request type data; If there is a match between the test request type and the request type, the parameter information in the test request is processed according to the parameter processing data to obtain complete request parameters; Based on the request parameters and the response result configuration information, response data corresponding to the test request is generated.

2. The method according to claim 1, characterized in that The step of processing the parameter information in the test request according to the parameter processing data to obtain complete request parameters specifically includes: Parsing the parameter processing data to obtain parameter parsing results, and extracting parameter information from the test request; Compare the parameter analysis result with the parameter information to determine whether the parameter information is complete; If the parameter information is incomplete, the missing parameters in the parameter information are supplemented according to the parameter parsing result to obtain complete request parameters.

3. The method according to claim 1, characterized in that The step of generating response data corresponding to the test request based on the request parameters and the response result configuration information specifically includes: Identify the processing mode indicated by the response result configuration information; If the processing mode indicated by the response result configuration information is a template return mode, obtaining preset first template data based on the request parameters, and using the first template data as response data corresponding to the test request; If the processing mode indicated by the response result configuration information is the template matching mode, obtaining a preset request field value based on the request parameter, matching the request field value with a field value of preset template data to obtain matching second template data, and using the second template data as the response data; If the processing mode indicated by the response result configuration information is the script processing mode, a preset logic processing script is obtained based on the request parameters, and the request parameters are input into the logic processing script for processing to obtain result data after logic processing, and the result data is used as the response data.

4. The method according to claim 1, characterized in that: Before the step of acquiring configuration information from the system cache according to the identifier in the test request, the method further includes: Determine whether the test request has an identifier; If the test request does not have an identifier, generating exception information, encapsulating the exception information into a preset format, and obtaining encapsulated exception information; The encapsulated exception information is returned to the sender of the test request.

5. The method according to claim 1, characterized in that After the step of generating response data corresponding to the test request based on the request parameters and the response result configuration information, the step further includes: Determining whether a response time is set in the configuration information; If the response time is set, the start time and current time of the test request are obtained, and the time difference between the start time and the current time is calculated; If the time difference is less than the response time, the thread is hibernated to wait for the remaining time until the response time is reached, and the response data is returned to the sender of the test request.

6. The method according to claim 1, characterized in that After the step of generating response data corresponding to the test request based on the request parameters and the response result configuration information, the step further includes: Determine whether callback information is set in the configuration information; If the callback information is set, the callback address, callback data and callback interval are obtained from the callback information; Based on the callback interval, create a scheduled task; When the scheduled task is triggered, a callback request is initiated through the callback address, and the callback data is passed into the callback request.

7. The method according to claim 1, characterized in that After the step of acquiring configuration information from the system cache according to the identifier in the test request, the method further includes: If the current limiting parameter is set in the configuration information, the query rate per second of the current request is obtained; Determine whether the query rate per second reaches a preset current limiting threshold; If the query rate per second reaches the current limiting threshold, the test request is processed according to a preset exception handling strategy; The step of matching the test request type in the test request with the request type indicated by the request type data specifically includes: If the query rate per second does not reach the current limiting threshold, the test request type in the test request is matched with the request type indicated by the request type data.

8. A request response device, characterized in that: include: A receiving module, used for receiving a test request; A first acquisition module, configured to acquire configuration information from a system cache according to an identifier in the test request, wherein the configuration information includes request type data, parameter processing data, and response result configuration information; A first matching module, configured to match a test request type in the test request with a request type indicated by the request type data; A first processing module, configured to process parameter information in the test request according to the parameter processing data to obtain complete request parameters if the test request type matches the request type; A generation module is used to generate response data corresponding to the test request based on the request parameters and the response result configuration information.

9. A computer device, characterized in that: It comprises a memory and a processor, wherein the memory stores computer-readable instructions, and when the processor executes the computer-readable instructions, the steps of the request response method as claimed in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the steps of the request response method according to any one of claims 1 to 7 are implemented.

Images