Interface test simulation data generation method and device, storage medium and electronic equipment

Abstract

This invention relates to a method, apparatus, storage medium, and electronic device for generating simulated data for interface testing. The method includes: obtaining metadata corresponding to the interface to be tested from a pre-built intelligent agent based on the interface to be tested; parsing the metadata to obtain interface parameters, the interface parameters including: interface protocol, request parameters, return value structure, and dependencies; parsing the input test requirement information of the interface to be tested to obtain key elements; assigning value ranges to the interface parameters based on the key elements to construct structured test requirements; calling a pre-set interface testing domain knowledge base; configuring a data generation strategy for the structured test requirements based on the interface parameters; and calling a pre-built interface testing domain large model; generating simulated data for testing the interface to be tested based on the structured test requirements and the data generation strategy. This can improve testing efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer and artificial intelligence interdisciplinary technology, and in particular to a method, apparatus, storage medium and electronic device for generating interface test simulation data. Background Technology

[0002] In software testing, interface testing is a crucial step in ensuring the correctness of interactions between different modules. Using mock data to replace the return values ​​of real dependent services can isolate the test environment and improve testing efficiency. Related technologies typically utilize interface mocking tools, such as WireMock, Mockito, and Postman Mock Server, to generate mock data for interface tests. However, these tools have the following drawbacks: (1) Insufficient static data and scenario coverage, resulting in low testing efficiency: Interface Mock tools rely on predefined templates or fixed rules to generate Mock data. For example, the fixed rule set is: return Y when the interface parameter is X. Therefore, the generated Mock data is static data and cannot simulate the dynamic characteristics of real interface calls, such as parameter randomness, return value dependence on context, complex combination of exception branches, and other dynamic characteristics.

[0003] (2) Weak interface protocol and parameter adaptation capability: The current interfaces cover multiple protocols such as RESTful, gRPC, and GraphQL, and the parameter types are diverse, including but not limited to JSON nested objects, binary files, and streaming data. Therefore, interface mock tools need to manually configure the corresponding parsing rules for different protocols, which limits the support for complex parameters (such as JSON bodies containing arrays and conditional judgments), resulting in long test preparation time, high maintenance costs, and low test efficiency.

[0004] (3) Disconnect between static configuration and dynamic feedback: The Mock data generated by the interface Mock tool is fixed once configured and cannot be dynamically adjusted according to the test execution results (such as the interface crashing due to a certain type of Mock data or the performance indicators not meeting the standards). For example, if a batch of Mock data causes the interface response time to exceed the threshold, the template for generating the Mock data needs to be manually modified and retested, which results in low testing efficiency. Summary of the Invention

[0005] In view of this, the present invention provides a method, apparatus, storage medium and electronic device for generating interface test simulation data.

[0006] Specifically, the present invention is achieved through the following technical solution: According to a first aspect of the present invention, a method for generating interface test simulation data is provided, the method comprising: Based on the interface to be tested, the metadata corresponding to the interface to be tested is obtained from the pre-built intelligent agent. The metadata is parsed to obtain the interface parameters, which include: interface protocol, request parameters, return value structure and dependency relationship. The test requirement information of the input interface to be tested is parsed to obtain key elements. Based on the key elements, the interface parameters are assigned values ​​within a range to construct structured test requirements. Call the pre-set interface testing domain knowledge base, and configure a data generation strategy for the structured testing requirements based on the interface parameters; The pre-built interface testing domain model is invoked, and simulated data for testing the interface to be tested is generated based on the structured testing requirements and data generation strategy.

[0007] Optionally, the step of parsing the test requirement information of the interface to be tested, obtaining key elements, assigning value ranges to the interface parameters based on the key elements, and constructing structured test requirements includes: Using natural language processing, the test requirement information of the input interface to be tested is parsed to obtain key elements, which include one or more test scenarios; For each test scenario, the range of interface parameters corresponding to the test scenario is obtained from the test requirement information. Based on the range of interface parameters and the interface parameters, the structured test scenario requirements corresponding to the test scenario are constructed. Based on the structured test scenario requirements corresponding to each test scenario, obtain the structured test requirements.

[0008] Optionally, the step of calling a pre-set interface testing domain knowledge base and configuring a data generation strategy for the structured testing requirements based on the interface parameters includes: Call the protocol parsing rule base in the pre-set interface testing domain knowledge base to obtain the simulated data format corresponding to the interface protocol in the interface parameters in order to generate a protocol adaptation sub-strategy; Based on the range of assigned values ​​and the exception pattern library and boundary value generation strategy library in the interface testing domain knowledge base, a parameter generation sub-strategy for generating random values ​​of request parameters is set. Based on the return value structure of the interface to be tested, a return value generation sub-strategy is set, and a simulated sub-strategy is constructed according to the dependency relationship in the interface parameters.

[0009] Optionally, one test scenario corresponds to one or more sets of simulated data.

[0010] Optionally, the method further includes: The generated simulation data is subjected to syntax and logic checks using a rule engine. For simulation data that fails the checks, it is modified accordingly based on the rule engine. Using a pre-built machine learning model, the abnormal coverage rate of the generated simulated data is statistically analyzed. When the abnormal coverage rate does not meet the coverage requirements in the structured testing requirements, the corresponding abnormal data volume is obtained based on the abnormal coverage rate, coverage requirements, and the amount of generated simulated data. Based on the structured testing requirements, data generation strategy, and abnormal data volume, the interface testing domain large model is invoked to generate simulated data of the abnormal data volume, which is then added to the simulated data used to test the interface to be tested.

[0011] Optionally, the method further includes: It is determined that the anomaly coverage rate is less than the corresponding coverage requirement in the structured test requirements; The parameter generation sub-strategy corresponding to the anomaly pattern library in the interface testing domain knowledge base is updated by using reinforcement learning algorithms, and the generation probability of anomaly scenarios in the large model of the interface testing domain is increased.

[0012] Optionally, the method further includes: The generated mock data is stored in a Mock data warehouse for execution and invocation during the testing of the interface to be tested.

[0013] The interface test mock data generation method in this technical solution obtains the metadata corresponding to the interface to be tested from a pre-built intelligent agent based on the interface to be tested. It then parses the metadata to obtain interface parameters, including the interface protocol, request parameters, return value structure, and dependencies. Next, it parses the input test requirement information of the interface to be tested to obtain key elements. Based on these key elements, it assigns value ranges to the interface parameters to construct structured test requirements. Finally, it calls a pre-set interface test domain knowledge base and configures a data generation strategy for the structured test requirements based on the interface parameters. Finally, it calls a pre-built interface test domain model and generates mock data for testing the interface to be tested based on the structured test requirements and the data generation strategy. This automatic parsing of metadata to construct structured test requirements and allocation of corresponding data generation strategies, along with the batch generation of mock data based on the interface test domain model, effectively improves testing efficiency.

[0014] According to a second aspect of the present invention, an interface test simulation data generation apparatus is provided, the interface test simulation data generation apparatus comprising: The metadata parsing module is used to obtain the metadata corresponding to the interface to be tested from the pre-built intelligent agent based on the interface to be tested, parse the metadata, and obtain the interface parameters. The interface parameters include: interface protocol, request parameters, return value structure and dependency relationship. The structured construction module is used to parse the test requirement information of the input interface to be tested, obtain key elements, assign value ranges to the interface parameters based on the key elements, and construct structured test requirements. The generation strategy acquisition module is used to call a pre-set interface testing domain knowledge base and configure a data generation strategy for the structured testing requirements based on the interface parameters. The simulated data generation module is used to call a pre-built interface testing domain model and generate simulated data for testing the interface to be tested, based on the structured testing requirements and data generation strategy.

[0015] According to a third aspect of the present invention, a storage medium is provided having a computer program stored thereon, wherein when the program is executed by a processor, it implements the steps of the interface test simulation data generation method in any possible implementation of the first aspect.

[0016] According to a fourth aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the interface test simulation data generation method in any possible implementation of the first aspect. Attached Figure Description

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

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

[0019] Figure 1 A flowchart illustrating a method for generating simulated interface test data according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an interface test simulation data generation device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] In related technologies, interface mocking tools, such as WireMock, Mockito, and Postman Mock Server, are used to generate mock test data. However, since the mock data is generated based on predefined templates or fixed rules, and the corresponding parsing rules need to be manually configured for different protocols during the mock data generation process, and the predefined templates or fixed rules cannot be dynamically adjusted according to the test execution results, manual modification is required. This makes the testing efficiency of interface testing based on mock test data low.

[0022] In recent years, Intelligent Agent Large Models (AIMs), such as GPT-4 and Tongyi Qianwen, have demonstrated powerful capabilities in natural language understanding and generation. However, their applications are mostly focused on general text generation or dialogue, and have not yet been applied to the vertical scenario of generating mock data for interface testing. This embodiment addresses the problems of insufficient data staticity, weak scenario adaptability, insufficient anomaly coverage, and lack of dynamic optimization in mock data generated by interface mocking tools. It provides a method for generating interface test mock data based on an AIM-based testing platform. By leveraging the semantic understanding, logical reasoning, and dynamic generation capabilities of AIMs, a collaborative framework of AIM-feedback optimization is constructed. This framework integrates test interface parsing, scenario modeling, mock data generation, and dynamic tuning into a closed-loop process, solving the problems of insufficient staticity, poor scenario adaptability, and insufficient anomaly coverage in interface test mock data. This enables multi-protocol adaptation, dynamic scenario simulation, intelligent anomaly construction, and closed-loop optimization.

[0023] See Figure 1 This invention provides a method for generating simulated interface test data, which may include the following steps: S101. Based on the interface to be tested, obtain the metadata corresponding to the interface to be tested from the pre-built intelligent agent, parse the metadata, and obtain the interface parameters. The interface parameters include: interface protocol, request parameters, return value structure, and dependency relationship. In this embodiment, the pre-built intelligent agent stores the mapping relationship between each test interface and its corresponding metadata. The user inputs information about the interface to be tested, such as the interface name and identifier. Based on this information, the intelligent agent queries the mapping relationship to obtain the metadata corresponding to the interface. As an optional embodiment, the metadata includes, but is not limited to, OpenAPI documentation, Swagger documentation, and Protobuf definition documentation. Interface parameters are obtained by parsing the metadata corresponding to the interface to be tested.

[0024] In this embodiment, the interface parameters include, but are not limited to: interface protocol, request parameters, return value structure, and dependencies. The interface protocol includes, but is not limited to: RESTful protocol, gRPC protocol, and GraphQL protocol. Request parameters include, but are not limited to: path parameters, query parameters, and Body parameter types and constraints. The return value structure includes, but is not limited to: field types, nesting relationships, required identifiers, and optional identifiers. Dependencies include, but are not limited to, cascading dependencies; for example, a cascading dependency could be "User ID → User Information → Order List".

[0025] S102. Parse the test requirement information of the input interface to be tested, obtain key elements, assign value ranges to the interface parameters based on the key elements, and construct structured test requirements. In this embodiment, the test requirement information of the input interface to be tested is parsed to obtain key elements. Based on the key elements, the interface parameters are assigned value ranges to construct structured test requirements, including: A11, using natural language processing, parse the test requirement information of the input interface to be tested, and obtain key elements, the key elements including one or more test scenarios; A12. For each test scenario, obtain the range of interface parameters corresponding to the test scenario from the test requirement information, and construct the structured test scenario requirements corresponding to the test scenario based on the range of interface parameters and the interface parameters. A13, based on the structured test scenario requirements corresponding to each test scenario, obtain the structured test requirements.

[0026] In this embodiment, test requirement information input by the user is received. For example, the test requirement information can be "simulating the return value of the payment interface under the scenario of 'high concurrency + network fluctuation', including 10% of 'payment timeout' exceptions, covering all parameter boundary values". The key elements contained in the user input are extracted through natural language processing (NLP). Among them, there is a test scenario, namely the 'high concurrency + network fluctuation' scenario. The corresponding interface parameter range includes: exception ratio, boundary conditions, protocol type, etc. Among them, the protocol type corresponds to the interface protocol in the interface parameters, the exception ratio corresponds to the request parameters in the interface parameters, and the boundary conditions correspond to the return value structure in the interface parameters. There is no dependency relationship in this test scenario. Structured test requirements are generated based on each test scenario.

[0027] In this embodiment, as an optional implementation, we take the interface test of the "Batch Import Interface for Transfer Details" combined with fund analysis as an example. This batch import interface for transfer details is the interface to be tested, used to batch import transfer detail data from external channels, such as third-party payment institutions and banks, to verify its compatibility and robustness under scenarios involving large data volumes, abnormal formats, and business conflicts. The interface metadata (defined in the Swagger 2.0 document) corresponding to the interface to be tested, i.e., the batch import interface for transfer details (RESTful POST / api / bank / transfer-details / import), is parsed to obtain: Request parameters include: Header: Authorization: Bearer {token} (authentication token), Content-Type: multipart / form-data (file upload format); Body parameter: file field (required, type .csv or .xlsx, size ≤100MB, encoding UTF-8). The file must contain a header and detailed data. The header fields are: transactionId (transaction ID, unique), fromAccount (transfer account, 19-digit bank card number), toAccount (transfer account, 19-digit bank card number), amount (amount, positive number, unit: cents), currency (currency, CNY / USD), transTime (transaction time, format: yyyy-MM-dd HH:mm:ss), remark (remark, optional, length ≤200 characters).

[0028] Return value: {"code": integer, "data": {"successCount": integer, "failCount": integer, "failDetails": [{"rowNum": integer, "reason": string}]},"message": string}, where failDetails is the row number and reason for the import failure (such as "duplicate transaction ID" or "incorrect amount format").

[0029] Dependencies: fromAccount / toAccount must be associated with a legitimate account in the "bank's core system" (verified by calling the "account validity verification interface"); transTime must be within the time range allowed by the bank's system (e.g., within the last 30 days).

[0030] In this embodiment, as an optional embodiment, the user inputs on the test platform interface of the intelligent agent: "Simulate a scenario of large data volume (100,000 records / file), abnormal format (missing CSV header, negative amount, incorrect time format), and business conflict (duplicate transaction ID, insufficient balance in the transferring account) of the transfer detail import interface, generate a mock CSV / XLSX file and corresponding return value, including 20% ​​of 'import failure' exceptions, covering all missing / error cases of header fields."

[0031] Requirement analysis involves extracting key elements from user input using an NLP model, resulting in: Protocol = RESTful (multipart / form-data file upload), Data type = CSV / XLSX file + JSON return value; Anomaly rate = 20% of imports failed; Scenario constraints (boundary conditions) = large data volume (100,000 records), format anomalies (missing header / negative amount / incorrect time), business conflicts (duplicate transaction ID / insufficient balance); Coverage requirement (return value structure) = missing / error cases of all header fields (transactionId / fromAccount / toAccount / amount / currency / transTime / remark).

[0032] In this embodiment, structured test requirements are generated by parsing the metadata of the interface to be tested (protocol type, parameter structure, return value definition (return value structure), and dependencies) and the test requirements (scenario, exception ratio, and boundary conditions) input by the user.

[0033] S103. Call the pre-set interface testing domain knowledge base, and configure a data generation strategy for the structured testing requirements based on the interface parameters; In this embodiment, an agent is invoked to configure a data generation strategy for the structured testing requirements (tasks) based on interface metadata and structured testing needs, using a pre-built interface testing domain knowledge base. As an optional embodiment, the interface testing domain knowledge base includes, but is not limited to, a protocol parsing rule base, an exception pattern base, and a boundary value generation strategy base.

[0034] In this embodiment, as an optional implementation, a pre-set interface testing domain knowledge base is invoked, and a data generation strategy is configured for the structured testing requirements based on the interface parameters, including: A21, call the protocol parsing rule base in the pre-set interface testing domain knowledge base, obtain the simulated data format corresponding to the interface protocol in the interface parameters to generate a protocol adaptation sub-strategy; A22, based on the range of values ​​assigned and the exception pattern library and boundary value generation strategy library in the interface testing domain knowledge base, set a parameter generation sub-strategy to generate random values ​​for request parameters; A23. Based on the return value structure of the interface to be tested, set a return value generation sub-strategy and construct a simulated sub-strategy according to the dependency relationship in the interface parameters.

[0035] In this embodiment, as an optional embodiment, the data generation strategy includes, but is not limited to: protocol adaptation sub-strategy, parameter generation sub-strategy, return value generation sub-strategy, and scenario simulation sub-strategy, wherein, Protocol adaptation sub-strategy: Configured to generate corresponding Mock data format (such as Protobuf binary data) according to the interface protocol (such as gRPC protocol); Parameter generation sub-strategy: Generate random values ​​that meet the constraints for request parameters. For example, the user ID must be in UUID format and the amount must be an integer between 1 and 10,000 yuan. Return value generation sub-strategy: Configured to generate normal / abnormal return values ​​based on the interface return value structure. For example, return the order number + amount when payment is successful, and return the error code + timeout reason when payment times out. Scenario simulation sub-strategy: Configured to construct a dependency scenario, for example, the constructed dependency scenario is: simulate an upstream service returning user information with a delay of 500ms.

[0036] In this embodiment, for each test scenario corresponding to the structured test scenario requirement in the structured test requirements, a corresponding data generation strategy is assigned to each test scenario. As an optional embodiment, for request parameters, the configured parameter generation sub-strategy can be to use "boundary value analysis method + random perturbation". For abnormal return values ​​in the return value structure, the assigned return value generation sub-strategy can be to use the timeout / error code combination strategy in the "fault injection pattern library".

[0037] In this embodiment, the interface to be tested is a financial interface. example, The system calls upon a knowledge base in the financial interface testing domain, which includes bank transfer rules, file format specifications, and an exception pattern library, to break down structured testing requirements into multiple atomic subtasks (test scenarios) and assign a data generation strategy to each atomic subtask.

[0038] S104. Call the pre-built interface testing domain model, and generate simulated data for testing the interface to be tested based on the structured testing requirements and data generation strategy.

[0039] In this embodiment, as an optional embodiment, the interface testing domain model can be a model obtained by fine-tuning the existing domain model containing each test interface using the interface to be tested. For example, the interface testing domain model can be an LLaMA-3-Multimodal model that supports multiple protocols.

[0040] In this embodiment, as an optional embodiment, the generated Mock data includes: Protocol adaptation data: Generate data in the corresponding format according to the interface protocol, such as JSON body data of RESTful interface, Protobuf serialized data of gRPC interface, and query response data of GraphQL interface; Dynamic parameter data: Generate request parameters that conform to constraints, for example, nested JSON Body: {"user":{"id":"uuid-xxx","age":25},"items":[{"id":123,"count":2}]}). Intelligent return value: Generates normal and abnormal return values. A normal return value can be, for example, {"code":200,"data":{"orderId":"OD123","amount":500}}). An abnormal return value can be, for example, {"code":504,"error":"Payment gateway timeout","retryable":true}). Scenario-dependent data: Generate upstream and downstream dependency data (e.g., when simulating "user information service returns null value", the Mock return value of the payment interface needs to handle null pointer exception).

[0041] In this embodiment, the large-scale model in the interface testing domain captures the dependencies between parameters through an attention mechanism, such as "when user level = VIP, discount field = 0.8", and the return value logic, such as "when amount > 1000, installment payment option should be returned", ensuring data logic consistency. Thus, by utilizing the Claude 3 model fine-tuned for financial interface testing, one or more sets of mock data can be generated for each test scenario based on structured testing requirements and data generation strategies.

[0042] In this embodiment, as an optional implementation, since the Mock data generated based on the large model in the interface testing domain contains data that does not conform to the test format, the method may further include: The generated simulation data is subjected to syntax and logic checks using a rule engine. For simulation data that fails the checks, it is modified accordingly based on the rule engine. Using a pre-built machine learning model, the abnormal coverage rate of the generated simulated data is statistically analyzed. When the abnormal coverage rate does not meet the coverage requirements in the structured testing requirements, the corresponding abnormal data volume is obtained based on the abnormal coverage rate, coverage requirements, and the amount of generated simulated data. Based on the structured testing requirements, data generation strategy, and abnormal data volume, the interface testing domain large model is invoked to generate simulated data of the abnormal data volume, which is then added to the simulated data used to test the interface to be tested.

[0043] In this embodiment, the simulated data undergoes quality verification: the data format is verified through a rule engine, including but not limited to: JSON syntax correctness, Protobuf field matching, and business logic verification. JSON syntax correctness includes, but is not limited to: the orderId format in the return value conforms to the specification. Protobuf field matching includes, but is not limited to: exception codes matching the scenario. For example, it checks whether the header fields of CSV / XLSX tables are consistent with Swagger (e.g., whether fromAccount is missing), whether the file size is ≤100MB, and whether the encoding is UTF-8; it also verifies whether the return value format conforms to the structure {"code":integer,"data":{...}}.

[0044] In this embodiment, anomaly coverage is calculated using a machine learning (ML) classifier trained on historical test data. For example, if the coverage requirement is a payment timeout anomaly rate of 10%, and the anomaly coverage rate based on the ML model is 8%, then the proportion of payment timeout anomalies in the simulated data needs to be increased. Another example is boundary value coverage, which checks whether the monetary parameter covers values ​​such as 0, 1, 10000, and 10001. As an optional embodiment, the anomaly coverage rate includes: Import failure rate = 18% (lower than the target of 20%), mainly because the error was not triggered in the "excessively long notes" scenario (it should have returned "note length exceeds 200 characters"). Header field coverage: The "Excessive length error" in the remark field is not covered, while the "Invalid currency JPY" in the currency field is covered but the return value is incorrect because "currency is not supported" (as expected).

[0045] In this embodiment, as another optional embodiment, the method may further include: It is determined that the anomaly coverage rate is less than the corresponding coverage requirement in the structured test requirements; The parameter generation sub-strategy corresponding to the anomaly pattern library in the interface testing domain knowledge base is updated by using reinforcement learning algorithms, and the generation probability of anomaly scenarios in the large model of the interface testing domain is increased.

[0046] In this embodiment, the quality of mock data is verified through a rule engine and an ML classifier, including format compliance, anomaly coverage, and boundary value coverage. If the quality does not meet the standards, the generation strategy of the agent is updated through reinforcement learning, and the model parameters of the large model in the interface testing domain are fine-tuned. The mock data is then regenerated until the standards are met. For example, if the quality verification fails and the anomaly coverage is only 8%, the task planning strategy of the agent is updated through reinforcement learning (such as increasing the generation weight of the "payment timeout anomaly" subtask), and the LoRA adapter of the large model is fine-tuned (to enhance the generation probability of anomaly scenarios). The mock data is then regenerated until the standards are met, and finally, the mock data is stored in a mock data warehouse for test execution.

[0047] The interface test simulation data generation method of this embodiment obtains the metadata corresponding to the interface to be tested from a pre-built intelligent agent based on the interface to be tested, parses the metadata to obtain interface parameters, including interface protocol, request parameters, return value structure, and dependencies; parses the input test requirement information of the interface to be tested to obtain key elements, assigns value ranges to the interface parameters based on the key elements, and constructs structured test requirements; calls a pre-set interface test domain knowledge base, configures a data generation strategy for the structured test requirements based on the interface parameters; and calls a pre-built interface test domain large model, according to the structured test requirements and the data generation strategy, generates simulation data for testing the interface to be tested. It has the following beneficial effects: (1) Improve the authenticity and scenario coverage of Mock data: The large model learns the parameter distribution and return value logic of real interface calls (such as "dynamic association between user level and discount") to generate dynamic Mock data that conforms to the production environment, and the scenario coverage rate is increased from the traditional 30%-50% to more than 90%.

[0048] (2) Reduce the cost of multi-protocol interface testing: The agent automatically parses the interface protocol and allocates the generation strategy, eliminating the need to manually write gRPC Protobuf templates or GraphQL query responses, thus reducing the preparation time for multi-protocol interface testing by more than 70%.

[0049] (3) Enhance the depth of anomaly and boundary testing: By intelligently constructing abnormal data (such as the combination scenario of "null parameter + network timeout"), it can cover the interface vulnerabilities that are difficult to reach by traditional tools, and improve the defect detection rate by 60%-80% (such as exposing unhandled null pointer exceptions in advance).

[0050] Based on the same inventive concept, such as Figure 2 As shown, this embodiment of the invention also provides an interface test simulation data generation device, the device comprising: Metadata parsing module 201 is used to obtain the metadata corresponding to the interface to be tested from the pre-built intelligent agent based on the interface to be tested, parse the metadata, and obtain the interface parameters. The interface parameters include: interface protocol, request parameters, return value structure and dependency relationship. In this embodiment, as an optional implementation, metadata includes, but is not limited to: OpenAPI documentation, Swagger documentation, and Protobuf definition documentation. Interface parameters include, but are not limited to: interface protocol, request parameters, return value structure, and dependencies.

[0051] The structured construction module 202 is used to parse the test requirement information of the input interface to be tested, obtain key elements, assign value ranges to the interface parameters based on the key elements, and construct structured test requirements. In this embodiment, as an optional implementation, the structured construction module 202 is specifically used for: Using natural language processing, the test requirement information of the input interface to be tested is parsed to obtain key elements, which include one or more test scenarios; For each test scenario, the range of interface parameters corresponding to the test scenario is obtained from the test requirement information. Based on the range of interface parameters and the interface parameters, the structured test scenario requirements corresponding to the test scenario are constructed. Based on the structured test scenario requirements corresponding to each test scenario, obtain the structured test requirements.

[0052] The generation strategy acquisition module 203 is used to call a pre-set interface testing domain knowledge base and configure a data generation strategy for the structured testing requirements based on the interface parameters. In this embodiment, as an optional embodiment, the generation strategy acquisition module 203 is specifically used for: Call the protocol parsing rule base in the pre-set interface testing domain knowledge base to obtain the simulated data format corresponding to the interface protocol in the interface parameters in order to generate a protocol adaptation sub-strategy; Based on the range of assigned values ​​and the exception pattern library and boundary value generation strategy library in the interface testing domain knowledge base, a parameter generation sub-strategy for generating random values ​​of request parameters is set. Based on the return value structure of the interface to be tested, a return value generation sub-strategy is set, and a simulated sub-strategy is constructed according to the dependency relationship in the interface parameters.

[0053] The simulation data generation module 204 is used to call a pre-built interface testing domain model and generate simulation data for testing the interface to be tested based on the structured testing requirements and data generation strategy.

[0054] In this embodiment, as an optional embodiment, one test scenario corresponds to one or more sets of simulation data.

[0055] In this embodiment, as an optional embodiment, the device further includes: The quality verification module (not shown in the figure) is used to perform syntax and logic verification on the generated simulation data using the rule engine. For simulation data that fails the verification, it is modified accordingly based on the rule engine. Using a pre-built machine learning model, the abnormal coverage rate of the generated simulated data is statistically analyzed. When the abnormal coverage rate does not meet the coverage requirements in the structured testing requirements, the corresponding abnormal data volume is obtained based on the abnormal coverage rate, coverage requirements, and the amount of generated simulated data. Based on the structured testing requirements, data generation strategy, and abnormal data volume, the interface testing domain large model is invoked to generate simulated data of the abnormal data volume, which is then added to the simulated data used to test the interface to be tested.

[0056] In this embodiment, as another optional embodiment, the device further includes: The model update module is used to determine that the anomaly coverage rate is less than the corresponding coverage requirement in the structured test requirements; The parameter generation sub-strategy corresponding to the anomaly pattern library in the interface testing domain knowledge base is updated by using reinforcement learning algorithms, and the generation probability of anomaly scenarios in the large model of the interface testing domain is increased.

[0057] In this embodiment, as another optional embodiment, the device further includes: The data storage module is used to store the generated simulated data in a Mock data warehouse for execution and invocation during the testing of the interface to be tested.

[0058] Based on the same inventive concept, embodiments of the present invention also provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the interface test simulation data generation method in any of the above possible implementations.

[0059] Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0060] Based on the same inventive concept, see [link to inventive concept] Figure 3 This invention also provides an electronic device, including a memory 101 (e.g., non-volatile memory), a processor 102, and a computer program stored on the memory 101 and executable on the processor 102. When the processor 102 executes the program, it implements the steps of the interface test simulation data generation method in any of the above possible implementations, which is equivalent to the interface test simulation data generation device described above. Of course, the processor can also be used to process other data or perform calculations. This electronic device can be a PC, server, terminal, or other similar device.

[0061] like Figure 3As shown, the electronic device may also include: memory 103, network interface 104, and internal bus 105. In addition to these components, other hardware may also be included, which will not be described in detail here.

[0062] It should be noted that the aforementioned interface test simulation data generation device can be implemented by software. As a logical device, it is formed by the processor 102 of the electronic device in which it is located reading the computer program instructions stored in the non-volatile memory into the memory 103 for execution.

[0063] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0064] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by special-purpose logic circuitry—such as FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit), and the device can also be implemented as special-purpose logic circuitry.

[0065] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0066] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0067] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily used to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0068] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0069] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. 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 apparatus that includes the element.

[0071] The above are merely specific embodiments of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for generating simulated interface test data, characterized in that, include: Based on the interface to be tested, the metadata corresponding to the interface to be tested is obtained from the pre-built intelligent agent. The metadata is parsed to obtain the interface parameters, which include: interface protocol, request parameters, return value structure and dependency relationship. The test requirement information of the input interface to be tested is parsed to obtain key elements. Based on the key elements, the interface parameters are assigned values ​​within a range to construct structured test requirements. Call the pre-set interface testing domain knowledge base, and configure a data generation strategy for the structured testing requirements based on the interface parameters; The pre-built interface testing domain model is invoked, and simulated data for testing the interface to be tested is generated based on the structured testing requirements and data generation strategy.

2. The interface test simulation data generation method according to claim 1, characterized in that, The test requirement information of the interface to be tested is parsed, key elements are obtained, and value ranges are assigned to the interface parameters based on the key elements to construct structured test requirements, including: Using natural language processing, the test requirement information of the input interface to be tested is parsed to obtain key elements, which include one or more test scenarios; For each test scenario, the range of interface parameters corresponding to the test scenario is obtained from the test requirement information. Based on the range of interface parameters and the interface parameters, the structured test scenario requirements corresponding to the test scenario are constructed. Based on the structured test scenario requirements corresponding to each test scenario, obtain the structured test requirements.

3. The interface test simulation data generation method according to claim 1, characterized in that, The step of calling a pre-set interface testing domain knowledge base and configuring a data generation strategy for the structured testing requirements based on the interface parameters includes: Call the protocol parsing rule base in the pre-set interface testing domain knowledge base to obtain the simulated data format corresponding to the interface protocol in the interface parameters in order to generate a protocol adaptation sub-strategy; Based on the range of assigned values ​​and the exception pattern library and boundary value generation strategy library in the interface testing domain knowledge base, a parameter generation sub-strategy for generating random values ​​of request parameters is set. Based on the return value structure of the interface to be tested, a return value generation sub-strategy is set, and a simulated sub-strategy is constructed according to the dependency relationship in the interface parameters.

4. The interface test simulation data generation method according to claim 2, characterized in that, Each test scenario corresponds to one or more sets of simulated data.

5. The interface test simulation data generation method according to any one of claims 1 to 4, characterized in that, The method further includes: The generated simulation data is subjected to syntax and logic checks using a rule engine. For simulation data that fails the checks, it is modified accordingly based on the rule engine. Using a pre-built machine learning model, the abnormal coverage rate of the generated simulated data is statistically analyzed. When the abnormal coverage rate does not meet the coverage requirements in the structured testing requirements, the corresponding abnormal data volume is obtained based on the abnormal coverage rate, coverage requirements, and the amount of generated simulated data. Based on the structured testing requirements, data generation strategy, and abnormal data volume, the interface testing domain large model is invoked to generate simulated data of the abnormal data volume, which is then added to the simulated data used to test the interface to be tested.

6. The interface test simulation data generation method according to claim 5, characterized in that, The method further includes: It is determined that the anomaly coverage rate is less than the corresponding coverage requirement in the structured test requirements; The parameter generation sub-strategy corresponding to the anomaly pattern library in the interface testing domain knowledge base is updated by using reinforcement learning algorithms, and the generation probability of anomaly scenarios in the large model of the interface testing domain is increased.

7. The interface test simulation data generation method according to any one of claims 1 to 4, characterized in that, The method further includes: The generated mock data is stored in a Mock data warehouse for execution and invocation during the testing of the interface to be tested.

8. An interface test simulation data generation device, characterized in that, The interface test simulation data generation device includes: The metadata parsing module is used to obtain the metadata corresponding to the interface to be tested from the pre-built intelligent agent based on the interface to be tested, parse the metadata, and obtain the interface parameters. The interface parameters include: interface protocol, request parameters, return value structure and dependency relationship. The structured construction module is used to parse the test requirement information of the input interface to be tested, obtain key elements, assign value ranges to the interface parameters based on the key elements, and construct structured test requirements. The generation strategy acquisition module is used to call a pre-set interface testing domain knowledge base and configure a data generation strategy for the structured testing requirements based on the interface parameters. The simulated data generation module is used to call a pre-built interface testing domain model and generate simulated data for testing the interface to be tested, based on the structured testing requirements and data generation strategy.

9. A storage medium, characterized in that, The program or instructions are stored on the storage medium, and the program or instructions are executed by the processor to implement the steps of the interface test simulation data generation method as described in any one of claims 1 to 7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the interface test simulation data generation method according to any one of claims 1 to 7.

Images