Mock test method, device, equipment and storage medium

Abstract

The application discloses a MOCK testing method and device, equipment and a storage medium. The method comprises the following steps: in response to a rule configuration operation triggered by a user, obtaining a target configuration rule of a target interface; generating a target MOCK configuration file according to the target configuration rule and historical response data of the target interface in an interface database, wherein the historical response data of different interfaces are collected in advance by a response interceptor and stored in the interface database; and sending the target MOCK configuration file to a front-end development server, so that the front-end development server returns simulated response data according to the target MOCK configuration file when testing the target interface. The application can replace manual operation and improve the collection efficiency by automatically collecting interface historical data through a response interceptor. Furthermore, the application can reduce the operation complexity by generating a configuration file through interface configuration rules, thereby improving the overall efficiency of the MOCK test.

Description

Technical Field

[0001] This application relates to the field of interface testing technology, and in particular to a MOCK testing method, apparatus, device and storage medium. Background Technology

[0002] In front-end development within the financial industry, the data required for front-end page rendering and feature debugging typically relies on back-end API responses. Since the development and deployment of back-end APIs generally lag behind the front-end development cycle, front-end developers find it difficult to directly call the actual APIs to obtain data during the page building phase. Therefore, MOCK technology is widely used in front-end development. This technology constructs simulated data to replace real API responses, allowing front-end development to proceed independently of the back-end's progress. Existing MOCK testing methods usually involve developers manually triggering each API request in the browser console, copying the request path, input parameters, and output data from the response content, processing the collected API response data to obtain MOCK data, and then having the front-end development server call this MOCK data to execute the test.

[0003] However, existing methods rely entirely on manual operations by developers to collect API response data. Developers must manually trigger requests for each API in the browser and copy the corresponding request path, input parameters, and output data from the console output. This process is tedious and highly repetitive, especially when the project involves a large number of APIs. Collecting response data from all APIs requires a significant amount of manpower and time, hindering the overall efficiency of MOCK testing. Summary of the Invention

[0004] The main purpose of this application is to provide a MOCK testing method, apparatus, device and storage medium, which aims to solve the technical problem that existing MOCK testing methods rely on manual collection of interface response data, resulting in low overall efficiency of MOCK testing.

[0005] To achieve the above objectives, this application proposes a MOCK testing method, the method comprising: In response to the rule configuration operation triggered by the user in the operation and maintenance management interface, obtain the target configuration rule for the target interface; Based on the target configuration rules and the historical response data of the target interface in the interface database, a target MOCK configuration file is generated. The interface database stores historical response data of different interfaces collected in advance by the response interceptor. The target MOCK configuration file is sent to the front-end development server so that the front-end development server returns simulated response data based on the target MOCK configuration file when testing the target interface.

[0006] In one embodiment, the step of obtaining the target configuration rule for the target interface in response to a rule configuration operation triggered by a user in the operation and maintenance management interface includes: In response to the user's request to view interface data in the operation and maintenance management interface, display a list of collected interfaces; When the user selects a target interface based on the list of collected interfaces, a rule configuration template is displayed to the user. The rule configuration template includes fields to be filled in and fields to be selected. Based on the user's actions in filling out the fields to be filled and the user's actions in selecting the fields to be selected, the target configuration rules for the target interface are obtained.

[0007] In one embodiment, the step of obtaining the target configuration rule for the target interface based on the user's input operation on the field to be filled and the user's selection operation on the field to be selected includes: Based on the user's actions in filling out the fields to be filled and the user's actions in selecting the fields to be selected, a first configuration rule is obtained; Obtain historical response data of the target interface, the historical response data including historical input parameters and historical output data; The historical input parameters and the historical output data are input into a preset semantic analysis model, the business logic relationship is output through the preset semantic analysis model, and a second configuration rule is generated based on the business logic relationship; The first configuration rule and the second configuration rule are determined as the target configuration rules for the target interface.

[0008] In one embodiment, the first configuration rule includes: de-identification rules, filtering rules, and time-limited rules; the step of obtaining the first configuration rule based on the user's filling operation on the field to be filled and the user's selection operation on the field to be selected includes: Based on the user's input operation on the field to be filled, determine the filter condition parameters set by the user and the dynamic generation parameters of the time field set by the user; and based on the user's selection operation on the field to be selected, determine the de-identified field and de-identification method selected by the user. The desensitization rule is generated based on the desensitization field and the desensitization method; the filtering rule is generated based on the filtering condition parameters; and the timeliness rule is generated based on the time field dynamically generated parameters.

[0009] In one embodiment, the step of inputting the historical input parameters and the historical output data into a preset semantic analysis model, outputting business logic relationships through the preset semantic analysis model, and generating a second configuration rule based on the business logic relationships includes: The historical input parameters and the historical output data are input into a preset semantic analysis model; The preset semantic analysis model identifies the business start time field contained in the historical input parameters and the business end time field contained in the historical output data, and generates business logic rules to limit the business generation time between the business start time and the business end time. The business logic rule is displayed to the user, and upon receiving confirmation from the user regarding the business logic rule, the business logic rule is identified as the second configuration rule.

[0010] In one embodiment, before the step of generating the target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database, the method further includes: The data acquisition component is a response interceptor integrated into the front-end development server to collect historical response data of different interfaces obtained from the interface requests by the front-end development server. The historical response data is encrypted, and the encrypted historical response data is stored in the interface database according to the correspondence with each of the interfaces.

[0011] In one embodiment, the target configuration rules include de-identification rules, filtering rules, timeliness rules, and business logic rules; the step of generating a target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database includes: Read the historical response data of the target interface from the interface database. The historical response data includes the request path, historical input parameters and historical output data of the target interface. According to the desensitization rules, the corresponding fields in the historical output data are desensitized; according to the filtering rules, the data entries in the historical output data are filtered; and according to the timeliness rules, the time field in the historical output data is replaced with a dynamically generated expression to obtain simulated output data. The simulated output data is validated according to the business logic rules, and the validated simulated output data, along with the request path and the historical input parameters, are assembled according to a preset configuration file format to generate a target MOCK configuration file.

[0012] Furthermore, to achieve the above objectives, this application also proposes a MOCK testing apparatus, the apparatus comprising: The interactive configuration module is used to respond to the rule configuration operation triggered by the user in the operation and maintenance management interface and obtain the target configuration rule for the target interface. The configuration application module is used to generate a target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database. The interface database stores historical response data of different interfaces collected in advance by the response interceptor. The interface testing module is used to send the target MOCK configuration file to the front-end development server, so that the front-end development server returns simulated response data based on the target MOCK configuration file when testing the target interface.

[0013] In addition, to achieve the above objectives, this application also proposes a MOCK testing device, the device comprising: a memory, a processor, and a MOCK testing program stored in the memory and executable on the processor, the MOCK testing program being configured to implement the steps of the MOCK testing method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, storing a MOCK test program, which, when executed by a processor, implements the steps of the MOCK test method as described above.

[0015] This application discloses a MOCK testing method, apparatus, device, and storage medium. The method includes: in response to a rule configuration operation triggered by a user in an operation and maintenance management interface, obtaining a target configuration rule for a target interface; generating a target MOCK configuration file based on the target configuration rule and historical response data of the target interface in an interface database, wherein the interface database stores historical response data of different interfaces collected in advance by a response interceptor; and sending the target MOCK configuration file to a front-end development server so that the front-end development server returns simulated response data based on the target MOCK configuration file when testing the target interface.

[0016] This application automatically collects historical response data from different interfaces and stores it in the interface database via a response interceptor. This eliminates the need for developers to manually trigger requests and copy response data for each interface in the browser, avoiding the tedious and time-consuming nature of manual data collection. This improves the efficiency of interface response data collection and consequently enhances the overall efficiency of MOCK testing. Furthermore, users can obtain target configuration rules simply by configuring rules in the operations and maintenance management interface, without needing to manually write data processing logic code, thus reducing the complexity of data preparation during MOCK testing. In addition, since the historical response data in the interface database is automatically collected by the response interceptor, compared to manual copying, the integrity and accuracy of the collected data are guaranteed. This ensures that the target MOCK configuration file generated based on the historical response data and target configuration rules accurately reflects the response structure of the target interface, thereby improving the reliability of the front-end development server when executing tests based on the target MOCK configuration file. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the MOCK testing method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the MOCK testing method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the MOCK testing method of this application; Figure 4 This is a schematic diagram of the system architecture of the MOCK testing method in this application; Figure 5 This is a schematic diagram of the entire MOCK testing method of this application; Figure 6 This is a schematic diagram of the module structure of the MOCK testing device of this application; Figure 7 This is a schematic diagram of the MOCK testing equipment used in this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] This application provides a MOCK testing method, referencing... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the MOCK testing method of this application. In this embodiment, the method includes steps S10 to S30: Step S10: In response to the rule configuration operation triggered by the user in the operation and maintenance management interface, obtain the target configuration rule for the target interface.

[0024] It should be noted that the method in this embodiment can be applied in scenarios where the backend interface development progress lags behind the frontend development cycle in the financial industry's frontend development process, and frontend developers need to construct MOCK data to independently advance frontend page development and testing. The executing entity of this embodiment can be a computing electronic device with functions such as data processing, network communication, and program execution, such as a server, mainframe computer, or cloud device. Here, a MOCK test data preparation server (referred to as "server") is used as an example to illustrate this embodiment and the following embodiments.

[0025] It should be understood that the operations and maintenance management interface is a visual interface provided by the server to front-end developers or testers for managing interface data and configuring MOCK rules. The rule configuration operations triggered by users in the operations and maintenance management interface can be operations performed by users through mouse clicks, form filling, option selection, etc., to limit the method of MOCK data generation. Rule configuration is the process by which users convey their MOCK data generation requirements for the target interface to the server through interface interaction.

[0026] Target configuration rules are a set of structured rule data generated by user configuration operations, used to define how historical response data is processed during subsequent MOCK configuration file generation. Target configuration rules can include de-identification rules, filtering rules, and time-sensitive rules. De-identification rules instruct sensitive fields to be obfuscated, filtering rules instruct data entries that meet specific conditions to be filtered, and time-sensitive rules instruct the replacement of fixed-time fields with dynamically generated expressions. The target interface is the front-end interface corresponding to the current MOCK configuration file to be generated, which can be selected by the user from the list of collected interfaces in the operations and maintenance management interface.

[0027] In the implementation, after selecting the target interface in the operation and maintenance management interface, the user can complete the selection of de-identification fields and methods, the filling in of filter condition parameters, and the filling in of dynamically generated parameters for the time field in the configuration template provided in the interface. The server can then generate target configuration rules based on the configuration information filled in by the user. After obtaining the target configuration rules, the server associates and stores the target configuration rules with the interface identifier of the target interface for later use when generating the MOCK configuration file.

[0028] Furthermore, to illustrate in detail how users configure target configuration rules for the target interface, step S10 includes: steps S101~S103: Step S101: In response to the user's interface data viewing operation triggered in the operation and maintenance management interface, display the list of collected interfaces.

[0029] It should be noted that the interface data viewing operation can be triggered by the user in the operation and maintenance management interface to view the data information related to each interface that has been collected by the server. The list of collected interfaces is a summary list of all interfaces stored in the interface database. Each interface entry in this list includes at least the interface name, interface request path, collection time, and the number of historical response data entries for that interface.

[0030] It should be understood that the server can respond to a user's interface data viewing operation by reading the index information of all interfaces from the interface database and displaying these interfaces in a list format in the operation and maintenance management interface for users to browse and select.

[0031] In the implementation, after logging into the operation and maintenance management interface, users can trigger the interface data viewing operation by clicking the entry buttons such as "Interface Management" or "Data View". After receiving the operation, the server sends a query request to the interface database to obtain the index information of all collected interfaces. The collected interfaces are then sorted in reverse chronological order by collection time and rendered into the table component of the interface to form a list of collected interfaces. Users can view the basic information of each interface in this list.

[0032] Step S102: When the user selects a target interface based on the list of collected interfaces, a rule configuration template is displayed to the user. The rule configuration template includes fields to be filled in and fields to be selected.

[0033] It should be noted that the rule configuration template can be a predefined interface form template used by the server to guide users in configuring the target rule. This rule configuration template can contain fields to be filled in and fields to be selected.

[0034] The fields to be filled in are those where users need to input specific parameter values ​​via keyboard, such as the numerical threshold of the filtering conditions and the range of days for dynamic time offset; the fields to be selected are those where users need to select configuration items from drop-down menus or option groups via mouse clicks, such as the name of the masked field and the type of masking method. The server transforms the complex rule definition process, which originally required users to write code, into an interactive interface by displaying rule configuration templates, thereby lowering the user's operational threshold.

[0035] In the implementation, after a user clicks on an interface entry in the list of collected interfaces and triggers the "Configure Rules" button, the server retrieves a rule configuration template adapted to that interface type from the database and renders and displays the template in the configuration area of ​​the operations and maintenance management interface. This rule configuration template includes pre-defined configurable de-identification field options, filter condition input boxes, and timeliness parameter input boxes for the target interface, allowing users to select or fill in the information in the appropriate locations.

[0036] Step S103: Based on the user's filling operation on the field to be filled and the user's selection operation on the field to be selected, obtain the target configuration rule for the target interface.

[0037] It should be noted that the fill-in operation is the operation in which the user enters specific parameter values ​​in the field to be filled in, while the select operation is the operation in which the user selects from multiple candidate options in the field to be selected.

[0038] The server can monitor user input and selection actions in the rule configuration template in real time, thereby obtaining the specific configuration values ​​entered or selected by the user in each field. Based on these specific configuration values, the server updates the rule configuration template to obtain structured target configuration rules. These target configuration rules can then contain all the user's configuration requirements for the target interface simulated data, including anonymization methods, filtering conditions, and timeliness processing.

[0039] In the implementation, after the user completes the input of all fields to be filled in and the selection of fields to be selected in the rule configuration template, they can click the "Confirm" or "Save" button. In response to this confirmation, the server reads the configuration values ​​from all fields to be filled in and selected, assembles them based on the rule configuration template, and generates a JSON-formatted rule data package as the target configuration rule. This package is stored locally on the server or in a database, indexed by the target interface's identifier. Subsequently, when the server generates the target MOCK configuration file, it can invoke this target configuration rule using the target interface's identifier.

[0040] Step S20: Generate a target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database. The interface database stores historical response data of different interfaces collected in advance by the response interceptor.

[0041] It should be noted that the interface database can be a database on the server used to store historical response data for each interface. The interface database stores historical response data for different interfaces, pre-collected by a response interceptor. This historical response data can be records of interface request and response data captured and reported to the server storage by the response interceptor integrated in the front-end development server when calling various interfaces. It can include the request path, input parameters, and output response data for the corresponding interface. The historical response data for the target interface consists of all historical response data records in the interface database associated with the interface identifier of the target interface.

[0042] It should be understood that a MOCK configuration file is a data file generated by the server after processing the historical response data of the target interface according to the target configuration rules. This MOCK configuration file can have a preset configuration file format that can be recognized by the front-end development server, which includes the request path of the target interface, the request parameter format, and the simulated response data after rule processing.

[0043] When the front-end development server calls the target interface, it can read the MOCK configuration file and return the simulated response data contained therein, thereby replacing the response of the real back-end interface. This allows front-end developers to complete page debugging and functional testing without the need for the real back-end interface to be available.

[0044] In the specific implementation, the server reads the historical response data corresponding to the target interface from the interface database, parses out the request path, input parameters and output response data, and reads the pre-obtained target configuration rules from local storage. Based on the target configuration rules, the server simulates the output response data to generate simulated response data. Then, the server assembles the simulated response data with the request path and input parameters according to the preset MOCK configuration file format (such as JSON or JS format) to generate the target MOCK configuration file. The target MOCK configuration file is stored in the specified directory of the server with the interface identifier of the target interface as the file name.

[0045] Step S30: Send the target MOCK configuration file to the front-end development server so that the front-end development server returns simulated response data based on the target MOCK configuration file when testing the target interface.

[0046] It should be noted that a front-end development server is a server device that runs front-end project code. It can be a development server that front-end developers run on their local computers (such as Webpack Dev Server, Vite Dev Server, etc.), or a front-end application server deployed in a development or testing environment.

[0047] It should be understood that, under normal operating conditions, API requests initiated by the front-end pages of the front-end development server default to the actual back-end API address. Upon receiving the target MOCK configuration file, the front-end development server can switch its API call target from the actual back-end API to this MOCK configuration file.

[0048] In the implementation, the server sends the generated target MOCK configuration file to a designated storage directory on the front-end development server via a network transmission protocol (such as HTTP or file transfer protocol). Upon receiving the target MOCK configuration file, the front-end development server can configure local interface routes based on the request paths within it. When the front-end page initiates a test request to an interface call pointing to that request path, the front-end development server can read the corresponding simulated response data from the target MOCK configuration file and return it to the front-end page. Therefore, front-end developers can obtain complete interface data responses on the front-end page without waiting for the actual back-end interface to be ready, thus enabling parallel front-end and back-end development.

[0049] This embodiment obtains the target configuration rules for the target interface in response to the rule configuration operation triggered by the user in the operation and maintenance management interface, and automatically generates the target MOCK configuration file based on the pre-collected historical response data stored in the interface database. The user only needs to complete the rule configuration in the interface to obtain a usable MOCK configuration file, without the need to manually write data processing logic code. At the same time, the MOCK configuration file is generated based on the pre-collected historical response data of the response interceptor, avoiding developers from manually triggering interface requests and copying response data one by one, simplifying the MOCK data preparation process and improving the efficiency of front-end MOCK testing.

[0050] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the MOCK testing method of this application.

[0051] In this embodiment, to further reduce the amount of manual coding while ensuring the reliability of the target configuration rules, step S103 further includes: steps S1031~S1034: Step S1031: Obtain the first configuration rule based on the user's filling operation on the field to be filled and the user's selection operation on the field to be selected.

[0052] It should be noted that the first configuration rule is a set of rules directly generated by the user through filling in and selecting rules in the rule configuration template of the operation and maintenance management interface. This set of rules can reflect the user's explicit configuration requirements for the target interface simulated data in terms of data anonymization, data filtering, and timeliness processing.

[0053] It should be understood that after the server displays the rule configuration template to the user in the operation and maintenance management interface, it can monitor the user's operation behavior in each field in real time: the user selects the field name to be de-identified (such as "mobile phone number" or "ID number") by clicking the mouse in the field to be selected and selects the de-identification method (such as "replace the middle four digits with..."). The server records the de-identified fields and de-identification methods determined by the above selection operation; the user enters filter condition parameters (such as "transaction amount greater than 100") in the fields to be filled in via the keyboard, and the server records these filter condition parameters; the user enters dynamically generated parameters for the time field in the fields to be filled in via the keyboard (such as "offset range is from the current time minus 3 days to the current time minus 1 day"), and the server records these dynamically generated parameters for the time field. The server can encapsulate all the above-mentioned configuration information according to a preset rule data structure to form a first configuration rule. The first configuration rule includes de-identification rules, filtering rules, and time-sensitive rules.

[0054] Furthermore, to specifically illustrate the generation process of the various rules (de-identification rules, filtering rules, and time-sensitive rules) included in the first configuration rule mentioned above, step S1031 further includes: steps S10311~S10312: Step S10311: Based on the user's filling operation on the field to be filled, determine the filter condition parameters set by the user and the dynamic generation parameters of the time field set by the user, and based on the user's selection operation on the field to be selected, determine the de-identified field and de-identification method selected by the user.

[0055] It should be noted that the fields to be filled are those in the rule configuration template that require users to input specific parameter values ​​via the keyboard. These fields may include, for example, filter condition parameters and dynamically generated parameters for time fields.

[0056] The filtering condition parameters can be user-defined conditional expressions or thresholds used to filter data entries from historical response data. These can include comparison conditions (such as "amount greater than 1000"), range conditions (such as "date between January 1, 2026 and June 30, 2026"), or logical combination conditions (such as "status equal to paid and amount greater than 500"), etc. This embodiment does not impose any restrictions on these.

[0057] The time field can be dynamically generated parameters that can be user-defined to replace fixed time values ​​in historical response data with dynamic time expressions. These parameters can include a base time (such as "current system time"), an offset range (such as "offset -3 days to -1 day"), and a time format (such as "YYYY-MM-DD HH:mm:ss"). This embodiment does not impose any restrictions on these parameters.

[0058] The fields to be selected are those that users need to select from the candidate options by clicking with the mouse in the rule configuration template. The fields to be selected can include, for example, de-identified fields and de-identification methods.

[0059] The de-identified field can be the name of a field in historical response data that needs to be de-identified, as specified by the user. The de-identification method can be the specific method selected by the user to obfuscate the de-identified field, which can include replacement (e.g., replacing the middle four digits of a mobile phone number with...). Methods include truncating (e.g., keeping only the first six and last four digits of the ID number), and encryption (e.g., MD5 encryption of the name).

[0060] In practice, after the user completes the input of all fields to be filled in and the selection of fields to be selected in the rule configuration template, the server reads the specific configuration values ​​that the user has filled in or selected in all fields.

[0061] Step S10312: Generate the desensitization rule based on the desensitization field and the desensitization method, generate the filtering rule based on the filtering condition parameters, and generate the timeliness rule based on the dynamic generation parameters of the time field.

[0062] It should be noted that the de-identification rules are rule data generated by the server based on the de-identification fields and de-identification methods selected by the user. These rules are used to instruct the subsequent de-identification processing of sensitive fields in historical response data during the generation of the MOCK configuration file.

[0063] Filtering rules are rules generated by the server based on the filtering conditions parameters set by the user. These rules are used to instruct the output response data in the historical response data to be filtered according to conditions during the subsequent MOCK configuration file generation process.

[0064] The timeliness rules are rule data generated by the server based on parameters dynamically generated by the user-defined time field. They are used to instruct the server to replace the fixed time field in the historical response data with a dynamic expression during the subsequent MOCK configuration file generation process.

[0065] In practical implementation, the server can establish a mapping relationship between the aforementioned determined de-identified fields and de-identification methods to generate de-identification rules; convert the filtering condition parameters into structured condition expressions to generate filtering rules; and encapsulate the base time, offset range, and time format in the dynamically generated parameters of the time field into a dynamic time generation template to generate time-sensitive rules. The de-identification rules, filtering rules, and time-sensitive rules together constitute the first configuration rule.

[0066] Step S1032: Obtain historical response data of the target interface, the historical response data including historical input parameters and historical output data.

[0067] It should be noted that the historical response data of the target interface refers to all interface call records associated with the interface identifier of the target interface in the interface database. This historical response data can specifically include historical input parameters and historical output data. Historical input parameters can be a set of request parameters passed from the front-end development server to the actual back-end interface when calling the target interface, and may include fields such as business start time, business end time, user identifier, and pagination parameters. Historical output data can be a set of response data returned by the actual back-end interface to the front-end development server after receiving the request, and may include fields such as business occurrence time, transaction amount, and status.

[0068] In practice, the server can read the historical response data of the target interface from the interface database, parse each call record in the historical response data, and separate the historical input parameter part and the historical output data part as input data for subsequent steps.

[0069] Step S1033: Input the historical input parameters and the historical output data into the preset semantic analysis model, output the business logic relationship through the preset semantic analysis model, and generate the second configuration rule according to the business logic relationship.

[0070] It should be noted that the preset semantic analysis model is a pre-trained artificial intelligence model used to identify the semantic relationship between input fields and output fields. This preset semantic analysis model can be a pre-trained language model based on natural language processing technology (such as BERT, GPT, etc.), or it can be a machine learning model specifically trained for interface field semantic matching tasks. This embodiment does not impose any restrictions on this.

[0071] This pre-defined semantic analysis model can receive the field names and example values ​​of historical input parameters and the field names and example values ​​of historical output data as input. Through semantic understanding and analysis, it outputs the business logic relationship between the input fields and the output fields.

[0072] It should be understood that business logic relationships refer to the association between fields in historical input parameters and fields in historical output data in terms of their business meaning. For example, there is a business logic relationship between the "start date" field in historical input parameters and the "transaction date" field in historical output data that "the transaction date should be after the start date".

[0073] It should be noted that the second configuration rule is rule data generated by the server based on the business logic relationship output by the above-mentioned preset semantic analysis model. It can be used to instruct the historical response data to be validated or filtered at the business logic level during the subsequent MOCK configuration file generation process.

[0074] In practical implementation, the server can preprocess the aforementioned historical input parameters and historical output data according to a preset input format, extracting and standardizing the field names and example values ​​before inputting them into a preset semantic analysis model. The preset semantic analysis model then performs semantic encoding and association analysis on the input and output fields, outputting one or more sets of field pairs and their corresponding business logic relationships. Upon receiving the business logic relationships output by the model, the server converts these relationships into structured rule expressions to generate a second configuration rule.

[0075] Furthermore, to specifically illustrate the process of the aforementioned preset semantic analysis model identifying business logic relationships and generating the second configuration rule, step S1033 further includes: steps S10331~S10333: Step S10331: Input the historical input parameters and the historical output data into the preset semantic analysis model.

[0076] It should be noted that the server can assemble the obtained historical input parameters and historical output data according to the input format required by the preset semantic analysis model, and then send the analysis request to the preset semantic analysis model.

[0077] It should be understood that the above analysis request may include all field names and example values ​​of historical input parameters, as well as all field names and example values ​​of historical output data. Upon receiving the above input data, the default semantic analysis model can initiate the semantic analysis process.

[0078] Step S10332: Identify the business start time field contained in the historical input parameters and the business end time field contained in the historical output data through the preset semantic analysis model, and generate business logic rules for limiting the business generation time between the business start time and the business end time.

[0079] It should be noted that the preset semantic analysis model can perform pairwise semantic matching between the names and example values ​​of each field in the historical input parameters and the names and example values ​​of each field in the historical output data through semantic encoding and similarity calculation.

[0080] For example, when the model identifies that the historical input parameters contain fields with semantic features such as "start time" and "start date", and the historical output data contains fields with semantic features such as "end time" and "deadline", the model can determine that there is a time range constraint relationship between the input field and the output field.

[0081] Furthermore, when the model identifies fields in the historical output data that have semantic features such as "transaction time", "business occurrence time", and "creation time", the model determines that the business occurrence time of the field should be subject to the above-mentioned time range constraints.

[0082] It should be understood that, based on the above determination, the model can generate business logic rules. These rules can be used to limit the business generation time in the historical output data to between the business start time and business end time in the historical input parameters. Furthermore, they can be expressed as structured conditional expressions, such as "(business generation time... (Business start time) AND (Business generation time) (Business end time).

[0083] In its implementation, the pre-defined semantic analysis model semantically encodes the field names in historical input parameters and calculates their similarity with pre-defined time-based semantic feature vectors. This identifies business start time fields (e.g., fields named "startDate", "beginTime", "start date") and business end time fields (e.g., fields named "endDate", "endTime", "deadline") in the historical input parameters. Simultaneously, the pre-defined semantic analysis model can also semantically encode the field names in historical output data, identifying business generation time fields (e.g., fields named "tradeTime", "createTime", "transaction time") in the historical output data.

[0084] The preset semantic analysis model can then generate business logic rules based on the above recognition results to limit the business generation time to between the business start time and the business end time.

[0085] Step S10333: Show the business logic rule to the user, and when the user confirms the business logic rule, determine the business logic rule as the second configuration rule.

[0086] It should be noted that, to ensure the accuracy of the business logic rules automatically generated by the AI ​​model, the server can display the business logic rules in a visual manner on the operation and maintenance management interface after they are generated, so that users can review and confirm them.

[0087] It should be understood that users can view, judge, and confirm the displayed business logic rules. When a user confirms that the business logic rule is correct, they can trigger a confirmation operation by clicking the "Confirm" or "Accept" button on the interface. Only after receiving the user's confirmation operation will the server officially confirm the business logic rule as the second configuration rule.

[0088] Furthermore, if a user determines that a business logic rule is incorrect or incomplete, the user can modify the rule using the editing function provided in the interface, or directly reject the adoption of the business logic rule. This embodiment does not impose any limitations on this.

[0089] In practice, after generating business logic rules, the server can display these rules in both natural language description and structured expression formats in the rule confirmation area of ​​the operations and maintenance management interface. After reviewing the displayed business logic rules, if the user determines that the rules meet business expectations, they can click the "Confirm Acceptance" button on the interface to trigger a confirmation operation. In response to this confirmation operation, the server formally stores the business logic rules as the second configuration rule.

[0090] Step S1034: Determine the first configuration rule and the second configuration rule as the target configuration rule for the target interface.

[0091] It should be noted that the first configuration rule is the rule directly configured by the user through the interface, while the second configuration rule is the rule automatically generated by the server based on a preset semantic analysis model and confirmed by the user. After obtaining the first and second configuration rules, the server can merge them together as the target configuration rule for the target interface.

[0092] It should be understood that through the above merging operation, the target configuration rules include not only user-configured de-identification rules, filtering rules, and timeliness rules, but also business logic rules generated with the assistance of AI models. Therefore, during the subsequent generation of the MOCK configuration file, the server can comprehensively apply all of these rules to process the historical response data of the target interface.

[0093] In the specific implementation, the server merges the first and second configuration rules obtained above, and uses the interface identifier of the target interface as an index to store the merged target configuration rules locally on the server or in a database. Then, when generating the target MOCK configuration file subsequently, the server can invoke the complete target configuration rules using the interface identifier of the target interface.

[0094] This embodiment can automatically identify the semantic relationships between fields in historical input parameters and historical output data through a preset semantic analysis model, and generate business logic rules as second configuration rules accordingly. This allows business logic filtering rules that originally required manual analysis and coding to be automatically derived by the AI ​​model, reducing manual coding and lowering the difficulty and error rate of business logic configuration. Furthermore, by displaying the AI-generated business logic rules to the user for confirmation, the accuracy of the automatically generated rules is ensured, balancing configuration efficiency and rule reliability.

[0095] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the MOCK testing method of this application.

[0096] In this embodiment, to specifically illustrate how to collect historical data from different interfaces through a response interceptor, before step S20, the following steps are included: S01~S02: Step S01: Collect historical response data of different interfaces obtained by the front-end development server in response to interface requests through a data acquisition component. The data acquisition component is a response interceptor integrated in the front-end development server.

[0097] It should be noted that the data acquisition component can be a response interceptor integrated into the front-end development server. The data acquisition component can be a piece of program code embedded in the front-end framework request library, which is used to automatically trigger the data capture operation when the interface request is completed.

[0098] The data acquisition component can be provided to front-end developers in the form of a Software Development Kit (SDK). Front-end developers then download the dependency packages of the data acquisition component into their front-end projects using package management tools, and import and initialize the data acquisition component in the entry file of the front-end project. The data acquisition component registers a data acquisition hook in the global response interceptor of the request library, thus binding the data acquisition component to the response interceptor. When the response interceptor is triggered, the data acquisition component synchronously executes the data capture logic.

[0099] It should also be noted that a front-end development server is a server device that runs front-end project code. It can be a development server that front-end developers run on their local computers, or a front-end application server deployed in a development or testing environment.

[0100] An API request is a network request initiated by the front-end page code via the HTTP protocol to the back-end API when the front-end development server provides data services to the front-end page. This request can be used to obtain the data required for front-end page rendering and function operation. The API request can include the request path and input parameters. Historical response data refers to the response data returned by the back-end API after receiving the API request sent by the front-end development server. By setting up a data collection component, historical response data from different APIs can be automatically captured and recorded during the process of the front-end development server calling APIs, without manual intervention.

[0101] In the implementation, after the front-end development server starts and loads the front-end project, the data collection hooks registered by the data collection component in the global response interceptor of the request library are in a listening state. When the front-end page triggers an interface request, the data collection component can read the request path and input parameters from the request object of the current interface request. When the back-end interface returns response data, the response interceptor is triggered, and the data collection component synchronously reads the output data from the response object corresponding to the current interface request. The data collection component assembles the request path, input parameters, and output data into interface collection data, which serves as the historical response data corresponding to the interface subsequently stored in the database.

[0102] For example, suppose the front-end project running on the front-end development server is a bank transaction query page. When a front-end developer clicks the "Query" button on the page, the front-end page initiates a transaction query request through the axios request library. The request path is / api / queryTrade, and the request parameters include the user ID "123456". When the back-end's actual interface A receives this transaction query request, it responds and returns output data, which may include the transaction serial number, transaction time, transaction amount, and counterparty information. At this time, the data collection component is automatically triggered, reading the request path " / api / queryTrade" and the input parameter "user ID=123456" from the request object, and reading the output data "transaction serial number, transaction time, transaction amount, and counterparty information" from the response object. Then, it assembles the above three pieces of information as the historical response data of interface A.

[0103] In this way, the data acquisition component can automatically capture and report historical response data of different interfaces when each interface request is completed on the front-end development server, without the need for manual intervention by developers, thereby achieving automated data acquisition.

[0104] Step S02: Encrypt the historical response data and store the encrypted historical response data in the interface database according to the correspondence with each of the interfaces.

[0105] It should be noted that, since historical response data may contain sensitive information fields such as user personal information and transaction details, in order to prevent data leakage during storage and transmission, the server can encrypt the historical response data after receiving it from the data collection component.

[0106] It should be understood that the server may use symmetric encryption algorithms (such as AES algorithm), asymmetric encryption algorithms (such as RSA algorithm), or industry-standard encryption protocols to encrypt historical response data, and this embodiment does not impose any restrictions on this.

[0107] Understandably, after encryption is complete, the server can use the request path of each interface as an index identifier to associate the encrypted output response data with the request path and input parameters and store it in the interface database. This will create a one-to-one mapping between the historical response data of each interface and the interface identifier of that interface, so that it can be quickly read according to the interface identifier in the future.

[0108] The interface database can be a relational database (such as MySQL or PostgreSQL), a non-relational database (such as MongoDB), or a distributed file storage system at the physical level. This embodiment does not impose any restrictions on this.

[0109] In its implementation, the server can receive historical response data sent by the data acquisition component and parse out the request path, historical input parameters, and historical output data. Then, sensitive information fields in the output data (such as mobile phone number, ID card number, bank card number, and user name) are encrypted. The encrypted output data is then associated with the request path and input parameters to form an interface record, which is written to the interface database using the request path as an index.

[0110] In this way, the interface database can gradually accumulate historical response data for each interface, thereby forming a data resource pool that can be used for subsequent MOCK configuration file generation.

[0111] Furthermore, to specifically illustrate how to generate the target MOCK configuration file based on the historical response data in the aforementioned interface database, step S20 includes: steps S201~S203: Step S201: Read the historical response data of the target interface from the interface database. The historical response data includes the request path, historical input parameters and historical output data of the target interface.

[0112] It should be noted that before generating the target MOCK configuration file, the server can first read the historical response data of the target interface from the interface database as the basis for generating the MOCK configuration file. The historical response data of the target interface consists of all historical response data records associated with the interface identifier of the target interface in the interface database. The historical response data can include the request path of the target interface, historical input parameters, and historical output data.

[0113] The request path is the URL path that the front-end development server sends a request to the real back-end interface when calling the target interface; the historical input parameters are the set of request parameters that the front-end development server passes to the real back-end interface when calling the target interface; and the historical output data is the set of response data that the real back-end interface returns to the front-end development server after receiving the request.

[0114] In practice, the server can send a data read request to the interface database using the interface identifier of the target interface (e.g., the request path of the target interface " / api / queryTrade") as the query condition. The interface database responds to this data read request by returning all historical response data records associated with the interface identifier of the target interface. The server parses the read historical response data records, extracting the request path, historical input parameters, and historical output data, which are then used as input data for subsequent steps.

[0115] Step S202: Perform desensitization processing on the corresponding fields in the historical output data according to the desensitization rules, filter the data entries in the historical output data according to the filtering rules, and replace the time field in the historical output data with a dynamically generated expression according to the timeliness rules to obtain simulated output data.

[0116] It should be noted that the target configuration rules include a first configuration rule and a second configuration rule, namely, de-identification rules, filtering rules, time-sensitive rules, and business logic rules. The de-identification rules instruct the obfuscation of sensitive fields in historical output data; the filtering rules instruct the selection of data entries that meet specific conditions from historical output data; and the time-sensitive rules instruct the replacement of fixed time fields in historical output data with dynamically generated expressions. These rules can be pre-configured by the user through the operation and maintenance management interface, or automatically generated by a preset semantic analysis model and confirmed by the user. The simulated output data can be the data obtained after sequentially performing de-identification, filtering, and dynamic replacement of time fields on historical output data.

[0117] In practice, the server first performs data masking on the data values ​​corresponding to the masking fields in the historical output data, based on the masking fields and masking methods recorded in the masking rules. For example, if the masking rule instructs the "phone number" field to be "replace the middle four digits with..." Using the "" data anonymization method, the server will change the value of the "phone number" field in each data record in the historical output data from "13212345678" to "132". 5678.

[0118] Next, the server can iterate through the data entries in the historical output data according to the conditional expressions recorded in the filtering rules, and filter out the data entries that meet the conditional expressions. For example, if the filtering rule indicates "transaction amount greater than 100", the server will only keep data entries in the historical output data whose "transaction amount" field value is greater than 100, and delete other entries that do not meet the condition.

[0119] Finally, based on the dynamically generated parameters recorded in the timeliness rules, the server replaces the fixed values ​​of the time field in the historical output data with dynamically generated expressions. For example, if the timeliness rule indicates "Transaction Time = Current System Time - Random 1~10 Days", then the server replaces the fixed value "2026-01-01" of the "Transaction Time" field in the historical output data with the expression "CURRENT_DATE - RANDOM(1,10) DAY". After the above three processes, the server obtains the simulated output data.

[0120] Step S203: Verify the simulated output data according to the business logic rules, and assemble the verified simulated output data with the request path and the historical input parameters according to the preset configuration file format to generate the target MOCK configuration file.

[0121] It should be noted that business logic rules are rules used to verify whether the simulated output data conforms to the business logic conditions defined by the input parameters. Business logic rules can be automatically generated by a preset semantic analysis model and obtained through user confirmation. They are used to indicate that specific fields in the simulated output data should satisfy preset logical constraints with specific fields in the historical input parameters.

[0122] The server can check each data entry in the simulated output data one by one according to the business logic rules to determine whether it meets the logical constraints defined in the business logic rules, thereby realizing the verification operation of the simulated output data. If it meets the requirements, the verification passes; otherwise, the data entry is removed from the simulated output data.

[0123] It should also be noted that the preset configuration file format can be a data file format that the front-end development server can recognize, such as JSON, JavaScript module format, XML format, or YAML format, etc. This embodiment does not limit this.

[0124] In the specific implementation, the server obtains business logic rules, which can be used to limit the "business generation time" in the simulated output data to be between the "business start time" and "business end time" in the historical input parameters. The server iterates through each data entry in the simulated output data, reads the "business generation time" field value of the data entry, and compares it with the "business start time" and "business end time" field values ​​in the historical input parameters. If the "business generation time" is between the "business start time" and "business end time," the verification passes, and the data entry is retained; otherwise, the data entry is removed from the simulated output data.

[0125] After verification, the server will assemble the verified simulated output data with the request path and historical input parameters of the target interface in a format such as JSON to generate the target MOCK configuration file.

[0126] For example, if the historical input parameters include a start time "2026-01-01" and an end time "2026-01-31", and the simulated output data contains three data entries with business generation times of "2026-01-05", "2026-01-20", and "2026-02-01", the server will validate the three data entries according to the business logic rules. "2026-02-01" will not be between the start and end times, so it will fail the validation and be removed; the other two will pass the validation. The server can then assemble the two validated data entries with the request path " / api / queryTrade" and the historical input parameters "start time = 2026-01-01, end time = 2026-01-31" in JSON format to generate the target MOCK configuration file.

[0127] This embodiment can automatically collect historical response data from each interface through a data acquisition component integrated in the front-end development server, and encrypt and store it in the interface database. This achieves automated collection and centralized management of interface data, replacing the traditional method of developers manually triggering interface requests and copying response data one by one, thus improving data collection efficiency and data security. At the same time, when generating the MOCK configuration file, historical output data is processed through desensitization rules, filtering rules, and timeliness rules, and the processed simulated output data is further verified through business logic rules. This ensures that the simulated data in the MOCK configuration file meets security and timeliness requirements while also conforming to the business logic constraints of the target interface, thereby improving the accuracy and usability of the MOCK configuration file.

[0128] Furthermore, you can also refer to this section. Figure 4 and Figure 5 This paper describes the entire process of the MOCK testing method in this application. Figure 4 This is a schematic diagram of the system architecture of the MOCK testing method in this application. Figure 5 This is a schematic diagram of the entire MOCK testing method of this application.

[0129] Depend on Figure 4 As can be seen, the system architecture of the MOCK testing method in this application involves three core nodes: a front-end development server, a MOCK test data preparation server, and an operation and maintenance management system. In actual deployment, the interface database can be deployed independently or integrated into the MOCK test data preparation server. Figure 4 It is presented in the form of independent modules to facilitate the distinction of functional boundaries.

[0130] The front-end development server can deploy front-end pages and data collection components (i.e., response interceptors). The data collection components are used to automatically capture the request path, input parameters and output response data of each interface when the interface request is completed, and send the collected data to the interface database for storage as historical response data of different interfaces.

[0131] The MOCK test data preparation server includes an operations and maintenance management interface, a rules engine module, an AI intelligent analysis layer, and a MOCK configuration file generation module. The operations and maintenance management interface displays the list of collected interfaces and their corresponding historical response data stored in the interface database. It also provides rule configuration templates for users to configure de-identification rules, filtering rules, and time-sensitivity rules. Additionally, it provides an AI rule confirmation interface for users to review and confirm the business logic rules generated by the AI ​​intelligent analysis layer. The rules engine module includes de-identification rules, filtering rules, time-sensitivity rules, and business logic rules. The AI ​​intelligent analysis layer deploys a pre-defined semantic analysis model to receive input parameters and output data from historical response data, output the business logic relationships between fields, and generate business logic rules. The MOCK configuration file generation module generates a target MOCK configuration file based on the target configuration rules and the target interface's historical response data, and sends it to the front-end development server for MOCK testing.

[0132] Depend on Figure 5 As can be seen, the entire process of this application method may include a data collection stage, a rule configuration stage, and a MOCK configuration file generation and usage stage.

[0133] During the data collection phase, the front-end page initiates an interface request, triggering the front-end framework's response interception mechanism. The data collection component (i.e., the response interceptor) automatically obtains the request path, input parameters, and output response data of different interfaces, and encrypts and stores the above data in the interface database.

[0134] During the rule configuration phase, the operation and maintenance management interface can display the collected data from each interface in real time. Users can configure de-identification rules, filtering rules, and time-sensitivity rules through the operation and maintenance management interface. At the same time, the preset semantic analysis model in the AI ​​intelligent analysis layer generates business logic rules based on historical response data in the interface database, which take effect after user confirmation.

[0135] During the MOCK configuration file generation and usage phase, the MOCK test data preparation server can generate the target MOCK configuration file based on the target configuration rules (including desensitization rules, filtering rules, timeliness rules, and business logic rules) and the historical response data of the target interface in the interface database. The target MOCK configuration file is then sent to the front-end development server. When testing the target interface, the front-end development server can directly call the MOCK configuration file to return simulated response data and complete the MOCK test.

[0136] Based on the aforementioned system architecture and methodology, this application automates the entire process from data collection and rule configuration to MOCK configuration file generation. The data collection component automatically captures the request paths, input parameters, and output response data of each interface and stores them encrypted in the interface database, replacing manual collection methods. Users can configure desensitization, filtering, and time-sensitive rules through the operation and maintenance management interface without writing code, reducing operational difficulty. Simultaneously, a pre-set semantic analysis model automatically identifies semantic relationships between input and output fields and generates business logic rules, reducing manual coding. Finally, the MOCK test data preparation server automatically generates and distributes MOCK configuration files to the front-end development server for use based on the target configuration rules and historical response data of the target interface in the interface database, thereby improving the overall efficiency of MOCK testing.

[0137] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the MOCK testing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0138] In addition, this application also provides a MOCK testing device, such as Figure 6 As shown, Figure 6 This is a schematic diagram of the modular structure of the MOCK testing device in this application. Figure 6 It is known that the device includes: The interactive configuration module 601 is used to respond to the rule configuration operation triggered by the user in the operation and maintenance management interface and obtain the target configuration rule for the target interface. The configuration application module 602 is used to generate a target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database. The interface database stores historical response data of different interfaces collected in advance by the response interceptor. The interface testing module 603 is used to send the target MOCK configuration file to the front-end development server, so that the front-end development server returns simulated response data according to the target MOCK configuration file when testing the target interface.

[0139] This embodiment obtains the target configuration rules for the target interface in response to the rule configuration operation triggered by the user in the operation and maintenance management interface, and automatically generates the target MOCK configuration file based on the pre-collected historical response data stored in the interface database. The user only needs to complete the rule configuration in the interface to obtain a usable MOCK configuration file, without the need to manually write data processing logic code. At the same time, generating the MOCK configuration file based on the pre-collected historical response data of the response interceptor can avoid developers manually triggering interface requests and copying response data one by one, simplifying the MOCK data preparation process and improving the efficiency of front-end MOCK testing.

[0140] This application also provides a MOCK testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the MOCK testing method in Embodiment 1 above.

[0141] The following is for reference. Figure 7 , Figure 7 This is a schematic diagram of the MOCK testing device of this application. The MOCK testing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), and fixed terminals such as digital TVs and desktop computers. Figure 7 The MOCK testing equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0142] like Figure 7As shown, the MOCK testing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the MOCK testing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the MOCK test equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows MOCK test equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0143] The MOCK testing device provided in this application, employing the MOCK testing method described in the above embodiments, can solve the technical problems of the MOCK testing method. Compared with the prior art, the beneficial effects of the MOCK testing device provided in this application are the same as those of the MOCK testing method provided in the above embodiments, and other technical features of the MOCK testing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0144] This application also provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the MOCK test method in the above embodiments.

[0145] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0146] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described MOCK testing method, thereby solving the technical problems of the MOCK testing method. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the MOCK testing method provided in the above embodiments, and will not be repeated here.

[0147] 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 elements in the process, method, article, or system that includes that element.

[0148] The above embodiment numbers are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. They are only some embodiments of this application and do not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A MOCK testing method, characterized in that, The method includes: In response to the rule configuration operation triggered by the user in the operation and maintenance management interface, obtain the target configuration rule for the target interface; Based on the target configuration rules and the historical response data of the target interface in the interface database, a target MOCK configuration file is generated. The interface database stores historical response data of different interfaces collected in advance by the response interceptor. The target MOCK configuration file is sent to the front-end development server so that the front-end development server returns simulated response data based on the target MOCK configuration file when testing the target interface.

2. The method as described in claim 1, characterized in that, The step of obtaining the target configuration rule for the target interface in response to the rule configuration operation triggered by the user in the operation and maintenance management interface includes: In response to the user's request to view interface data in the operation and maintenance management interface, display a list of collected interfaces; When the user selects a target interface based on the list of collected interfaces, a rule configuration template is displayed to the user. The rule configuration template includes fields to be filled in and fields to be selected. Based on the user's actions in filling out the fields to be filled and the user's actions in selecting the fields to be selected, the target configuration rules for the target interface are obtained.

3. The method as described in claim 2, characterized in that, The step of obtaining the target configuration rule for the target interface based on the user's input operation on the field to be filled and the user's selection operation on the field to be selected includes: Based on the user's actions in filling out the fields to be filled and the user's actions in selecting the fields to be selected, a first configuration rule is obtained; Obtain historical response data of the target interface, the historical response data including historical input parameters and historical output data; The historical input parameters and the historical output data are input into a preset semantic analysis model, the business logic relationship is output through the preset semantic analysis model, and a second configuration rule is generated based on the business logic relationship. The first configuration rule and the second configuration rule are determined as the target configuration rules for the target interface.

4. The method as described in claim 3, characterized in that, The first configuration rule includes: de-identification rule, filtering rule, and time-limited rule; the step of obtaining the first configuration rule based on the user's input operation on the field to be filled and the user's selection operation on the field to be selected includes: Based on the user's input operation on the field to be filled, determine the filter condition parameters set by the user and the dynamic generation parameters of the time field set by the user; and based on the user's selection operation on the field to be selected, determine the de-identified field and de-identification method selected by the user. The desensitization rule is generated based on the desensitization field and the desensitization method; the filtering rule is generated based on the filtering condition parameters; and the timeliness rule is generated based on the time field dynamically generated parameters.

5. The method as described in claim 3, characterized in that, The steps of inputting the historical input parameters and the historical output data into a preset semantic analysis model, outputting business logic relationships through the preset semantic analysis model, and generating a second configuration rule based on the business logic relationships include: The historical input parameters and the historical output data are input into a preset semantic analysis model; The preset semantic analysis model identifies the business start time field contained in the historical input parameters and the business end time field contained in the historical output data, and generates business logic rules to limit the business generation time between the business start time and the business end time. The business logic rule is displayed to the user, and upon receiving confirmation from the user regarding the business logic rule, the business logic rule is identified as the second configuration rule.

6. The method as described in claim 1, characterized in that, Before the step of generating the target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database, the method further includes: The data acquisition component is a response interceptor integrated into the front-end development server to collect historical response data of different interfaces obtained from the interface requests by the front-end development server. The historical response data is encrypted, and the encrypted historical response data is stored in the interface database according to the correspondence with each of the interfaces.

7. The method as described in claim 6, characterized in that, The target configuration rules include de-identification rules, filtering rules, timeliness rules, and business logic rules; the step of generating the target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database includes: Read the historical response data of the target interface from the interface database. The historical response data includes the request path, historical input parameters and historical output data of the target interface. According to the desensitization rules, the corresponding fields in the historical output data are desensitized; according to the filtering rules, the data entries in the historical output data are filtered; and according to the timeliness rules, the time field in the historical output data is replaced with a dynamically generated expression to obtain simulated output data. The simulated output data is validated according to the business logic rules, and the validated simulated output data, along with the request path and the historical input parameters, are assembled according to a preset configuration file format to generate a target MOCK configuration file.

8. A MOCK testing device, characterized in that, The device includes: The interactive configuration module is used to respond to the rule configuration operation triggered by the user in the operation and maintenance management interface and obtain the target configuration rule for the target interface. The configuration application module is used to generate a target MOCK configuration file based on the target configuration rules and the historical response data of the target interface in the interface database. The interface database stores historical response data of different interfaces collected in advance by the response interceptor. The interface testing module is used to send the target MOCK configuration file to the front-end development server, so that the front-end development server returns simulated response data based on the target MOCK configuration file when testing the target interface.

9. A MOCK testing device, characterized in that, The device includes: a memory, a processor, and a MOCK test program stored in the memory and executable on the processor, the MOCK test program being configured to implement the steps of the MOCK test method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a MOCK test program, which, when executed by a processor, implements the steps of the MOCK test method as described in any one of claims 1 to 7.

Images