Interface contract graph-based cross-interface consistency test data synthesis method and system, computer device and storage medium

Abstract

The embodiment of the application relates to the computer field, and provides an interface contract graph-based cross-interface consistency test data synthesis method, system, computer device and storage medium, the method comprises the following steps: firstly, formalization processing is carried out on input and output constraint information of each interface obtained by automatically extracting from a preset data source; then, interface contract construction processing is carried out to obtain a directed weighted interface contract graph; then, forward constraint propagation and reverse constraint propagation are executed; then, loop dependence breaking processing is carried out on strong connected components detected in the graph; then, the processed data is compiled into a satisfiability modulo theory formula; then, a satisfiability modulo theory solver is called to solve the formula; finally, the solved data is assembled and output in a format selected by a user, and a complete test data set is obtained. The embodiment of the method improves the synthesis efficiency and quality of test data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, computer device, and storage medium for synthesizing cross-interface consistency test data based on interface contract graphs. Background Technology

[0002] In modern microservice architectures and enterprise-level distributed systems, ensuring data consistency between application programming interfaces (APIs) is one of the core challenges in the testing field. A typical business process often spans multiple API interfaces across multiple microservices, each with complex input constraints and output contracts.

[0003] Traditional test data preparation methods require testers to manually construct API test data, meticulously consulting API documentation to understand the meaning and constraints of each parameter, and then relying on experience and intuition to construct the request body. Constructing a moderately complex API test case typically takes 15 to 30 minutes. Manual methods tend to use the most readily conceived combinations of normal values, making it difficult to systematically cover boundary values, outliers, and combined boundary scenarios. Furthermore, API test data is often constructed independently, and the output data format of upstream APIs may not match the expected input format of downstream APIs, leading to test failures due to data inconsistency rather than actual functional defects.

[0004] In summary, the traditional process of synthesizing cross-interface consistency test data suffers from low data synthesis efficiency and poor data quality. Summary of the Invention

[0005] This application provides a method, system, computer device, and storage medium for synthesizing cross-interface consistency test data based on interface contract graphs. More specifically, this application provides a method, system, computer device, computer storage medium, and computer program product for synthesizing cross-interface consistency test data based on interface contract graphs, thereby improving the efficiency and quality of test data synthesis.

[0006] In a first aspect, embodiments of this application provide a method for synthesizing cross-interface consistency test data based on an interface contract graph, including: The input and output constraint information of each interface is automatically extracted from the preset data source, and the input and output constraint information is formalized to obtain a unified contract tuple representation data. Based on the unified contract tuple representation data, interface contract construction processing is performed to obtain a directed weighted interface contract graph. Receive the test scenario seed value specified by the user, and perform forward constraint propagation along the directed edge direction of the directed weighted interface contract graph according to the test scenario seed value to obtain the data after forward constraint propagation; In response to the user-specified output-side target constraint, reverse constraint propagation is performed from the output-side target constraint along the opposite direction of the directed edge based on the forward constraint propagation data, to obtain the reverse constraint propagation data; The strongly connected components detected in the graph corresponding to the data after the reverse constraint propagation are subjected to cycle dependency breaking processing to determine the bidirectional propagation data after the breaking process. The propagation constraints corresponding to the bidirectional propagation data are compiled into satisfiability modulus theory formulas, and the satisfiability modulus theory solver is called to solve the satisfiability modulus theory formulas to obtain the solved data. The solved data is assembled and output according to the user-selected format to obtain a complete test dataset.

[0007] Optionally, in some embodiments of this application, the step of performing interface contract construction processing based on the unified contract tuple representation data to obtain a directed weighted interface contract graph includes: The vertex set and directed edge set of the directed weighted interface contract graph are constructed. The coupling weight is calculated based on the data coupling degree score, the frequency weight is determined based on the normalized value of the actual call frequency, and the confidence weight is obtained based on the deterministic score of the preset data source. The edge weight data of the directed weighted interface contract graph is obtained by weighted summation based on the coupling weight, the frequency weight, and the confidence weight. Based on the vertex set, the directed edge set, and the edge weight data, the directed weighted interface contract graph is constructed.

[0008] Optionally, in some embodiments of this application, the step of performing cycle dependency breaking processing on the strongly connected components detected in the graph corresponding to the data after reverse constraint propagation, and determining the bidirectional propagation data after the breaking, includes: The strongly connected components in the graph corresponding to the data after the reverse constraint propagation are identified using a time-complexity algorithm. Select the edge with the smallest edge weight in the strongly connected component as the virtual broken edge to perform the cycle breaking process, and obtain the directed acyclic graph after the cycle breaking process. A bidirectional constraint propagation is performed on the directed acyclic graph after the cycle disruption process, and a posterior compatibility check is performed on both ends of the broken edge of the directed acyclic graph after the cycle disruption process to determine the data after bidirectional propagation.

[0009] Optionally, in some embodiments of this application, the step of compiling the propagated constraints corresponding to the bidirectional propagated data into satisfiability modulus theory formulas, and calling a satisfiability modulus theory solver to solve the satisfiability modulus theory formulas to obtain the solved data includes: Deserialize the satisfactory results to obtain the request or response test data of each interface, and apply the boundary detection strategy to automatically generate variant data families covering boundary values ​​and outliers based on each normal data. Output a minimum conflict subset report for unsatisfiable results; The solved data is determined based on the variant data family and the minimal conflict subset report.

[0010] Optionally, in some embodiments of this application, the step of compiling the propagated constraints corresponding to the bidirectional propagated data into satisfiability modulus theory formulas, and calling a satisfiability modulus theory solver to solve the satisfiability modulus theory formulas to obtain the solved data includes: A fitting probability distribution model is constructed based on the interface traffic sampling data of the production environment, and the fitting distribution data is output according to the fitting probability distribution model. In the process of solving the satisfiability modulus formula, if specific values ​​need to be generated for the fields, the field values ​​are sampled from the fitted distribution data and projected back to the constraint allowable range. The solved data is obtained by solving the field values ​​projected back to the constraint allowable range.

[0011] Optionally, in some embodiments of this application, before the step of assembling and outputting the solved data in a user-selected format to obtain a complete test dataset, the method further includes: Establish a data lineage record for each field of each synthetic test data corresponding to the solved data; In the event of a conflict arising during the propagation of constraints in the data lineage record representation process, the conflict resolution process is carried out according to the data source priority strategy to obtain the result data of the conflict resolution process.

[0012] Optionally, in some embodiments of this application, the priority order represented in the data source priority strategy, from high to low, is as follows: The test scenario seed value explicitly specified by the user, the sampled fill field value in the fitted distribution data, the satisfiability modulus solution value corresponding to the solved data, the propagation inheritance value, and the default value.

[0013] Secondly, embodiments of this application provide a cross-interface consistency test data synthesis system based on interface contract graphs, which has the function of implementing the cross-interface consistency test data synthesis method based on interface contract graphs provided in the first aspect above. The function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, and the modules can be software and / or hardware.

[0014] In one possible design, the system includes: The interface contract automatic extraction and modeling module is used to automatically extract the input and output constraint information of each interface from a preset data source, perform formal processing on the input and output constraint information, and obtain unified contract tuple representation data. The directed weighted interface contract graph construction module is used to perform interface contract construction processing based on the unified contract tuple representation data to obtain a directed weighted interface contract graph. The forward constraint propagation module is used to receive the test scenario seed value specified by the user, and perform forward constraint propagation along the directed edge direction of the directed weighted interface contract graph according to the test scenario seed value to obtain the data after forward constraint propagation. The reverse constraint propagation module is used to respond to the output-side target constraint specified by the user, and perform reverse constraint propagation from the output-side target constraint along the reverse direction of the directed edge based on the forward constraint propagation data to obtain the reverse constraint propagation data. The cycle dependency breaking module is used to perform cycle dependency breaking processing on the strongly connected components detected in the graph corresponding to the data after the reverse constraint propagation, and to determine the bidirectional propagation data after the breaking; The constraint solving and data synthesis module is used to compile the propagated constraints corresponding to the bidirectional propagated data into satisfiability modulus theory formulas, call the satisfiability modulus theory solver to solve the satisfiability modulus theory formulas, and obtain the solved data. The test dataset assembly and export module is used to assemble and output the solved data according to the user-selected format to obtain a complete test dataset.

[0015] In another aspect, this application provides a computer device including at least one connected processor and a memory, wherein the memory is used to store program code, and the processor is used to call the program code in the memory to execute the methods described in the above aspects.

[0016] In another aspect, embodiments of this application provide a computer storage medium including instructions that, when executed on a computer, cause the computer to perform the methods described in the above aspects.

[0017] In another aspect, this application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the above aspects.

[0018] Compared to traditional technologies, the technical solution of this application embodiment ensures the consistency of cross-interface data through contract graph modeling and bidirectional constraint propagation; it eliminates the need for testers to consider data boundaries one by one, realizes the systematization of boundary values ​​and abnormal scenarios, and improves the overall efficiency and quality of test data synthesis. Attached Figure Description

[0019] Figure 1 This is a flowchart of one embodiment.

[0020] Figure 2 This is a structural block diagram of a system in one embodiment.

[0021] Figure 3 This is an internal structural diagram of a computer device in one embodiment.

[0022] Figure 4 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation

[0023] The terms "first," "second," etc., used in the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The division of modules appearing in the embodiments of this application is only a logical division. In actual applications, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, and the indirect coupling or communication connection between modules may be electrical or other similar forms. None of these are limited in the embodiments of this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed among multiple circuit modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of this application.

[0024] Figure 1This is a flowchart illustrating one embodiment, such as... Figure 1 As shown in the embodiments of this application, the method for synthesizing cross-interface consistency test data based on interface contract graphs includes: S1100 automatically extracts the input and output constraint information of each interface from the preset data source, performs formal processing on the input and output constraint information, and obtains unified contract tuple representation data.

[0025] The preset data source refers to the various data sources pre-defined for extracting interface constraint information. Preset data sources include specification documents, code annotations, interface documentation, and production traffic sampling data. Automatic extraction refers to a processing method that automatically extracts constraint information without requiring manual field-by-field analysis.

[0026] Among them, input and output constraint information is used to characterize the rules such as the type range and format that the interface input and output parameters must meet; formal processing refers to the process of converting unstructured constraints into standardized computable expressions; contract tuple representation data is used to reflect the structured and unified description data of interface constraint information.

[0027] For example, input and output constraint information of N API interfaces in the system is automatically extracted from multiple data sources, and the unified contract tuple represents the data, which is the formal contract definition data of each API interface.

[0028] S1200 performs interface contract construction processing based on unified contract tuple representation data to obtain a directed weighted interface contract graph.

[0029] Among them, the interface contract construction process refers to the process of building an interface relationship graph based on contract tuples.

[0030] Among them, the directed weighted interface contract graph refers to a directed relational graph structure where the vertices are interfaces and the edges are weighted.

[0031] For example, the N API contracts are constructed as a directed weighted interface contract graph G=(V, E, W), where the vertex set V corresponds to the N APIs, the directed edge set E represents the data flow between APIs, and the edge weight W(e_ij) is a weighted sum of data coupling degree, call frequency and edge existence confidence.

[0032] S1300 receives the test scenario seed value specified by the user, performs forward constraint propagation along the directed edge direction of the directed weighted interface contract graph based on the test scenario seed value, and obtains the data after forward constraint propagation.

[0033] Among them, the test scenario seed value refers to the initial parameter value specified by the user in advance to start the generation of test data; forward constraint propagation refers to the propagation process of shrinking the range of downstream parameter values ​​along the data flow direction; the data after forward constraint propagation is used to characterize the constraint data after the range of each parameter value is shrunk after forward propagation; the output side target constraint refers to the expected conditions set by the user for the final output result of the interface.

[0034] For example, the system receives the test scenario seed value specified by the user, and performs forward constraint propagation along the directed edge direction of the graph starting from the parameter with known value. Specifically, it performs type checking, range propagation, format validation, enumeration validation, and custom constraint evaluation on the determined parameter value against the input constraints of the downstream API, narrowing the range of legal values ​​of the downstream parameter until the propagation fixed point is reached.

[0035] S1400, in response to the user-specified output-side target constraint, performs reverse constraint propagation from the output-side target constraint along the reverse direction of the directed edge based on the data after forward constraint propagation, and obtains the data after reverse constraint propagation.

[0036] Among them, reverse constraint propagation refers to the propagation process of inferring upstream input parameter requirements from the output target; the data after reverse constraint propagation is used to reflect the requirement specification data of each upstream interface parameter after reverse propagation.

[0037] For example, when the user specifies the target constraint on the output side, reverse constraint propagation is performed from the target constraint in the opposite direction of the directed edge to transform the output expectation into a requirement specification for the upstream API parameters, and the process is recursively reversed until the starting API.

[0038] S1500 performs cyclic dependency breaking processing on the strongly connected components detected in the graph corresponding to the data after reverse constraint propagation, and determines the bidirectional propagation data after the breaking.

[0039] Strongly connected components refer to subgraph structures in which vertices in the graph are mutually reachable and form loops; loop dependency resolution refers to the process of eliminating loops in the graph to prevent the propagation of infinite loops.

[0040] Among them, the data obtained after bidirectional propagation is used to characterize the final constraint data determined after the combined effect of forward and reverse propagation.

[0041] For example, for strongly connected components (SCCs) detected in the graph, the Tarjan algorithm is used to identify them, and the edge with the smallest edge weight is selected as a virtual broken edge to break the cycle. After propagation on the broken DAG, the posterior compatibility of the two ends of the broken edge is checked.

[0042] S1600 compiles the propagation constraints corresponding to the bidirectional propagation data into satisfiability modulus theory formulas, calls the satisfiability modulus theory solver to solve the satisfiability modulus theory formulas, and obtains the solved data.

[0043] Among them, the post-propagation constraints refer to all constraints after propagation, which means the final legal range of values ​​for each parameter after propagation and contraction.

[0044] Among them, the Satisfiability Modular Theory formula, or SMT formula, is used to characterize the logical mathematical expression that can be operated by the solver after compilation; the Satisfiability Modular Theory solver, or SMT solver, refers to the computational tool used to determine whether the constraints can be satisfied and to solve them; the solved data is used to reflect the variable assignment results output by the solver that satisfy all constraints.

[0045] For example, all constraints after propagation are compiled into SMT (Satisfiability Modulus Theory) formulas, and the SMT solver (Z3 / CVC5 / Yices2) is called to solve them. Satisfiable (SAT) results are deserialized into request / response test data for each API, and a "1+N" strategy is applied to automatically generate variant data families covering boundary values ​​and outliers based on each normal data. For unsatisfiable (UNSAT) results, a minimum conflict subset report is output.

[0046] S1700 assembles and outputs the solved data according to the user-selected format to obtain the complete test dataset.

[0047] Here, "assembly output" refers to the process of packaging the solution results into a usable dataset according to a specified format; "complete test dataset" refers to a set of request and assertion data that can be directly used for interface testing.

[0048] Compared to traditional technologies, in this embodiment, the input and output constraint information of each interface is first automatically extracted from a preset data source and formalized. Then, an interface contract construction process is performed to obtain a directed weighted interface contract graph. Subsequently, forward constraint propagation and backward constraint propagation are executed, and the strongly connected components detected in the graph are subjected to cycle dependency breaking processing. Then, the graph is compiled into a satisfiability modular theory formula, and a satisfiability modular theory solver is called to solve it. Finally, the solved data is assembled and output according to the user-selected format to obtain a complete test dataset. The technical solution of this embodiment ensures the consistency of cross-interface data through contract graph modeling and bidirectional constraint propagation. It eliminates the need for testers to consider data boundaries one by one, realizes the systematization of boundary values ​​and abnormal scenarios, and improves the overall efficiency and quality of test data synthesis.

[0049] Optionally, in some embodiments of this application, interface contract construction processing is performed based on unified contract tuple representation data to obtain a directed weighted interface contract graph, including: constructing a vertex set and a directed edge set of the directed weighted interface contract graph; calculating coupling weights based on data coupling degree scores, determining frequency weights based on normalized values ​​of actual call frequencies, and obtaining confidence weights based on deterministic scores of preset data sources; performing weighted summation based on coupling weights, frequency weights, and confidence weights to obtain edge weight data of the directed weighted interface contract graph; and constructing a directed weighted interface contract graph based on the vertex set, directed edge set, and edge weight data.

[0050] The vertex set refers to the set of all vertices representing each interface in the graph; the directed edge set refers to the set of all directed edges representing the data flow between interfaces in the graph.

[0051] Among them, the data coupling score is used to characterize the degree of correlation reflected by the proportion of shared fields between interfaces; the coupling weight, w-coupling, refers to the edge weight component calculated based on the data coupling degree between interfaces; the normalized value of the actual call frequency is used to reflect the normalized value of the call frequency between interfaces in the production environment; the frequency weight, w-frequency, refers to the edge weight component calculated based on the call frequency between interfaces; the deterministic score is used to characterize the reliability score of the constraint information provided by the data source; the confidence weight, w-confidence, refers to the edge weight component calculated based on the confidence of the edge existence; the weighted summation refers to the calculation method of adding the components according to the coefficient weights to obtain the comprehensive value; the edge weight data is used to characterize the numerical data of the comprehensive weight of the directed edges, and the obtained edge weight data is edge weight W(e_ij).

[0052] For example, the vertex set V = {v_i | v_i corresponds to API_i}, with each vertex having a complete contract tuple for that API attached. The directed edge set E = {e_ij | there exists a data flow from the output field of API_i to the input field of API_j}. The edge weight W(e_ij) = wcoupling × wfrequency × wconfidence, where: wcoupling is the data coupling score, calculated based on the proportion of shared fields to the total number of parameters; wfrequency is the normalized value of the actual call frequency from API_i to API_j in the production environment; and wconfidence is the existence confidence of the edge, derived from the determinism of the data source.

[0053] In this embodiment, edge weights are calculated using a three-dimensional weighted approach based on coupling degree, call frequency, and confidence level, which improves the accuracy and rationality of graph modeling and enhances the priority ranking effect of constraint propagation paths.

[0054] Optionally, in some embodiments of this application, the strongly connected components detected in the graph corresponding to the data after reverse constraint propagation are subjected to cycle dependency breaking processing to determine the bidirectional propagation data after the breaking process. This includes: using a time complexity algorithm to identify the strongly connected components in the graph corresponding to the data after reverse constraint propagation; selecting the edge with the smallest edge weight in the strongly connected component as a virtual broken edge to perform cycle breaking processing to obtain a directed acyclic graph after cycle breaking processing; performing bidirectional constraint propagation on the directed acyclic graph after cycle breaking processing; and performing posterior compatibility verification on both ends of the broken edge of the directed acyclic graph after cycle breaking processing to determine the bidirectional propagation data.

[0055] Among them, the time complexity algorithm, namely Tarjan's algorithm, refers to a strongly connected component detection algorithm with linear time complexity; virtual edge breaking refers to the processing method of temporarily removing the edge with the smallest weight in a loop to break the loop.

[0056] Among them, "loop breaking" refers to the process of transforming a circular structure into an acyclic structure by removing an edge from the loop; a directed acyclic graph refers to a directed graph structure that does not contain any loops.

[0057] Among them, posterior compatibility verification refers to the verification process of checking whether the values ​​at both ends of the broken edge are compatible after propagation is completed.

[0058] For example, when strongly connected components exist in the contract graph, forward and backward propagation may loop infinitely within the loop. A Tarjan algorithm-based SCC detection and virtual edge-breaking strategy is adopted to address this, specifically including: (a) using the Tarjan algorithm to identify all SCCs in the graph; (b) for each SCC, selecting the edge with the smallest edge weight W as a "virtual edge break," temporarily removing it but not deleting it, and marking it as broken; (c) performing normal bidirectional constraint propagation on the broken DAG; (d) for the broken constraint relationships, supplementing the check with "post-hoc verification" after propagation, i.e., after the values ​​of all other nodes in the loop have been determined, checking whether the values ​​at both ends of the broken edge are compatible; if incompatible, adjusting them; (e) if all constraints still cannot be satisfied after adjustment, marking the test scenario as "constraints unsatisfiable" and outputting a conflict report.

[0059] In this embodiment, by detecting strongly connected components and using virtual edge breaking combined with posterior verification to break circular dependencies, the stability and reliability of constraint propagation are improved, and the infinite loop problem caused by loops is avoided.

[0060] Optionally, in some embodiments of this application, the propagation constraints corresponding to the bidirectional propagation data are compiled into satisfiability modulus theory formulas, and the satisfiability modulus theory solver is called to solve the satisfiability modulus theory formulas to obtain the solved data, including: deserializing the satisfiable results to obtain the request or response test data of each interface, and applying a boundary detection strategy to automatically generate a variant data family covering boundary values ​​and outliers based on each normal data; outputting a minimum conflict subset report for the unsatisfiable results; and determining the solved data based on the variant data family and the minimum conflict subset report.

[0061] Among them, Satisfactory Result (SAT) refers to the solution result in which the solver determines that the constraint has a valid solution; deserialization refers to the process of converting the variable assignments output by the solver into structured request data.

[0062] Among them, the boundary detection strategy is referred to as the "1+N" strategy, which refers to the strategy method of automatically generating test variants at the constraint boundary.

[0063] Boundary values ​​refer to the upper and lower limits of the constraint range and the critical values ​​near them; outliers refer to values ​​that are intentionally violated for negative testing; variant data families refer to a set of boundary and outlier test data extended from normal data.

[0064] Among them, the Unsatisfiable Result (UNSAT) refers to the solution result where the solver determines that there is no solution due to contradictions between constraints; the Minimal Conflict Subset Report refers to the report that locates the smallest set of constraints that leads to no solution.

[0065] For example, Satisfiable (SAT) results are deserialized into request / response test data for each API, and a "1+N" strategy is applied to automatically generate variant data families covering boundary values ​​and outliers based on each normal data; for Unsatisfiable (UNSAT) results, a minimal conflict subset report is output.

[0066] In this embodiment, variant data families are generated by combining satisfiability modulus solution with boundary detection strategy, which improves the coverage and diversity of test data and enhances the detection capability of boundaries and abnormal scenarios.

[0067] Optionally, in some embodiments of this application, the propagation constraints corresponding to the bidirectional propagation data are compiled into satisfiability modulus theory formulas, and a satisfiability modulus theory solver is called to solve the satisfiability modulus theory formulas to obtain the solved data. This includes: constructing a fitted probability distribution model based on the production environment interface traffic sampling data, and outputting fitted distribution data according to the fitted probability distribution model; when it is necessary to generate specific values ​​for fields during the process of solving the satisfiability modulus theory formulas, sampling fill field values ​​from the fitted distribution data and projecting them back to the constraint allowable range, so as to solve the data based on the fill field values ​​projected back to the constraint allowable range.

[0068] Among them, production environment interface traffic sampling data, also known as production environment API traffic sampling data, refers to data sampled from real online interface traffic.

[0069] Among them, the fitted probability distribution model refers to the probability distribution model statistically fitted based on real data; the fitted distribution data is used to reflect the probability distribution characteristics of the fitted model output; sampling filling refers to the process of randomly extracting values ​​from the probability distribution to fill the field; and projection back to the constraint allowed range refers to the process of correcting out-of-bounds sampled values ​​to the legal range.

[0070] For example, for fields marked as free variables in the solution, a probability distribution model is fitted from production environment API traffic sampling data, and field values ​​are sampled from the fitted distribution and projected back to the constraint allowable range; the fitted probability distribution model includes kernel density estimation or Gaussian mixture model for continuous fields, multinomial distribution for discrete fields, and n-gram language model or lightweight LLM for string fields.

[0071] In this embodiment, test data is generated by combining production flow distribution fitting and constrained projection, which improves the realism and production fit of the test data and enhances the ability to detect production environment problems.

[0072] Optionally, in some embodiments of this application, before assembling and outputting the solved data in a user-selected format to obtain a complete test dataset, the method further includes: establishing a data lineage record for each field of each synthetic test data corresponding to the solved data; and, in the event of a conflict arising during the constraint propagation process represented by the data lineage record, performing constraint propagation conflict resolution processing according to the data source priority strategy to obtain constraint propagation conflict resolution result data.

[0073] Among them, data lineage records refer to tracking data that records the origin and evolution of each field value.

[0074] Among them, constraint propagation conflict refers to the situation where different propagation paths give inconsistent values ​​for the same field; data source priority strategy refers to the strategy of arbitrating conflicts according to the reliability of the data source; constraint propagation conflict resolution refers to the process of resolving conflicts based on priority and determining the final value.

[0075] For example, a data lineage record is created for each field of each synthetic test data, constraint propagation conflicts are detected and resolved (arbitrated according to data source priority), and a complete test dataset is assembled and output; the data lineage record includes value, source type, source details, propagation path, and conflict flag.

[0076] In this embodiment, by establishing data lineage records and priority arbitration to resolve propagation conflicts, the traceability and consistency of test data are improved, and the ability to handle constraint conflicts is enhanced.

[0077] Optionally, in some embodiments of this application, the priority order represented in the data source priority strategy from high to low is as follows: the test scenario seed value specified by the explicit user, the sampled fill field value in the fitted distribution data, the satisfiability modulus solution value corresponding to the solved data, the propagation inheritance value, and the default value.

[0078] Among them, priority order refers to the order of adjudication when conflicts occur between different data sources; explicit user-specified value, also known as user-specified value or explicit user-specified test scenario seed value, refers to the seed parameter value explicitly input by the user; sampled fill field value in the fitted distribution data, also known as production sample value; satisfiability modulus theoretical solution value corresponding to the solved data, also known as SMT solution value; propagation inheritance value, also known as forward propagation inheritance value, refers to the parameter value inherited from upstream and downstream interfaces through constraint propagation; default value refers to the preset default value used when there are no other sources.

[0079] For example, the priority order for conflict resolution is: user-specified value (priority 5) > production sample value (4) > SMT solution value (3) > forward propagation inherited value (2) > default value (1), with higher priority values ​​winning.

[0080] In this embodiment, by setting a clear priority order for data sources to arbitrate conflicts, the certainty and rationality of conflict resolution are improved, and the stability of the test data generation results is guaranteed.

[0081] The technical research process and other technical details of this application are described below with reference to a specific embodiment.

[0082] In modern microservice architectures and enterprise-level distributed systems, ensuring data consistency among Application Programming Interfaces (APIs) is one of the core challenges in the testing field. A typical business process (such as e-commerce order placement → inventory deduction → payment processing → logistics delivery) often spans 5-20 microservices and 10-50 API interfaces. Each interface has complex input constraints (parameter types, value ranges, enumeration values, format requirements, business rules) and output contracts (response structure, field meanings, error code system). Traditional test data preparation methods face the following dilemmas: (1) Efficiency bottleneck of manually constructing data When testers manually construct API test data, they need to consult API documentation (Swagger / OpenAPI specifications, API wikis, code annotations, etc.) one by one to understand the meaning and constraints of each parameter, and then construct the request body based on experience and intuition. The main problems with this method include: (a) long processing time; constructing data for a medium-complexity API test case takes an average of 15-30 minutes; (b) low coverage; testers tend to use "Happy Path" data (i.e., the most readily conceived combination of normal values), making it difficult to systematically cover boundary values, outliers, and combined boundary scenarios; (c) poor consistency; test data across interfaces is often constructed independently, and the output data format of the upstream interface may not match the expected input format of the downstream interface, leading to a large number of "false negative" failures (the test failure is due to data inconsistency rather than a real functional defect). According to industry research data, in microservice integration testing, approximately 35%-45% of test failures are attributed to test data quality issues (data not conforming to the interface contract), rather than actual defects in the system under test.

[0083] (2) Limitations of existing automated data generation technologies

[0084] To address the above issues, the industry has proposed various automated test data generation solutions, which mainly include the following categories: (a) Template / schema-based data generation tools: Representative tools include ZenData (domestic open source), Faker.js (internationally popular), Mockaroo, etc. These tools generate random or semi-random data based on user-defined schemas (YAML / JSON Schema). The advantages are speed and ease of use; the disadvantages are that they can only handle data generation for a single interface / entity, lack cross-interface constraint awareness, and cannot guarantee that the output data of interface A can be directly used as valid input for interface B.

[0085] (b) Mock Data Generation Based on API Documentation Parsing: Representative solutions include technical articles and engineering practices that generate sample request bodies after understanding OpenAPI documentation using large language models such as DeepSeek / ChatGPT (emerging gradually from 2025-2026). The advancement of this type of solution lies in its ability to understand the field-level constraints of a single API and generate sample data that conforms to the specifications. However, its essence is still a "single API perspective," and it cannot model the relationships between multiple APIs. For example, the cross-API constraints such as the consistency in type and format between the "orderId field in the response of the order creation interface" and the "orderId parameter in the request of the order query interface" cannot be automatically discovered and guaranteed by LLM documentation understanding solutions.

[0086] (c) Consumer-Driven Contract Testing (CDC / Pact): Representative frameworks include Pact (multi-language versions in Ruby / JS / Java / .NET), Spring Contract, etc. The core idea of ​​CDC is that the consumer defines the expected contract (expected request / response pair), and the provider verifies whether its own implementation conforms to the contract. CDC can effectively prevent incompatible changes to the interface protocol from breaking the consumer, but its design is positioned as "contract verification" rather than "test data generation". That is, it tells you "the interface has changed and is incompatible", but it will not help you generate a complete test dataset that is consistent across N interfaces.

[0087] (d) Production Traffic Playback / Recording: Representative tools include GoReplay, Traffic Control, Tcpdump, and other traffic recording and playback solutions. These solutions record real traffic from the production environment and then play it back in the test environment. The advantage is high data authenticity; the disadvantage is that it relies entirely on the existing traffic scenarios in the production environment, cannot actively explore new boundary combinations, and involves compliance complexities related to data anonymization.

[0088] In summary, existing technologies either remain at the "single interface / single entity" data generation level (unable to guarantee cross-API consistency), focus on "contract verification" (without generating test data), or rely on "production traffic replay" (passive and limited by existing scenarios). The industry urgently needs a systematic approach and system capable of: globally modeling the input-output constraint relationships between N APIs; automatically synthesizing consistent test data across all APIs based on constraint propagation; and simultaneously covering boundary values, outliers, and combined scenarios.

[0089] Based on this, this application provides a cross-interface consistency test data synthesis method based on interface contract graph, also known as a cross-API consistency test data synthesis and constraint propagation method based on interface contract graph. It belongs to the field of software interface testing and automated test data generation technology. Its purpose is to solve the following technical problems: (1) the existing test data generation scheme cannot guarantee the data consistency between multiple API interfaces; (2) the manual or randomly generated test data does not cover boundary values, outliers and combined scenarios; (3) the existing scheme cannot automatically discover and utilize the implicit dependencies between APIs (such as the output of A is the input of B) to generate end-to-end consistent test data streams. The present invention is achieved through the following technical means: all API interfaces and their input and output constraints in the system are modeled as a directed weighted interface contract graph (Contract Graph). Bidirectional constraint propagation is performed on this graph (forward: known input derives downstream output; backward: expected output derives upstream input requirements). Combined with the SMT constraint solver, test data that satisfies all constraints is automatically solved. Field distribution characteristics are learned from the production environment traffic to ensure the realism of the synthesized data.

[0090] The specific steps of the cross-interface consistency test data synthesis method based on interface contract graph in this application include: Step A: Automatically extract the input and output constraint information of N API interfaces in the system from multiple data sources. The formal contract of each API interface is defined as API_i=(endpoint, method, params_in, params_out, constraints_in, constraints_out, deps), where constraints include six basic types: TYPE_C type constraints, RANGE_C range constraints, ENUM_C enumeration constraints, FORMAT_C format constraints, REF_C reference constraints, and CUSTOM_C custom business constraints. Step B: Construct the N API contracts into a directed weighted interface contract graph G=(V, E, W), where the vertex set V corresponds to the N APIs, the directed edge set E represents the data flow between APIs (a directed edge e_ij is established when the output field of API_i and the input field of API_j satisfy one of the conditions of name matching / type compatibility / explicit reference / semantic inference), and the edge weight W(e_ij) is the weighted sum of data coupling degree, call frequency and edge existence confidence. Step C: Receive the test scenario seed value specified by the user (which can be an empty set or partially specified), and perform forward constraint propagation along the directed edge direction of the graph starting from the parameter with known value. Specifically, the determined parameter value is compared with the input constraints of the downstream API to perform type checking, range propagation, format validation, enumeration validation, and custom constraint evaluation, narrowing the legal value range of the downstream parameter until the propagation fixed point is reached. Step D: When the user specifies the target constraint on the output side, reverse constraint propagation is performed from the target constraint in the opposite direction of the directed edge to transform the output expectation into a requirement specification for the upstream API parameters, and the process is recursively reversed until the starting API is reached. Step E: For the strongly connected components (SCCs) detected in the graph, the Tarjan algorithm is used to identify them and select the edge with the smallest edge weight as a virtual broken edge to break the cycle. After propagation on the broken DAG, the posterior compatibility of the two ends of the broken edge is checked. Step F: Compile all propagated constraints into SMT (Satisfiability Modulus Theory) formulas, call the SMT solver (Z3 / CVC5 / Yices2) to solve, deserialize the satisfiable (SAT) results into request / response test data for each API, and apply the "1+N" strategy to automatically generate variant data families covering boundary values ​​and outliers based on each normal data; output a minimum conflict subset report for unsatisfiable (UNSAT) results. Step G: For the fields marked as free variables in the solution, fit a probability distribution model from the API traffic sampling data in the production environment (use kernel density estimation or Gaussian mixture model for continuous fields, multinomial distribution for discrete fields, and n-gram language model or lightweight LLM for string fields), sample the filled field values ​​from the fitted distribution and project them back to the constraint allowable range; Step H: Establish a data lineage record for each field of each synthetic test data (including value, source type, source details, propagation path, and conflict flag), detect and resolve constraint propagation conflicts (arbitrate according to data source priority), and assemble and output the complete test dataset.

[0091] In step A, the data sources supported, from highest to lowest priority, are: OpenAPI / Swagger 3.0 specification files, code framework validation annotations (javax.validation / Pydantic / FastAPI / go-validate), unstructured interface documents parsed by LLM, and reverse schema inference from production traffic; when multiple data sources conflict, the higher priority takes precedence and the conflict is recorded.

[0092] Wherein, the calculation formula for the edge weight W in step B is: W(e_ij) = α·w_coupling + β·w_frequency + γ·w_confidence, where α+β+γ=1, and the recommended values are α=0.4, β=0.35, γ=0.25; w_coupling is the ratio of the number of shared fields to the total number of input parameters of API_j; w_frequency is the normalized value of the call volume from API_i to API_j in the production environment to the interval [0,1]; w_confidence is valued according to the edge establishment source (explicit $ref=1.0, LLM semantic inference=0.6-0.8, field name + type matching=0.7-0.9).

[0093] Wherein, the shrinkage rule for the RANGE_C constraint in the forward propagation in step C is: if the upstream output value val falls into the closed interval [min, max], the propagation succeeds and the downstream parameter domain is shrunk to [val∩original_domain]; if val < min, it is marked as "range underflow"; if val > max, it is marked as "range overflow"; if val is equal to exclMin or exclMax, it is marked as "exclusive boundary collision".

[0094] Wherein, the a posteriori verification method for Tarjan cycle breaking in step E is: after the values of all non-break-edge nodes in the SCC are determined, let the break edge be e=(u, v), and verify whether the output value of u satisfies the input constraint of v after edge mapping; if they are incompatible, randomly select to adjust the value of u or v with the probability of the inverse ratio of the weights of the two sides of (u, v); if there is still a conflict after adjustment, the entire SCC is marked as "constraint unsatisfiable" and the constraint set involved in the conflict is listed.

[0095] Wherein, the specific rules of the "1+N" boundary detection strategy in step F are: generate a maximum of 8 boundary variants for each RANGE_C constraint, including min, min+δ, max-δ, max, exclMin±1, exclMax±1 (δ is the minimum meaningful granularity, δ=1 for integer type, δ=0.01 for floating-point type); traverse all enumeration values for each ENUM_C constraint to generate N_enum variants; additionally generate 2-3 deliberately violating negative test cases for the pattern constraint of each FORMAT_C.

[0096] Wherein, the number of components K of the Gaussian mixture model in step G is automatically selected through BIC (Bayesian Information Criterion): K =argmin_K { BIC(K) = -2·ln(L_K) + K·ln(n)}, where L_K is the likelihood value of the K-component Gaussian model, n is the sample size, and the search range of K is 1-5.

[0097] In step H, the priority order for conflict resolution is as follows: user-specified value (priority 5) > production sample value (4) > SMT solution value (3) > forward propagation inherited value (2) > default value (1), with higher priority values ​​winning; the complete record of the conflict event includes timestamp, involved API pair, involved field name, values ​​and sources of both parties in the conflict, arbitration result and reason for the ruling.

[0098] The output test dataset supports multiple export formats: Postman Collection v2.1 format, Python pytest parameterized fixture format, JUnit 5 @CsvSource CSV format, and user-defined Mustache / Handlebars template format; each test data entry is accompanied by a coverage label (indicating the type of constraint covered and the test intent) and a data lineage summary.

[0099] The key technical points of the cross-interface consistency test data synthesis method based on interface contract graph in this application are as follows: (1) Global Modeling of Directed Weighted Interface Contract Graph: This is the first method proposed in the field of test data generation to uniformly model N APIs and their input and output constraints as a weighted directed graph. The edges of the graph not only represent the data flow direction, but also carry three-dimensional weights of coupling degree, call frequency and confidence, so that constraints can be preferentially propagated along the "most important and most frequent" path. This is fundamentally different from existing single API data generation tools (ZenData / Faker.js / Mockaroo) and single API document understanding schemes (DeepSeek-based mock gen) - the latter do not have the concept of "graph" and cannot model cross-API relationships.

[0100] (2) Innovative combination of bidirectional constraint propagation (forward + backward): The combined use of forward propagation (known input → deducing output → narrowing the downstream scope) and backward propagation (expected output → deducing input requirements) is a first in the field of test data generation. Forward propagation ensures that "data remains legal throughout the process", while backward propagation enables "goal-oriented test data generation" (simply declare what scenario you want to test, and the system will automatically deduce what input is needed). The combination of the two allows the system to perform both traditional tests of "given input and see the output" and goal-driven tests of "given output and find the input".

[0101] (3) Automatic Resolution of Circular Dependencies Based on Tarjan SCC Detection: Circular calls between APIs are common in microservice systems (e.g., A creates an order → B deducts inventory → A updates the order status, forming a loop). In constraint propagation, loops can lead to infinite cycles. This invention uses the classic Tarjan linear-time SCC detection algorithm (O(V+E) complexity) to identify loops, and elegantly solves this problem with a two-stage strategy of virtual edge breaking + posterior verification. This strategy is original in its application to the field of test data generation.

[0102] (4) Introduction of SMT constraint solver and "1+N" boundary probing strategy: The SMT solver (Z3) from the formal verification field is introduced into the test data generation, enabling the system to automatically handle arbitrarily complex combinations of constraints (arithmetic inequalities, regular matching, enumeration constraints, cross-references, etc.). The "1+N" strategy automatically expands to cover a family of variants that cover boundary values ​​and outliers based on a single solution, so that the test coverage expands from a single Happy Path to a complete equivalence class / boundary value matrix.

[0103] (5) Enhanced Data Realism Through Production Flow Distribution Fitting: While the data generated by pure constraint solving is mathematically valid, it may deviate significantly from the distribution of real production data. The M5 module learns the distribution characteristics from real flow through methods such as kernel density estimation, GMM fitting, and n-gram models, making the test data "look real" as much as possible while satisfying hard constraints. This improves the sensitivity of the test data to detecting problems in the production environment.

[0104] (6) Complete data lineage tracing and conflict resolution mechanism: Every field of each piece of synthetic data can be traced back to its source (seed value / solved value / sampled value / propagation value / default value). When constraint conflicts occur, there is a clear arbitration strategy and complete audit logs. This is not only a powerful debugging tool, but also a data support for promoting the standardization of API design. Conflict hotspots directly reflect which APIs have inconsistent contractual agreements.

[0105] The advantages of the cross-interface consistency test data synthesis method based on interface contract graph in this application are: (1) Cross-API data consistency is fundamentally guaranteed: Through contract graph modeling and bidirectional constraint propagation, the system ensures that the data along the entire chain, from the input of the first API to the output of the last API, always satisfies all relevant interface constraints. This means that when a test fails, it can be attributed with more confidence to "defects in the system under test" rather than "problems with the test data itself". It is estimated that the false positive failures caused by the current 35%-45% data quality problems can be reduced to below 5%.

[0106] (2) Order-of-magnitude improvement in test data generation efficiency: For a medium-sized microservice system with 20 APIs and an average of 8 parameters per API, manually constructing a set of end-to-end test data covering the main scenarios would take about 4-8 person-days; after using this system, the fully automated process from contract extraction to dataset export takes only 3-15 minutes (depending on the graph complexity and SMT solution scale), improving efficiency by about 100-1000 times.

[0107] (3) Systematic coverage of boundary values ​​and abnormal scenarios: The "1+N" strategy automatically generates a complete combination of normal value + boundary value + abnormal value for each constraint, eliminating the need for testers to think about "whether there are boundary cases here". Systematic boundary detection can cover many corners that are easily overlooked by humans (such as "when the discount rate is 0", "the quantity is exactly equal to the inventory threshold", "the amount is rounded to the nearest tenth", etc.).

[0108] (4) Goal-oriented test data generation (unique capability of backpropagation): Testers can use natural language-based goals to drive data generation: "I want a scenario where a VIP user returns multiple items purchased during a promotional event." The system automatically calculates what parameters need to be entered into the initial API to achieve this goal through backpropagation. This "declarative" data generation experience is far superior to the traditional "imperative" field-by-field filling.

[0109] (5) Production-driven data realism: The distribution fitting module ensures that the test data is not only mathematically valid but also statistically close to real production data. This is of great value in discovering bugs that are only triggered under specific data distributions (such as usernames of a certain length causing buffer overflows, postal code formats in specific regions triggering parsing errors, etc.).

[0110] (6) Promote API contract standardization: Conflict logs and hotspot analysis accumulated in data lineage tracing serve as a mirror, objectively reflecting which APIs have inconsistent contractual agreements and which fields have ambiguous constraint definitions. Regularly synchronizing this data with the API design and development teams can improve interface standardization from the source, forming a virtuous cycle of "test-driven contract governance".

[0111] It should be noted that any technical feature in any of the above embodiments provided in this application is also applicable to any of the following embodiments provided in this application; the technical features in the relevant embodiments of the various methods provided in this application are also applicable to the relevant embodiments of the various devices, systems or equipment provided in this application; the same, related or corresponding technical features in the various embodiments provided in this application can be referenced and explained to each other, and similarities will not be repeated.

[0112] Figure 2 Here is a structural block diagram of the system in one embodiment, with reference to Figure 2 The cross-interface consistency test data synthesis system based on interface contract graph includes: The interface contract automatic extraction and modeling module 201 is used to automatically extract the input and output constraint information of each interface from the preset data source, perform formal processing on the input and output constraint information, and obtain unified contract tuple representation data. The directed weighted interface contract graph construction module 202 is used to perform interface contract construction processing based on unified contract tuple representation data to obtain a directed weighted interface contract graph. The forward constraint propagation module 203 is used to receive the test scenario seed value specified by the user, and perform forward constraint propagation along the directed edge direction of the directed weighted interface contract graph according to the test scenario seed value to obtain the data after forward constraint propagation. The reverse constraint propagation module 204 is used to respond to the output-side target constraint specified by the user, and to perform reverse constraint propagation from the output-side target constraint along the reverse direction of the directed edge based on the data after forward constraint propagation, so as to obtain the data after reverse constraint propagation. The circular dependency breaking module 205 is used to perform circular dependency breaking processing on the strongly connected components detected in the graph corresponding to the data after reverse constraint propagation, and to determine the bidirectional propagation data after the breaking. The constraint solving and data synthesis module 206 is used to compile the propagated constraints corresponding to the bidirectional propagation data into satisfiability modulus theory formulas, call the satisfiability modulus theory solver to solve the satisfiability modulus theory formulas, and obtain the solved data. The test dataset assembly and export module 207 is used to assemble and output the solved data in the format selected by the user to obtain a complete test dataset.

[0113] In this embodiment of the application, based on, as follows Figure 2 The connections between the modules or units shown in the diagram improve the efficiency and quality of test data synthesis through the cooperation between these modules or units.

[0114] The following section describes the system composition and technical principles of the cross-interface consistency test data synthesis system based on interface contract graphs from the perspective of other technical descriptions.

[0115] The system consists of seven core modules: automatic interface contract extraction and modeling module (M1), directed weighted interface contract graph construction module (M2), bidirectional constraint propagation engine (M3), SMT constraint solving and data synthesis module (M4), production flow distribution fitting module (M5), data lineage tracing and conflict resolution module (M6), and test dataset assembly and export module (M7). The functions of each module are described below.

[0116] (1) Interface Contract Automatic Extraction and Modeling Module (M1)

[0117] M1 is responsible for automatically extracting the input and output constraint information of each API interface from multiple data sources and formalizing it into a unified contract representation. Supported data sources are listed in order of priority as follows: (a) OpenAPI / Swagger 3.0 specification files (JSON / YAML format) are the ideal data source, as they contain complete schema parameters, including type / format / min / max / enum / pattern / required, etc.; (b) Code annotations, such as Java's javax.validation annotations (@NotNull / @Size / @Min / @Max / @Pattern, etc.), Python's Pydantic model / FastAPI's Query / Path / Body decorators, Go's validate tag, etc.; (c) Interface documentation (Confluence / Wiki / Markdown), using LLM to parse unstructured text and extract constraint information; (d) Production traffic sampling, performing reverse schema inference on recent (e.g., the last 7 days) real request / response messages (using Type inference or Druid / Google API Design style inferringlibrary).

[0118] The formal contract for each API interface is defined as the following tuple: API_i = (endpoint, method, params_in, params_out, constraints_in, constraints_out, deps); The parameters have the following meanings: endpoint: API path (e.g., " / api / v2 / orders / create"), supports path parameter placeholders (e.g., " / api / v2 / orders / {orderId}").

[0119] method: HTTP method (GET / POST / PUT / DELETE / PATCH).

[0120] params_in: A list of input parameters [{name, location, type, ...}], where location ∈ {query, path, header, body, cookie}.

[0121] params_out: Output parameter list (response body field structure).

[0122] constraints_in: The set of input constraints C_in, which contains the following six basic constraint types: TYPE_C: Type constraints: JSON Schema basic types string / integer / number / boolean / array / object / null, and custom enumeration types (such as order status: PENDING / PAID / SHIPPED / COMPLETED / CANCELLED).

[0123] RANGE_C: Range constraints: for numeric values, minimum / maximum / exclusive minimum / exclusive maximum (min / exclusiveMin / max / exclusiveMax), and for string values, minLength / maxLength.

[0124] ENUM_C: Enumeration constraint: Set of allowed values ​​(enum array), such as payment method: ["alipay","wechat","bank_card","balance"].

[0125] FORMAT_C: Format constraints: regular expressions (pattern), date and time formats (date-time / date / time), URI formats (email / uri / hostname / ipv4 / uuid, etc.), and custom formats.

[0126] REF_C: Reference constraints: $ref points to a shared definition (such as a reused Address object, a generic pagination structure) or a cross-API reference.

[0127] CUSTOM_C: Custom business constraints: Complex rules described in natural language or expressed by DSL (such as "discount amount ≤ unit price of goods × maximum discount rate of 30%", "delivery address must be in the list of operating cities").

[0128] (2) Directed weighted interface contract graph construction module (M2)

[0129] M2 is responsible for constructing a directed weighted graph G = (V, E, W) from the set of {API_i} contracts extracted by M1. The formal definition of the graph is: The vertex set V = {v_i | v_i corresponds to API_i}, with each vertex having a complete contract tuple for that API attached.

[0130] A directed edge set E = {e_ij | There exists a data flow from the output field of API_i to the input field of API_j}. The rules for establishing edges are as follows: A directed edge e_ij is created when a field f_out in the response body (params_out) of API_i and a field f_in in the request parameters (params_in) of API_j satisfy one of the following conditions: (a) The field names are the same and the data types are compatible (e.g., both are string format orderId); (b) There is an explicit $ref cross-API reference relationship; (c) A semantic "upstream and downstream" relationship is inferred from the interface documentation description through LLM analysis (e.g., "Interface A returns orderId when creating an order, and interface B requires orderId to query order details").

[0131] Edge weight W(e_ij) = wcoupling × wfrequency × wconfidence, where: w-coupling: Data coupling score (0-1), calculated based on the proportion of shared fields to the total number of parameters.

[0132] w frequency: The normalized value (0-1) of the actual call frequency from API_i to API_j in the production environment.

[0133] w confidence: edge existence confidence (0-1), determinism from the data source (explicit ref=1.0, LLM inference=0.6-0.8, name matching=0.7-0.9).

[0134] After the graph is constructed, the system automatically detects and handles two special cases: (a) isolated nodes with no incoming or outgoing edges (usually edge services or independent tool APIs), which can generate data separately; (b) strongly connected components (SCCs), where there are loops in the graph (such as A→B→C→A forming a loop, corresponding to the business loop of "create→modify→modify again"). For details on handling SCCs, please refer to the loop breaking strategy in M3.

[0135] (3) Two-way constraint propagation engine (M3)

[0136] M3 is responsible for performing bidirectional propagation of constraint information on the contract graph G. "Constraint propagation" means that when certain parameter values ​​of an API are determined (whether they are user-specified seed values ​​or system-generated initial values), the constraint information satisfied / violated by that value propagates along the edges of the graph to adjacent APIs, narrowing the range of legal values ​​for the parameters of adjacent APIs, and thus affecting more APIs in a chain reaction, until the propagation reaches a fixed point or the range of values ​​for all parameters is determined.

[0137] Forward Propagation: The direction is consistent with the data flow direction (along the directed edge direction). When the output parameter p_out of the upstream API_i is assigned a specific value val, the system performs the following: (a) Type check: Verify whether val satisfies the type constraint TYPE_C of the corresponding input parameter p_in of the downstream API_j. If incompatible, the data path is marked as "type conflict"; (b) Range propagation: If p_in has a RANGE_C constraint, propagation is successful if val falls within the range; otherwise, it is marked as "range overflow"; (c) Format propagation: If p_in has a pattern regular expression constraint in FORMAT_C, propagation is successful if val matches; otherwise, it is marked as "format violation"; (d) Enumeration propagation: If p_in has an ENUM_C constraint, propagation is successful if val belongs to the enumeration set; otherwise, it is marked as "illegal enumeration value"; (e) Custom constraint evaluation: For CUSTOM_C type constraints, compile them into evaluable expressions (supporting basic arithmetic comparisons, string operations, and set membership determination), substitute them into val for evaluation, and success is achieved if the result is true. (f) Value range shrinkage: Even if the specific value of val cannot be determined (e.g., the upstream only constrains "this is a positive integer"), forward propagation can shrink the value range of the downstream parameter from "the whole domain" to a subdomain that satisfies the upstream output constraint.

[0138] Backward Propagation: The direction is opposite to the data flow direction (along the reverse direction of the directed edges). When testers want to ensure that the output of downstream API_k meets a certain expected condition (such as "the total order amount must be greater than 0"), the system starts from this condition and works backward upstream to deduce the requirements that each API parameter should meet. Backward propagation process: (a) Formalize the expected condition as a target constraint C_target acting on a certain output parameter of API_k; (b) Trace along the incoming edges to the direct upstream API_j, and combine the mapping relationship of API_j→API_k to transform C_target into a requirement C_j for the output parameter of API_j; (c) Recursively propagate upward until the "starting API" is reached (usually the API for which the user manually provides the seed value or the "source node" of the graph); (d) The output of backward propagation is a requirements specification for each "starting input parameter", telling the user "what range of values ​​you need to input into the starting API if you want the final result to meet C_target". The value of backpropagation lies in supporting "target-oriented test data generation". Testers only need to declare "I want to test a super large order scenario with an amount exceeding 10,000 yuan", and the system will automatically deduce what kind of product unit price and quantity need to be passed into the order creation interface.

[0139] Circular dependency breaking (SCC breaking): When there are strongly connected components (SCC, i.e., loops) in the contract graph, forward and backward propagation may loop infinitely within the loop. This invention employs a SCC detection + virtual edge-breaking strategy based on the Tarjan algorithm (Tarjan, RE, "Depth-first search and linear graph algorithms", SIAM Journal on Computing, 1972) to solve the problem: (a) Use the Tarjan algorithm (time complexity O(V+E)) to identify all SCCs in the graph; (b) For each SCC, select the edge with the smallest edge weight W as a "virtual edge break" (temporarily removed but not deleted, marked as broken); (c) Perform normal bidirectional constraint propagation on the broken DAG (Directed Acyclic Graph); (d) For the broken constraint relationship, supplement the check in a "posterior verification" manner after propagation is completed, that is, after the values ​​of all other nodes in the cycle have been determined, check whether the values ​​at both ends of the broken edge are compatible. If they are incompatible, adjust them (prioritize adjusting the values ​​of nodes with lower weights on the broken edge); (e) If all constraints still cannot be satisfied after adjustment, mark the test scenario as "constraints cannot be satisfied" and output a conflict report (listing all constraints involved in the conflict and their source APIs).

[0140] (4) SMT constraint solving and data synthesis module (M4)

[0141] After constraint propagation in M3, the range of values ​​for each API parameter has been narrowed down to a (hopefully) small enough candidate space. The task of M4 is to select specific values ​​from this space and assemble them into complete test data. This invention uses an SMT (Satisfiability Modulo Theories) solver to automatically accomplish this task.

[0142] The compilation rules constrained to the SMT formula are as follows: TYPE_C(string), declared as a StringSort variable, with length constraints converted to length(v) ≥ minLen ∧ length(v) ≤ maxLen.

[0143] TYPE_C(integer), declared as an IntSort variable, the range constraint is converted to v ≥ min ∧ v ≤ max ∧ (v ≠ exclMin) ∧ (v ≠ exclMax).

[0144] TYPE_C(number) is declared as a RealSort variable and supports floating-point constraints.

[0145] TYPE_C(boolean) is declared as a BoolSort variable.

[0146] ENUM_C([v1,...,vn]) is transformed into v = v1 ∨ v = v2 ∨ ... ∨ v = vn (disjunction).

[0147] FORMAT_C(pattern) converts a regular expression into an SMT-lib2 compatible finite automaton constraint (using Z3's regex extension or preprocessing to a string equation).

[0148] CUSTOM_C(expr) parses a custom expression into the corresponding SMT arithmetic / logic formula.

[0149] Cross-API consistency constraint: If API_A.output.x = API_B.input.y, then declare var_x = var_y (variable equivalence constraint).

[0150] After all constraints are compiled, the Z3 SMT solver (or alternatives such as CVC5 or Yices2) is called to solve them. The solver output has two possibilities: (a) SAT (satisfiable), which returns a set of variable assignments that satisfy all constraints. M4 deserializes this into a JSON request / response body; (b) UNSAT (unsatisfiable), which indicates that there are logical conflicts between constraints. M4 calls Z3's UNSAT Core function to obtain a minimal unsatisfiable core, locates which constraints are contradictory, and then generates a conflict report for the user to adjust.

[0151] To improve the diversity of test data (covering more equivalence classes and boundary values), M4 incorporates a "boundary probing strategy" during the solution process: For each RANGE_C constraint, in addition to solving for a value that satisfies the constraint, variants are generated at the boundaries (min, min+ε, max-ε, max, and exclMin±1, exclMax±1); for each ENUM_C constraint, variants are generated by iterating through each enumerated value; and for each FORMAT_C pattern constraint, several values ​​that intentionally violate the pattern are generated (for negative testing). Through this "1+N" strategy, a single solution can produce a family of test data covering normal paths and multiple boundary / abnormal paths.

[0152] (5) Production flow distribution fitting module (M5)

[0153] While pure constraint solving can guarantee that the data is "valid" (satisfies all constraints), the generated data distribution may differ significantly from the actual production data distribution. For example, if the constraint only specifies "amount ≥ 0 and ≤ 99999.99", the SMT solver may sample evenly within this range, but actual production data may be 80% concentrated in the 100-5000 range. If the test data distribution differs too much from production, some bugs that are common in the production environment but near the constraint boundaries may be missed in testing (because the test data rarely hits those areas).

[0154] The M5 module samples recent real traffic from the production environment's API gateway or monitoring system (the default sampling window is the last 14 days, and the sampling rate is configurable from 0.1% to 1%, with data involving PII personal privacy information being anonymized first), performs statistical analysis on each key field, and fits a probability distribution model: For continuous numerical fields (such as amount, quantity, latitude and longitude): use kernel density estimation (KDE) or Gaussian mixture model (GMM, automatically select the number of components K=1-5 through the BIC criterion) to fit the distribution, then sample values ​​from the fitted distribution to generate values, and then project them back into the range allowed by the constraints (truncate samples that exceed the boundary).

[0155] Discrete / enumerated fields (such as order status, payment method): Calculate the frequency of occurrence of each enumerated value as a probability distribution, sample according to multinomial distribution, and set a minimum guarantee ratio for low-frequency enumerated values ​​(such as at least 5% of the test data using low-frequency values ​​to ensure coverage).

[0156] String fields (such as name, address, description text): Use an n-gram language model (bigram / trigram) or a lightweight LLM (such as TinyLlama-1.1B) to generate text that conforms to the "style" of production data, while satisfying the pattern / length constraints in FORMAT_C.

[0157] The timestamp field is used to analyze the time patterns of production data (weekdays vs. weekends, daytime vs. nighttime, seasonal trends, etc.) and generate timestamps in ISO-8601 format that conform to the same time distribution pattern.

[0158] The output of M5 is a "distribution-aware sampler" object. When M4 needs to generate a specific value for a field, it first samples from the fitted distribution of M5; only when the sampled values ​​violate the hard constraints does it fall back to uniform / random sampling. This dual control of "soft distribution + hard constraints" ensures both the authenticity and legality of the data.

[0159] (6) Data lineage tracking and conflict resolution module (M6)

[0160] M6 establishes a complete lineage tracing map for each synthesized test data, recording the origin and evolution of each field value. The data structure of the lineage record is as follows: LineageRecord = { fieldPath, value, sourceType, sourceDetail, propagationPath, conflictFlag}; Where sourceType ∈ {"seed" (user seed value), "solved" (SMT solution), "sampled" (distributed sampling), "propagated" (constraint propagation inheritance), "default" (default value)}; When a conflict occurs during constraint propagation (such as a field receiving inconsistent value requirements from two different propagation paths), M6 executes the following resolution strategies: (a) Priority arbitration, sorted by data source priority (explicit user-specified > production sampled value > SMT solved value > propagated inherited value > default value), with higher priority prevailing; (b) Conflict reporting, regardless of the arbitration result, the conflict event is recorded in the conflict log (including timestamp, involved fields, values ​​of both conflicting parties, arbitration result, and reason for the ruling) for post-event auditing; (c) Conflict hotspot analysis, regularly compiling statistics on frequently conflicting fields and conflict types, and providing feedback to the API design team to promote contract standardization (e.g., if two APIs have inconsistent format conventions for the same orderId, they should be unified).

[0161] (7) Test dataset assembly and export module (M7)

[0162] M7 is responsible for assembling the test parameter values ​​of the various APIs produced by M4-M6 into a directly usable test dataset. Supported output formats include: (a) Postman Collection v2.1 format (JSON file, which can be directly imported into Postman / Insomnia for execution); (b) pytest / unittest parameterized fixture format (Python code snippets); (c) JUnit5 @CsvSource format (CSV file); (d) custom template format (users define the output format through Mustache / Handlebars templates). Each test dataset entry includes: request body, expected response assertion (assertion automatically generated based on params_out + constraints_out), data lineage summary (optional), and covered constraint labels (such as "boundary - lower limit of amount", "abnormal - illegal enumeration", "normal - HappyPath", etc.), which helps testers understand the design intent of each data entry.

[0163] The overall execution flow of the cross-interface consistency test data synthesis system based on interface contract graphs, that is, the complete execution flow of the cross-interface consistency test data synthesis method based on interface contract graphs in this application, is carried out in the following steps: S1. Contract Extraction: M1 extracts the input and output constraint information of all API interfaces in the system from various data sources such as OpenAPI specification files, code annotations, interface documents, and production traffic sampling, and formalizes it into a unified contract tuple representation.

[0164] S2. Graph Construction: M2 constructs the extracted N API contracts into a directed weighted interface contract graph G=(V,E,W), and detects and marks isolated nodes and strongly connected components (SCC).

[0165] S3. Seed Value Reception: Receives the test scenario seed value specified by the user (can be empty, in which case the system will generate it automatically; or can be partially specified, such as "I want to test a VIP user's return scenario", and the system will set some parameter values ​​of the starting API accordingly).

[0166] S4. Forward Constraint Propagation: Starting from the parameters with known values, M3 performs forward constraint propagation along the directed edges of the graph, narrowing the range of values ​​for each API parameter until a propagation fixed point is reached. Tarjan's loop-breaking strategy is applied to SCC.

[0167] S5. Backward Constraint Propagation (Optional): If the user specifies the target constraint on the output side (such as "statusCode must be 200 in the final response"), M3 performs back propagation from the target constraint along the reverse side to further tighten the required range of the initial input parameters.

[0168] S6. SMT Solving and Data Synthesis: M4 compiles all propagated constraints into SMT formulas and calls the Z3 solver to solve them. The SAT results are deserialized into JSON request / response bodies, and a "1+N" boundary probing strategy is applied to generate a normal + boundary + anomalous data family. For UNSAT results, a minimum conflict subset report is output.

[0169] S7. Distribution-aware sampling: For fields marked as "free variables" (fields with only type constraints but no specific range constraints) in the M4 solution, M5 samples and fills them from the production flow fitted distribution to increase the realism of the data.

[0170] S8. Lineage Recording and Conflict Resolution: M6 creates a LineageRecord for each field of each test data, detects and resolves propagation conflicts, and records conflict logs.

[0171] S9. Assembly and Export: M7 assembles and outputs the complete test dataset in the format selected by the user, with each data point accompanied by a coverage label and lineage summary.

[0172] In a specific embodiment, the cross-interface consistency test data synthesis system based on interface contract graph provided in this application, also known as the cross-API consistency test data synthesis and constraint propagation system based on interface contract graph, includes: an interface contract automatic extraction and modeling module for extracting and formalizing API constraints from multiple sources; a directed weighted interface contract graph construction module for constructing a directed weighted graph of API relationships and detecting SCCs; a bidirectional constraint propagation engine for performing forward / reverse constraint propagation and loop breaking; an SMT constraint solving and data synthesis module for compiling constraints into SMT formulas and solving to generate test data and boundary variants; a production flow distribution fitting module for learning field distributions from production flow and sampling and filling; a data lineage tracing and conflict resolution module for establishing data lineage records and resolving propagation conflicts; and a test dataset assembly and export module for outputting a complete test dataset in multiple formats.

[0173] In another embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown, it includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores relevant data. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. The computer program can be executed by the processor to implement the various methods described in the above embodiments.

[0174] In yet another embodiment, a computer device is provided, such as a terminal, whose internal structure diagram may be as follows: Figure 4As shown, it includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. The computer program can be executed by the processor to implement the various methods described in the above embodiments.

[0175] Those skilled in the art will understand that Figure 3 and Figure 4 The structure shown is only a block diagram of a part of the structure related to the present application and does not constitute a limitation on the computer device on which the present application is applied. It may also include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements, in order to realize the function of the computer device.

[0176] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0177] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the systems, devices, equipment, modules or units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0178] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0179] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0180] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0181] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0182] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (e.g., a solid-state drive), etc.

[0183] The technical solutions provided by the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.

Claims

1. A method for synthesizing cross-interface consistency test data based on interface contract graphs, characterized in that, The method includes: The input and output constraint information of each interface is automatically extracted from the preset data source, and the input and output constraint information is formalized to obtain a unified contract tuple representation data. Based on the unified contract tuple representation data, interface contract construction processing is performed to obtain a directed weighted interface contract graph. Receive the test scenario seed value specified by the user, and perform forward constraint propagation along the directed edge direction of the directed weighted interface contract graph according to the test scenario seed value to obtain the data after forward constraint propagation; In response to the user-specified output-side target constraint, reverse constraint propagation is performed from the output-side target constraint along the opposite direction of the directed edge based on the forward constraint propagation data, to obtain the reverse constraint propagation data; The strongly connected components detected in the graph corresponding to the data after the reverse constraint propagation are subjected to cycle dependency breaking processing to determine the bidirectional propagation data after the breaking process. The propagation constraints corresponding to the bidirectional propagation data are compiled into satisfiability modulus theory formulas, and the satisfiability modulus theory solver is called to solve the satisfiability modulus theory formulas to obtain the solved data. The solved data is assembled and output according to the user-selected format to obtain a complete test dataset.

2. The method according to claim 1, characterized in that, The interface contract construction process based on the unified contract tuple representation data yields a directed weighted interface contract graph, including: The vertex set and directed edge set of the directed weighted interface contract graph are constructed. The coupling weight is calculated based on the data coupling degree score, the frequency weight is determined based on the normalized value of the actual call frequency, and the confidence weight is obtained based on the deterministic score of the preset data source. The edge weight data of the directed weighted interface contract graph is obtained by weighted summation based on the coupling weight, the frequency weight, and the confidence weight. Based on the vertex set, the directed edge set, and the edge weight data, the directed weighted interface contract graph is constructed.

3. The method according to claim 1, characterized in that, The process of performing cycle dependency breaking on the strongly connected components detected in the graph corresponding to the data after the reverse constraint propagation, and determining the bidirectional propagation data after the breaking, includes: The strongly connected components in the graph corresponding to the data after the reverse constraint propagation are identified using a time-complexity algorithm. Select the edge with the smallest edge weight in the strongly connected component as the virtual broken edge to perform the cycle breaking process, and obtain the directed acyclic graph after the cycle breaking process. Bidirectional constraint propagation is performed on the directed acyclic graph after the destructive process, and posterior compatibility verification is performed on both ends of the broken edge of the directed acyclic graph after the destructive process to determine the data after bidirectional propagation.

4. The method according to claim 1, characterized in that, The process involves compiling the propagated constraints corresponding to the bidirectional propagated data into satisfiability modulus theory formulas, calling a satisfiability modulus theory solver to solve the satisfiability modulus theory formulas, and obtaining the solved data, including: Deserialize the satisfactory results to obtain the request or response test data of each interface, and apply the boundary detection strategy to automatically generate variant data families covering boundary values ​​and outliers based on each normal data. Output a minimum conflict subset report for unsatisfiable results; The solved data is determined based on the variant data family and the minimal conflict subset report.

5. The method according to claim 1, characterized in that, The process involves compiling the propagated constraints corresponding to the bidirectional propagated data into satisfiability modulus theory formulas, calling a satisfiability modulus theory solver to solve the satisfiability modulus theory formulas, and obtaining the solved data, including: A fitting probability distribution model is constructed based on the interface traffic sampling data of the production environment, and the fitting distribution data is output according to the fitting probability distribution model. In the process of solving the satisfiability modulus formula, if specific values ​​need to be generated for the fields, the field values ​​are sampled from the fitted distribution data and projected back to the constraint allowable range. The solved data is obtained by solving the field values ​​projected back to the constraint allowable range.

6. The method according to claim 1, characterized in that, Before the step of assembling and outputting the solved data in a user-selected format to obtain a complete test dataset, the method further includes: Establish a data lineage record for each field of each synthetic test data corresponding to the solved data; In the event of a conflict arising during the propagation of constraints in the data lineage record representation process, the conflict resolution process is carried out according to the data source priority strategy to obtain the result data of the conflict resolution process.

7. The method according to claim 6, characterized in that, The priority order, from highest to lowest, as represented in the data source priority strategy is as follows: The test scenario seed value explicitly specified by the user, the sampled fill field value in the fitted distribution data, the satisfiability modulus solution value corresponding to the solved data, the propagation inheritance value, and the default value.

8. A cross-interface consistency test data synthesis system based on interface contract graph, characterized in that, The system includes: The interface contract automatic extraction and modeling module is used to automatically extract the input and output constraint information of each interface from a preset data source, perform formal processing on the input and output constraint information, and obtain a unified contract tuple representation data. The directed weighted interface contract graph construction module is used to perform interface contract construction processing based on the unified contract tuple representation data to obtain a directed weighted interface contract graph. The forward constraint propagation module is used to receive the test scenario seed value specified by the user, and perform forward constraint propagation along the directed edge direction of the directed weighted interface contract graph according to the test scenario seed value to obtain the data after forward constraint propagation. The reverse constraint propagation module is used to respond to the output-side target constraint specified by the user, and perform reverse constraint propagation from the output-side target constraint along the reverse direction of the directed edge based on the forward constraint propagation data to obtain the reverse constraint propagation data. The cycle dependency breaking module is used to perform cycle dependency breaking processing on the strongly connected components detected in the graph corresponding to the data after the reverse constraint propagation, and to determine the bidirectional propagation data after the breaking; The constraint solving and data synthesis module is used to compile the propagated constraints corresponding to the bidirectional propagated data into satisfiability modulus theory formulas, call the satisfiability modulus theory solver to solve the satisfiability modulus theory formulas, and obtain the solved data. The test dataset assembly and export module is used to assemble and output the solved data according to the user-selected format to obtain a complete test dataset.

9. A computer device, characterized in that, The computer device includes: At least one processor and memory; The memory is used to store program code, and the processor is used to call the program code stored in the memory to execute the method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, It includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images