Baffle generation method, device, equipment and computer storage medium
By automatically configuring the request and return parameters in the interface documentation through the rules engine, mock code is generated, which solves the problems of missing and incomplete coverage of baffle rules in the existing technology, and improves the accuracy and efficiency of mock test results.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- WEBANK (CHINA)
- Filing Date
- 2019-09-05
- Publication Date
- 2026-05-29
AI Technical Summary
In existing mock tests, the input of the baffle rules is prone to missing some scenario rules, resulting in incomplete scenario coverage of the request results and insufficient accuracy of the test results.
The rule engine automatically configures rules for request and return parameters in the API documentation, generates target mock code and simulated mock code, and determines the target mock server shield, avoiding manual input and improving the efficiency and completeness of rule maintenance.
It improves the accuracy of mock test results, avoids the time-consuming and laborious process and the problem of missing scenario rules caused by manual data entry, and improves testing efficiency.
Smart Images
Figure CN110569159B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of testing technology for financial technology (Fintech), and more particularly to a method, apparatus, device, and computer storage medium for generating baffles. Background Technology
[0002] With the development of computer technology, more and more technologies (big data, distributed systems, blockchain, artificial intelligence, etc.) are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology (Fintech). However, due to the security and real-time requirements of the financial industry, higher demands are also being placed on technology.
[0003] In the current fintech testing field, mock servers are frequently used to test system interfaces. For example, when a client of the product being tested initiates a transaction, and the system under test needs to simulate calling a downstream service's synchronous interface to return a specified result, a shield rule can be entered into the mock server platform. When the intercepted interface request parameter value matches the request parameter value entered in the shield rule, the specified request result is returned. However, this method has certain drawbacks. The input of shield rules can easily miss some scenario rules; the request result coverage of scenarios is incomplete; and the downstream return result is uncontrollable, thus affecting the accuracy of the mock test results. Therefore, how to improve the accuracy of mock test results has become an urgent technical problem to be solved. Summary of the Invention
[0004] The main objective of this invention is to provide a baffle generation method, apparatus, device, and computer storage medium, which aims to improve the accuracy of mock test results.
[0005] To achieve the above objectives, the present invention provides a baffle generation method, the baffle generation method comprising the following steps:
[0006] Obtain the standard interface document of the terminal, and configure rules for the request parameters and return parameters in the standard interface document through the rule engine;
[0007] The rule engine parses the request parameters that have been configured with rules to obtain the target mock code corresponding to the request parameters, and the rule engine also parses the return parameters that have been configured with rules to obtain the simulated mock code corresponding to the return parameters.
[0008] The target mock server baffle is determined based on the target mock code and the simulated mock code.
[0009] Optionally, the step of configuring rules for the request parameters and return parameters in the standard interface document using a rule engine includes:
[0010] The request matching rule corresponding to the request parameter is determined by the rule engine, and the request parameter is configured according to the request matching rule;
[0011] A preset number of error codes are obtained through a rules engine, and the return parameters are configured with rules based on each error code.
[0012] Optionally, the step of determining the request matching rule corresponding to the request parameter through the rule engine includes:
[0013] The rule engine obtains multiple input test data and matches each test data with the request parameters in sequence.
[0014] If there is target test data in each of the test data that matches the request parameters, then the matching rule corresponding to the target test data shall be used as the request matching rule.
[0015] Optionally, after the step of using the matching rule corresponding to the target test data as the request matching rule if target test data matching the request parameters exists in each of the test data, the following steps are included:
[0016] Obtain the return result corresponding to the request parameters and multiple error codes in the error code library corresponding to the rule engine, and match the result return code corresponding to the return result with each of the error codes in sequence;
[0017] If no error code matches the result return code among the error codes, then the result return code is stored in the error code library.
[0018] Optionally, the step of obtaining the return result corresponding to the request parameter includes:
[0019] Obtain the status code returned by the request parameter, construct the return content based on the status code value, and use the return content as the return result corresponding to the request parameter.
[0020] Optionally, the step of obtaining a preset number of error codes through a rule engine and configuring rules for the returned parameters based on each error code includes:
[0021] The rule engine retrieves a preset number of error codes from an error code library containing the returned result codes, and then matches the error codes with the expected results in the request parameters in sequence.
[0022] If a target error code exists among the error codes that matches the expected result in the request parameters, then the matching rule corresponding to the target error code is used as the return matching rule corresponding to the return parameter, and the return parameter is configured with rules based on the return matching rule.
[0023] Optionally, the step of determining the target mock server shield based on the target mock code and the simulated mock code includes:
[0024] Determine the mock server shield based on the target mock code and the simulated mock code;
[0025] Obtain the target test data corresponding to the target mock code from the request parameters, and enter each target test data into the mock server panel, and use the mock server panel with each target test data as the target simulation server mock server panel.
[0026] Furthermore, to achieve the above objectives, the present invention also provides a baffle generating apparatus, the baffle generating apparatus comprising:
[0027] The acquisition module is used to acquire the input standard interface document and configure rules for the request parameters and return parameters in the standard interface document through the rule engine.
[0028] The parsing module is used to parse the request parameters that have been configured with rules through the rule engine to obtain the target mock code corresponding to the request parameters, and to parse the return parameters that have been configured with rules through the rule engine to obtain the simulated mock code corresponding to the return parameters;
[0029] The determination module is used to determine the target mockserver baffle based on the target mock code and the simulated mock code.
[0030] In addition, to achieve the above objectives, the present invention also provides a baffle generation device, the baffle generation device comprising: a memory, a processor, and a baffle generation program stored in the memory and executable on the processor, wherein the baffle generation program, when executed by the processor, implements the steps of the baffle generation method as described above.
[0031] In addition, to achieve the above objectives, the present invention also provides a computer storage medium storing a baffle generation program, which, when executed by a processor, implements the steps of the baffle generation method as described above.
[0032] This invention obtains the standard interface document of the terminal and configures rules for the request and return parameters in the standard interface document using a rule engine. The rule engine then parses the configured request parameters to obtain the target mock code corresponding to each parameter, and similarly parses the configured return parameters to obtain the corresponding simulated mock code. Based on the target and simulated mock codes, a target mock server is determined. By automatically configuring rules for the request and return parameters in the interface document using the rule engine, manual input is eliminated, improving the efficiency and completeness of the mock server rules. This avoids the time-consuming, labor-intensive, and inefficient nature of existing technologies that rely on manual input of mock server rules, which can easily lead to the omission of some scenario rules. Therefore, this invention improves the accuracy of mock test results. Attached Figure Description
[0033] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of the present invention;
[0034] Figure 2 This is a flowchart illustrating the first embodiment of the baffle generation method of the present invention;
[0035] Figure 3 This is a schematic diagram of the device modules of the baffle generating apparatus of the present invention;
[0036] Figure 4 This is a schematic diagram of the mock test process in the baffle generation method of the present invention;
[0037] Figure 5 This is a schematic diagram of the process of obtaining the mock server baffle in the baffle generation method of the present invention.
[0038] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0039] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
[0040] like Figure 1 As shown, Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of the present invention.
[0041] The baffle generation device in this embodiment of the invention can be a PC or a server device, on which a Java Virtual Machine runs.
[0042] like Figure 1As shown, the baffle generating device may include: a processor 1001, such as a CPU; a network interface 1004; a user interface 1003; a memory 1005; and a communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.
[0043] Those skilled in the art will understand that Figure 1 The device structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0044] like Figure 1 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a baffle generation program.
[0045] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the client (user terminal) and communicate with the client; and the processor 1001 can be used to call the baffle generation program stored in the memory 1005 and execute the operations in the baffle generation method described below.
[0046] Based on the above hardware structure, an embodiment of the baffle generation method of the present invention is proposed.
[0047] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the baffle generation method of the present invention, the method comprising:
[0048] Step S10: Obtain the standard interface document of the terminal, and configure rules for the request parameters and return parameters in the standard interface document through the rule engine;
[0049] Currently, interface documentation used in terminal applications is basically archived in two ways: 1. Editing and saving using Excel and then transferring it between different versions; 2. Saving and maintaining it on a ShowDoc (online documentation) service. Regardless of the method used, the interface documentation includes the API service's Q (Request), request parameters, and return parameters. The result status field values of the return parameters are typically enumerated for use by the calling system. This standard interface documentation (i.e., standard interface documentation) provides the raw data for rule matching for the mock server's (simulated server) code.
[0050] Currently, when conducting mock testing, such as Figure 4 As shown, when simulating client testing of the system under test, a mock server is relied upon for simulation testing. This involves manually entering shield rules on the mock server platform. The system intercepts request parameter values from calls to downstream service interfaces to simulate returning specified response results. When the intercepted request parameter values match those entered in the rules, the shield is triggered, and the specified result is simulated and returned to the system under test. However, this testing method suffers from incomplete coverage of request result scenarios and uncontrollable downstream return results. Downstream services may be provided by different departments or even partners, and changes to service interface versions incur communication costs. Failure to update mock server rules in a timely manner can affect the accuracy of test results. The incomplete scenario coverage and uncontrollable downstream return results stem from two main reasons: 1. Interface documentation may be updated, while the documentation used to generate the shield remains the same. If the latest interface documentation includes new error codes, the scenario coverage will be incomplete; 2. If the shield is only generated based on the interface documentation for verification, abnormal returns may be ignored, leading to incomplete coverage. Therefore, in this embodiment, the standard interface document to be tested is first obtained from the terminal, and then the request parameters and return parameters in the standard interface document are configured with rules through the rule engine in the mock server platform. That is, in this embodiment, the matching rules for the corresponding swatch are generated based on the request parameters, and when generating the matching rules for the corresponding swatch based on the request parameters, the corresponding association rules can be modified as needed, such as changing "or" to "and".
[0051] Step S20: The request parameters with configured rules are parsed by the rule engine to obtain the target mock code corresponding to the request parameters; and the return parameters with configured rules are parsed by the rule engine to obtain the simulated mock code corresponding to the return parameters.
[0052] The rule engine primarily includes normal rules and exception error code rules, allowing for the configuration of corresponding rules for request and return parameters in standard API documentation. The main logic of the rule engine is to combine API documentation data, parse the rule configuration for the corresponding request parameters, and generate mock codes (i.e., target mock codes) for the parameters that need to be hit during the request invocation. It also parses the rule configuration for the corresponding return parameter status codes, generating mock code data (i.e., simulated mock codes) that mimic the request's return content.
[0053] In normal circumstances, the caller sends a message consisting of request parameters to the downstream system, which then parses the message and returns the corresponding result. However, with a mock server, when the rule engine receives test data (i.e., request parameters) entered by the tester, it calls the corresponding interface to identify each request parameter. If one or more parameter values match the pre-entered mock server parameter values, the mock server is considered matched, and the corresponding result is returned to the caller. The returned result is constructed based on the status code of the request. Typical status values are success, failure, and processing. The rule engine constructs the returned content according to these three statuses. In cases where there are exception error code rules, the rule engine retrieves all returned error codes from the exception error code database for full-case regression testing, or randomly selects a portion of the status codes for quick verification according to a configured ratio. For example, it might randomly select three error codes, generate three matching rules based on these three selected error codes, and configure the returned parameters according to these three matching rules. The request parameter matching rules remain consistent with normal rules. That is, when no exception error code rules exist, the rule engine only configures rules for the request parameters, parses the rule configuration for the request parameters, and outputs the parsing result through the return parameters. However, when exception error code rules exist, the engine will configure rules for the return parameters based on the error code while keeping the request parameter rule configuration unchanged, and output the corresponding return result.
[0054] Step S30: Determine the target mock server (mockserver) based on the target mock code and the simulated mock code.
[0055] A mock server is a testing mechanism that separates the interface from the data, using interface documentation for testing and simulating behavior through conditional and result data. Once the target mock code and the mock code being simulated are obtained, the mock code can be placed after the target mock code. In other words, the mock code generated by exception error code rules is placed after the mock code generated by normal rules. The mock server only becomes effective, i.e., the target mock server is obtained, after receiving the test data corresponding to the request parameters input by the tester.
[0056] In addition, to help understand the mock testing of the standard interface documentation in this embodiment, examples are provided below.
[0057] For example, such as Figure 5 As shown, after the rule engine in the mock server platform receives the standard interface document, it will configure the request parameters and return parameters in the standard interface document according to two methods: normal rules and exception error code rules. In the normal rules, the matching rules of the corresponding shield are generated according to the request parameters, and the rule configuration of the corresponding request parameters is parsed to determine whether there are any request parameters that match the pre-entered shield parameters. If they do, it means that the shield is hit, and the corresponding return content can be constructed according to the status code value returned by the request and the return content is output. In the exception error rules, the rule configuration for request parameters remains consistent with that in normal rules. However, when configuring rules for return parameters, error codes are randomly selected from the exception error code library (1% to 100%). These randomly selected error codes are then quickly validated to generate corresponding matching rules for the return parameters. The rules for the return parameters are then configured, and the rule configuration for the return parameter status codes is parsed to obtain the return content. The shield code generated by the exception error code rules is placed after the shield code generated by the normal rules. Test data corresponding to the request parameters that the testers want to match the rules is then received to activate the mock server, thus obtaining an effective mock server shield and improving the efficiency of mock testing.
[0058] In this embodiment, a standard interface document of the terminal is obtained, and a rule engine is used to configure rules for the request parameters and return parameters in the standard interface document. The rule engine parses the configured request parameters to obtain the target mock code corresponding to the request parameters, and the rule engine also parses the configured return parameters to obtain the simulated mock code corresponding to the return parameters. Based on the target mock code and the simulated mock code, a target mock server is determined. The rule engine automatically configures rules for the request and return parameters in the interface document, eliminating the need for manual input. This improves the maintenance efficiency and completeness of the mock server rules, avoiding the time-consuming, labor-intensive, and inefficient nature of existing technologies that rely on manual input of mock server rules, which can easily lead to the omission of some scenario rules. This improves the accuracy of the mock test results.
[0059] Furthermore, based on the first embodiment of the baffle generation method of the present invention, a second embodiment of the baffle generation method of the present invention is proposed. This embodiment is a refinement of step S10 of the first embodiment of the present invention, which involves configuring rules for the request parameters and return parameters in the standard interface document through a rule engine, including:
[0060] Step a: Determine the request matching rule corresponding to the request parameter through the rule engine, and configure the rule for the request parameter according to the request matching rule;
[0061] After receiving the standard interface document, the rule engine generates corresponding request matching rules based on the request parameters in the standard interface document. In other words, when testers input various test data, the downstream system calls the corresponding interface to identify one or more request parameter values that match the entered shield parameter values. If the shield is matched, the system returns the result to the caller according to the shield. The judgment condition corresponding to the shield parameter value can be represented as a request matching rule, and then this request matching rule is used to configure the request parameters.
[0062] Step b: Obtain a preset number of error codes through the rule engine, and configure the rules for the returned parameters based on each error code.
[0063] The rule engine obtains a preset number of error codes from the error code library corresponding to the rule engine based on a random selection ratio, and verifies these error codes in order to obtain the return parameter rules corresponding to the return parameters, and configures the return parameters according to the return parameter rules.
[0064] In this embodiment, the request matching rules corresponding to the request parameters are determined by the rule engine, and the request parameters are configured according to the request matching rules. Then, the return parameters are configured according to the error codes. This realizes that the request parameters and return parameters are automatically configured by the rule engine without manual settings, which improves the maintenance efficiency of the mock server.
[0065] Specifically, the step of determining the request matching rule corresponding to the request parameter through the rule engine includes:
[0066] Step a1: Obtain multiple input test data through the rule engine, and match each test data with the request parameters in sequence;
[0067] The rule engine obtains the input test data (the test data consists of the parameters to be tested entered by the testers), and after obtaining each test data, it matches each test data with the request parameters in turn to determine whether there is a match between the test data and the data in the request parameters, and performs different operations based on the determination results.
[0068] Step a2: If there is target test data in each of the test data that matches the request parameters, then the matching rule corresponding to the target test data is used as the request matching rule.
[0069] If, after evaluation, target test data matching the request parameters is found in various test data, then the matching rule for matching the target test data in the request parameters is used as the request matching rule.
[0070] In this embodiment, by obtaining multiple test data from the rule engine, and determining that there is target test data in each test data that matches the request parameters, the matching rule corresponding to the target test data is used as the request matching rule, thereby ensuring the accuracy of the request matching rule corresponding to the obtained request parameters.
[0071] Specifically, if there is target test data in each of the test data that matches the request parameters, then after the step of using the matching rule corresponding to the target test data as the request matching rule, the following steps are included:
[0072] Step a3: Obtain the return result corresponding to the request parameter and multiple error codes in the error code library corresponding to the rule engine, and match the result return code corresponding to the return result with each of the error codes in sequence;
[0073] The error code database is a centralized database storing abnormal error codes returned by different projects and products in different transaction scenarios. The data sources for the error code database mainly include two aspects: first, the rule engine automatically maintains the result return codes of the return parameters enumerated by the standard interface documentation into the error code database (i.e., if the result return code does not exist in the error code database, it is maintained in the error code database); second, typical error code scenarios are manually maintained into the error code database. In addition, the rule engine randomly selects different return result error codes from the error code database. This can be selected from different scenario return codes within the same project or from return codes across products, to generate corresponding mock server blocks. These mock servers are used to determine whether the caller can properly handle various uncontrollable error code returns from downstream systems. When the judgment finds that target test data exists in various test data that matches the preset block parameters, the return result corresponding to that target test data in the block parameters is obtained. The rule engine retrieves multiple error codes from the error code database and obtains the result return codes corresponding to the return results. These result return codes are then matched sequentially with each error code, and different operations are performed based on the matching results.
[0074] Step a4: If there is no error code that matches the result return code among the error codes, then the result return code is stored in the error code library.
[0075] If, after evaluation, no matching error code is found among the error codes, the resulting error code will be added to the error code database so that the rule engine can retrieve the appropriate error code from the database. If a matching error code is found among the error codes, the returned content will be output directly through the return parameters.
[0076] In this embodiment, the return code of the result corresponding to the request parameter is matched with various error codes. If no error code matches the return code, the return code is maintained in the error code database. This ensures the comprehensiveness of abnormal result return scenarios and provides a foundation for subsequent rule configuration of return parameters.
[0077] Specifically, the step of obtaining the return result corresponding to the request parameters includes:
[0078] Step c1: Obtain the status code returned by the request parameter, construct the return content based on the status value of the status code, and use the return content as the return result corresponding to the request parameter.
[0079] A status code is a 3-digit numeric code used to represent the response status of a web server's Hypertext Transfer Protocol (HTTP). The status value refers to the different states the status code has gone through. The system retrieves the status code returned from the request parameters and constructs the return content based on the status code's status value. That is, each status value corresponds to a set of return content. Typically, there are three status values: success, failure, and processing. The rule engine constructs three sets of return content based on these three states and uses these return contents as the return results corresponding to the request parameters. In other words, when the status value is success, it constructs a return message indicating that the request parameters have successfully matched the test data and uses this as the return content, i.e., the return result.
[0080] In this embodiment, the accuracy of the returned results is ensured by constructing the returned content based on the status values of each status code and using the returned content as the returned result corresponding to the request parameters.
[0081] Specifically, the steps of obtaining a preset number of error codes through a rule engine and configuring rules for the returned parameters based on each error code include:
[0082] Step d1: Obtain a preset number of error codes from the error code library containing the result return codes using the rule engine, and match the error codes with the expected results in the request parameters in sequence;
[0083] The rules engine retrieves a preset number of error codes from an error code database with result return codes at a random ratio, and then matches these error codes with the expected results in the request parameters. Different operations are performed based on different matching results. The expected results can be pre-set by the tester and correspond to the error codes.
[0084] Step d2: If there is a target error code among the error codes that matches the expected result in the request parameters, then the matching rule corresponding to the target error code is used as the return matching rule corresponding to the return parameter, and the return parameter is configured with rules based on the return matching rule.
[0085] If, after evaluation, a target error code matching the expected result is found among the various error codes, the matching rule corresponding to the target error code and the expected result can be used as the return matching rule for the return parameter, and the rule engine can configure the return parameter according to the return matching rule.
[0086] In this embodiment, a preset number of error codes are obtained from the error code library through a rule engine, and each error code is matched with the expected result. If a target error code matches the expected result, the return matching rule is determined based on the target error code, and the return parameters are configured according to the rule, thereby ensuring the accuracy of the rule configuration of the return parameters.
[0087] Further, the step of determining the target mock server shield based on the target mock code and the simulated mock code includes:
[0088] Step k: Determine the mock server shield based on the target mock code and the simulated mock code;
[0089] Once the target mock code and the simulated mock code are obtained, the simulated mock code can be placed after the target mock code. In other words, the mock code generated by the exception error code rules can be placed after the mock code generated by the normal rules to obtain the mock server mock. The mock server mock will only take effect after receiving the test data corresponding to the request parameters input by the tester, thus obtaining the target mock server mock.
[0090] Step h: Obtain the target test data corresponding to the target mock code in the request parameters, and enter each of the test data into the mock server panel, and use the mock server panel with each of the test data as the target mock server panel.
[0091] Once the mock server template is obtained through the rule engine and error code database, the values listed in the request parameters of the mock server template are initially empty. Therefore, by retrieving the target test data corresponding to the target mock code from the request parameters and inputting this target test data into the mock server template, a valid mock server template can be obtained and used as the target mock server template. The target test data can be pre-entered by testers in the interface documentation or added during testing on the mock server platform.
[0092] In this embodiment, the effectiveness of the mock server is ensured by recording the test data of each target into the mock server.
[0093] The present invention also provides a baffle generating apparatus, with reference to Figure 3 The baffle generating device includes:
[0094] The acquisition module is used to acquire the input standard interface document and configure rules for the request parameters and return parameters in the standard interface document through the rule engine.
[0095] The parsing module is used to parse the request parameters that have been configured with rules through the rule engine to obtain the target mock code corresponding to the request parameters, and to parse the return parameters that have been configured with rules through the rule engine to obtain the simulated mock code corresponding to the return parameters;
[0096] The determination module is used to determine the target mockserver baffle based on the target mock code and the simulated mock code.
[0097] Optionally, the acquisition module is further configured to:
[0098] The request matching rule corresponding to the request parameter is determined by the rule engine, and the request parameter is configured according to the request matching rule;
[0099] A preset number of error codes are obtained through a rules engine, and the return parameters are configured with rules based on each error code.
[0100] Optionally, the acquisition module is further configured to:
[0101] The rule engine obtains multiple input test data, and then matches each test data with the request parameters in sequence.
[0102] If there is target test data in each of the test data that matches the request parameters, then the matching rule corresponding to the target test data shall be used as the request matching rule.
[0103] Optionally, the acquisition module is further configured to:
[0104] Obtain the return result corresponding to the request parameters and multiple error codes in the error code library corresponding to the rule engine, and match the result return code corresponding to the return result with each of the error codes in sequence;
[0105] If no error code matching the result return code is found among the error codes, then the result return code is maintained in the error code library.
[0106] Optionally, the acquisition module is further configured to:
[0107] Obtain the status code returned by the request parameter, construct the return content based on the status code value, and use the return content as the return result corresponding to the request parameter.
[0108] Optionally, the acquisition module is further configured to:
[0109] The rule engine retrieves a preset number of error codes from an error code library containing the returned result codes, and then matches the error codes with the expected results in the request parameters in sequence.
[0110] If a target error code exists among the error codes that matches the expected result in the request parameters, then the matching rule corresponding to the target error code is used as the return matching rule corresponding to the return parameter, and the return parameter is configured with rules based on the return matching rule.
[0111] Optionally, the determining module is further configured to:
[0112] Determine the mock server shield based on the target mock code and the simulated mock code;
[0113] Obtain the target test data corresponding to the target mock code from the request parameters, and enter each target test data into the mock server panel, and use the mock server panel with each target test data as the target simulation server mock server panel.
[0114] The methods executed by the above-mentioned program modules can be referred to in the various embodiments of the baffle generation method of the present invention, and will not be repeated here.
[0115] The present invention also provides a computer storage medium.
[0116] The present invention stores a baffle generation program on a computer storage medium, and when the baffle generation program is executed by a processor, it implements the steps of the baffle generation method described above.
[0117] The method implemented when the baffle generation program running on the processor is executed can be referred to in various embodiments of the baffle generation method of the present invention, and will not be repeated here.
[0118] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.
[0119] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, 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 disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.
[0121] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.
Claims
1. A method for generating a baffle, characterized in that, The baffle generation method includes the following steps: Obtain the standard interface document of the terminal, and configure rules for the request parameters and return parameters in the standard interface document through the rule engine; The rule engine parses the request parameters that have been configured with rules to obtain the target mock code corresponding to the request parameters, and the rule engine also parses the return parameters that have been configured with rules to obtain the simulated mock code corresponding to the return parameters. The target mock server shield is determined based on the target mock code and the simulated mock code. The step of configuring rules for the request parameters and return parameters in the standard interface document using a rule engine includes: The request matching rule corresponding to the request parameter is determined by the rule engine, and the request parameter is configured according to the request matching rule; A preset number of error codes are obtained through a rules engine, and the return parameters are configured with rules based on each error code; The step of determining the request matching rule corresponding to the request parameter through the rule engine includes: The rule engine obtains multiple input test data, and then matches each test data with the request parameters in sequence. If there is target test data in each of the test data that matches the request parameters, then the matching rule corresponding to the target test data shall be used as the request matching rule.
2. The baffle generation method as described in claim 1, characterized in that, The step of using the matching rule corresponding to the target test data as the request matching rule after the step of finding target test data that matches the request parameters in each of the test data includes: Obtain the return result corresponding to the request parameters and multiple error codes in the error code library corresponding to the rule engine, and match the result return code corresponding to the return result with each of the error codes in sequence; If no error code matches the result return code among the error codes, then the result return code is stored in the error code library.
3. The baffle generation method as described in claim 2, characterized in that, The step of obtaining the return result corresponding to the request parameters includes: Obtain the status code returned by the request parameter, construct the return content based on the status code value, and use the return content as the return result corresponding to the request parameter.
4. The baffle generation method as described in claim 2, characterized in that, The step of obtaining a preset number of error codes through a rule engine and configuring rules for the returned parameters based on each error code includes: The rule engine retrieves a preset number of error codes from an error code library containing the returned result codes, and then matches the error codes with the expected results in the request parameters in sequence. If a target error code exists among the error codes that matches the expected result in the request parameters, then the matching rule corresponding to the target error code is used as the return matching rule corresponding to the return parameter, and the return parameter is configured with rules based on the return matching rule.
5. The baffle generation method according to any one of claims 1-4, characterized in that, The step of determining the target mock server shield based on the target mock code and the simulated mock code includes: Determine the mock server shield based on the target mock code and the simulated mock code; Obtain the target test data corresponding to the target mock code from the request parameters, and enter each target test data into the mock server panel, and use the mock server panel with each target test data as the target simulation server mock server panel.
6. A baffle generating device, characterized in that, The baffle generating device includes: The acquisition module is used to acquire the input standard interface document and configure rules for the request parameters and return parameters in the standard interface document through the rule engine. The parsing module is used to parse the request parameters that have been configured with rules through the rule engine to obtain the target mock code corresponding to the request parameters, and to parse the return parameters that have been configured with rules through the rule engine to obtain the simulated mock code corresponding to the return parameters; The determination module is used to determine the target mock server shield based on the target mock code and the simulated mock code; The acquisition module is specifically used to determine the request matching rule corresponding to the request parameter through the rule engine, and to configure the request parameter according to the request matching rule; to acquire a preset number of error codes through the rule engine, and to configure the return parameter according to each error code; The acquisition module is specifically used to acquire multiple input test data through the rule engine, and sequentially match each test data with the request parameter; if there is target test data in each test data that matches the request parameter, then the matching rule corresponding to the target test data is used as the request matching rule.
7. A baffle generating device, characterized in that, The baffle generation device includes: a memory, a processor, and a baffle generation program stored in the memory and executable on the processor, wherein when the baffle generation program is executed by the processor, it implements the steps of the baffle generation method as described in any one of claims 1 to 5.
8. A computer storage medium, characterized in that, The computer storage medium stores a baffle generation program, which, when executed by a processor, implements the steps of the baffle generation method as described in any one of claims 1 to 5.