A test data generation method and device, electronic equipment and medium

Abstract

The application provides a test data generation method and device, electronic equipment and medium. The method comprises: constructing a multi-system association model and constraint rule data by data association analysis and constraint extraction on system description data of a plurality of business systems, and extracting to-be-generated data, cross-system field mapping relationship and data constraint conditions in combination with test scenario requirements; further, performing constrained data instantiation on the to-be-generated data according to a data attribute matching target generation mode, and performing field value transmission and synchronization between associated fields of different business systems. Thus, the test data generation method can reduce the amount of data generation irrelevant to the current test scenario, make data of different attributes adopt a matching generation path, and reduce the probability of inconsistent values, association rupture and repeated configuration of cross-system shared fields, thereby improving the consistency and reusability of multi-system test data generation.

Description

Technical Field

[0001] This application belongs to the field of data processing technology and relates to a test data generation method, apparatus, electronic device and medium. Background Technology

[0002] As information systems evolve towards platformization, distribution, and multi-business collaboration, data interaction between different business systems is becoming increasingly frequent, and business processes typically span multiple systems, interfaces, and data processing stages. During software development, system integration, and operation and maintenance, it is necessary to configure corresponding test data for different business scenarios to conduct functional verification, interface verification, process verification, and system integration testing activities. The generation and management of test data has become a crucial aspect of ensuring the successful implementation of multi-business system testing.

[0003] The existing test data generation process suffers from several issues, including incomplete representation of data relationships between multiple business systems, difficulty in uniformly matching constraints of different data fields, and insufficient consistency in field values ​​across systems. This leads to test data prone to field value conflicts, broken business links, or incomplete scenario coverage. Furthermore, the test data generation method lacks adaptability to different data types and test scenarios, making it difficult to balance efficiency, completeness, and consistency in test data generation. Summary of the Invention

[0004] This application provides a test data generation method, apparatus, electronic device, and medium to solve the problems of incomplete data association, difficulty in uniformly matching data constraints, and insufficient consistency of field values ​​across systems in the process of generating test data for multiple business systems in the prior art.

[0005] Firstly, this application provides a method for generating test data, including:

[0006] Obtain system description data from multiple business systems, perform data association parsing and constraint extraction on the system description data, and obtain multi-system association model and constraint rule data;

[0007] Receive test scenario requirements, perform association matching between the test scenario requirements and the multi-system association model, extract the data to be generated and the cross-system field mapping relationship corresponding to the data to be generated from the association matching results, and extract the data constraint conditions corresponding to the data to be generated from the constraint rule data.

[0008] The data attributes of the data to be generated are matched with the preset data generation conditions to obtain the target generation method corresponding to each data to be generated. The data to be generated is instantiated according to the target generation method and the data constraints. The instantiated data is collected to form an initial test dataset.

[0009] According to the cross-system field mapping relationship, extract the data fields that belong to different business systems and are related to each other from the initial test dataset. Based on the cross-system field mapping relationship, perform field value transfer and synchronization between the related data fields to obtain the target test dataset.

[0010] In one implementation of the first aspect, before instantiating the data to be generated, the method further includes:

[0011] The business attributes of the data to be generated are matched with preset priority rules to obtain the generation priority corresponding to each data to be generated;

[0012] The data to be generated is sorted according to the generation priority to obtain a data generation sequence, and the data to be generated is instantiated sequentially according to the data generation sequence.

[0013] In one implementation of the first aspect, the method further includes, during the process of forming the initial test dataset:

[0014] Record the data generation source and field association information corresponding to each data item in the initial test dataset to form a data tracking record;

[0015] The data tracking records are associated and stored with the corresponding data in the initial test dataset.

[0016] In one implementation of the first aspect, after obtaining the target test dataset, the method further includes:

[0017] The data in the target test dataset are classified according to business attributes and usage scenarios, and the classified data is then version-marked and stored accordingly.

[0018] Receive incremental test data requests, extract new or changed fields from the incremental test data requests, extract cross-system field mapping relationships corresponding to the new or changed fields from the multi-system association model, and extract data constraint conditions corresponding to the new or changed fields from the constraint rule data.

[0019] The data attributes of the newly added or changed fields are matched with the preset data generation conditions to obtain the corresponding incremental generation method. According to the incremental generation method and the extracted data constraints, the newly added or changed fields are instantiated. Based on the extracted cross-system field mapping relationship, the field values ​​of the instantiated data are passed and synchronized. The synchronized data is written into the test data of the corresponding version.

[0020] The data stored in categories is matched with preset cleanup conditions, and the data that meets the preset cleanup conditions is deleted, and the corresponding data cleanup information is recorded.

[0021] In one implementation of the first aspect, the system description data includes interface information, a data dictionary, and a business process description; the step of performing data association parsing and constraint extraction on the system description data to obtain a multi-system association model and constraint rule data includes:

[0022] The interface information and the data dictionary are structured and parsed to obtain interface description data, and the business process description is decomposed to obtain a directed business process graph.

[0023] The interface description data is clustered by interface affiliation to obtain multiple system nodes, and data nodes are extracted from the interface parameters corresponding to each system node.

[0024] Field matching is performed on data nodes belonging to different system nodes, and the cross-system association mapping is performed on the data nodes by combining the data flow path in the business process directed graph and the upstream and downstream interface parameter transmission relationship in the interface description data to obtain the multi-system association model.

[0025] Data format constraints, value range constraints, business logic constraints, and cross-system association constraints are extracted from the interface information, the data dictionary, and the business process description. The extracted constraints are then classified and structured to obtain the constraint rule data.

[0026] In one implementation of the first aspect, the step of instantiating the data to be generated according to the target generation method and the data constraints, and collecting the instantiated data to form an initial test dataset, includes:

[0027] When the target generation method is static generation, the generation mode is deduced for the data constraints, and the data generator corresponding to the deduced generation mode is called to generate field values ​​to obtain the corresponding instantiated test data; or, a preset data template corresponding to the data to be generated is loaded, the variable values ​​corresponding to the placeholders of each variable in the preset data template are obtained, and the variable values ​​are filled into the preset data template to obtain the corresponding instantiated test data.

[0028] When the target generation method is dynamic generation, the parameter values ​​corresponding to the data to be generated and satisfying the data constraints are obtained, the parameter values ​​are filled into the parameterized traffic template, a request message is generated, the request message is replayed, and the corresponding response message is obtained. The request message and the response message are associated to form corresponding instantiated test data; or, based on the received interaction request, the interaction request is matched with a preset matching rule, and the data of the matched response template is filled to obtain a response message. The interaction request and the response message are associated to form corresponding instantiated test data.

[0029] When the target generation method is a model generation method, the data to be generated and the corresponding data constraints are input into the generative model to generate data records, and the generated data records are determined as the corresponding instantiated test data.

[0030] The instantiated test data is collected to form the initial test dataset.

[0031] In one implementation of the first aspect, the step of transferring and synchronizing field values ​​between the interrelated data fields based on the cross-system field mapping relationship includes:

[0032] Based on the cross-system field mapping relationship, the source data field and target data field corresponding to the same data object are determined from the interrelated data fields, the field value of the source data field is extracted, and the extracted field value is written into the target data field corresponding to each business system in the initial test dataset;

[0033] Obtain the field value change data of any of the data fields, determine other data fields that are related to the data field whose field value has changed according to the cross-system field mapping relationship, and write the changed field value into the other data fields.

[0034] Secondly, this application provides a test data generation apparatus. The apparatus includes:

[0035] The data acquisition module is used to acquire system description data from multiple business systems, perform data association parsing and constraint extraction on the system description data, and obtain multi-system association model and constraint rule data.

[0036] The requirement acquisition module is used to receive test scenario requirements, perform association matching between the test scenario requirements and the multi-system association model, extract the data to be generated and the cross-system field mapping relationship corresponding to the data to be generated from the association matching result, and extract the data constraint conditions corresponding to the data to be generated from the constraint rule data.

[0037] The data matching module is used to match the data attributes of the data to be generated with the preset data generation conditions to obtain the target generation method corresponding to each data to be generated, and to instantiate the data to be generated according to the target generation method and the data constraints, and to collect the instantiated data to form an initial test dataset.

[0038] The data extraction module is used to extract data fields belonging to different business systems and related to each other from the initial test dataset according to the cross-system field mapping relationship, and to transfer and synchronize field values ​​between the related data fields based on the cross-system field mapping relationship to obtain the target test dataset.

[0039] Thirdly, this application provides an electronic device. The electronic device includes: a memory for storing a computer program; and a processor for executing the computer program stored in the memory to cause the electronic device to perform the test data generation method as described in any one of the first aspects.

[0040] Fourthly, this application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed by a processor, implements the test data generation method described in any one of the first aspects.

[0041] As described above, the test data generation method, apparatus, electronic device, and medium of this application have the following beneficial effects:

[0042] By performing data association parsing and constraint extraction on system description data from multiple business systems, the data association information and data constraint information scattered in different business systems are respectively formed into multi-system association models and constraint rule data. After receiving test scenario requirements, the data to be generated, cross-system field mapping relationships and data constraints corresponding to the current test scenario are extracted from them, so that the scope of subsequent test data generation can be limited to data objects actually associated with the current test scenario, reducing the generation of data unrelated to the current test task.

[0043] Furthermore, by matching the data attributes of the data to be generated with the preset data generation conditions, the corresponding target generation method is selected for the data to be generated with different attributes, and the data is instantiated in combination with the data constraints, so that the generated data can simultaneously meet the corresponding data type, value range and business constraints, reducing the number of regeneration and verification times caused by not meeting the constraints after generation.

[0044] After forming the initial test dataset, the data fields belonging to different business systems and related to each other are identified according to the cross-system field mapping relationship. Field values ​​are then passed and synchronized between related fields to ensure that the corresponding fields of the same business data remain consistent across multiple business systems, reducing test data failures caused by cross-system field value mismatches.

[0045] Therefore, this application can simultaneously complete test data range filtering, generation method matching, constraint instantiation, and cross-system field synchronization during a single test data generation process, reducing the proportion of invalid data, constraint conflict data, and cross-system inconsistent data generated in multi-system test scenarios, and reducing the need for repeated generation, manual adjustment, and cross-system verification operations for the aforementioned abnormal data. Attached Figure Description

[0046] Figure 1 The diagram shows an application scenario of the test data generation method described in the embodiments of this application.

[0047] Figure 2 The diagram shown is a flowchart illustrating the test data generation method described in an embodiment of this application.

[0048] Figure 3 This is another flowchart illustrating the test data generation method described in an embodiment of this application.

[0049] Figure 4 This is another flowchart illustrating the test data generation method described in an embodiment of this application.

[0050] Figure 5 The diagram shown is a structural schematic of the test data generation device described in an embodiment of this application.

[0051] Figure 6 The diagram shown is a structural schematic of the electronic device described in an embodiment of this application.

[0052] Component designation explanation:

[0053] 100: Test data generation device; 110: Data acquisition module; 120: Demand acquisition module; 130: Data matching module; 140: Data extraction module; 200: Electronic device; 210: Memory; 220: Processor; 230: Display;

[0054] S100~S400: Steps;

[0055] S101~S104: Steps;

[0056] S301~S304: Steps. Detailed Implementation

[0057] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0058] The technical solutions of the embodiments of this application will be described in detail below with reference to the accompanying drawings. This will enable those skilled in the art to understand and implement the methods of this embodiment without creative effort.

[0059] Figure 1 This diagram illustrates an application scenario of the test data generation method in this application. For example... Figure 1 As shown, this application environment includes multiple interconnected business systems, a test data generation system, and data storage units for storing test data and related rule data. The multiple business systems can be applied to collaborative scenarios involving multiple systems such as e-commerce, government statistics, and financial accounting, forming data dependencies between systems through interface calls, data interactions, or business processes. The test data generation system is used to obtain interface information, data dictionaries, and business process descriptions from each business system and generate test data adapted to the corresponding test scenarios. The generated test data can be further used for joint debugging, functional testing, performance testing, anomaly testing, or regression testing of multiple business systems.

[0060] Figure 2 This is a flowchart illustrating the test data generation method in an embodiment of this application. For example... Figure 2 As shown, the test data generation method provided in this application includes the following steps.

[0061] Step S100: Obtain system description data from multiple business systems, perform data association parsing and constraint extraction on the system description data, and obtain multi-system association model and constraint rule data.

[0062] System description data represents the data structure, interface interaction methods, and business processing flow of a business system, such as interface information, data dictionaries, and business process descriptions. The multi-system association model is a data model representing the data flow, data dependencies, and data mapping between multiple business systems, including system nodes, data nodes, and the association mappings between different data nodes. Constraint rule data is data-generated constraints extracted and structured from the system description data of multiple business systems, such as data format constraints, value range constraints, business logic constraints, and cross-system association constraints.

[0063] For example, the system acquires interface documents, data dictionaries, and business process descriptions for multiple business systems. It then performs structured parsing of interface names, request parameters, response parameters, parameter types, and parameter constraints in the interface documents and data dictionaries, and identifies business nodes, flow conditions, and data dependencies in the business process descriptions. Furthermore, it groups interfaces belonging to the same business domain or calling the same basic services, extracts business-meaning data nodes from the corresponding interface parameters, and associates data nodes belonging to different business systems to form a multi-system association model describing data flow, dependencies, and data interaction paths between multiple business systems.

[0064] Simultaneously, corresponding constraint information is extracted from interface information, data dictionary, and business process description. The constraint information is then classified and structured to form constraint rule data.

[0065] Specifically, interface information and data dictionaries can be parsed to form structured interface description data, and business process descriptions can be broken down into directed business process graphs. Cross-system data relationships are established through field name matching, data flow paths in business processes, and parameter passing relationships between upstream and downstream interfaces.

[0066] For example, fields with different names but the same business meaning are mapped according to the similarity of field names and business semantics; data nodes located in the upstream and downstream of the business process and with parameter passing are associated according to the corresponding data flow path.

[0067] Each constraint is organized into a structured rule record according to its applicable object and constraint type. Each rule record includes information such as rule identifier, rule type, applicable object, constraint condition expression, verification method and priority.

[0068] By transforming interface data, business process data, and field constraints from different business systems into structured data with clear data node relationships and constraint representations, a multi-system data association foundation is formed for test scenario requirement analysis and test data generation.

[0069] Step S200: Receive test scenario requirements, perform association matching between test scenario requirements and multi-system association model, extract the data to be generated and the cross-system field mapping relationship corresponding to the data to be generated from the association matching results, and extract the data constraint conditions corresponding to the data to be generated from the constraint rule data.

[0070] The test scenario requirements describe the business scenarios and data requirements involved in the current test task, such as the test scenario type, test coverage, and test data volume. The data to be generated refers to data items that match the current test scenario and need to form specific test data. Cross-system field mapping relationships are mapping relationships between data fields belonging to different business systems but corresponding to the same business data or having data transfer relationships. Data constraints are the data format, value range, mandatory requirements, business logic, or cross-system association requirements associated with the data to be generated.

[0071] As an example, upon receiving a test scenario requirement, the scenario type, data range, and other information in the requirement are matched with system nodes, data nodes, and data interaction paths in the multi-system association model. The data to be generated for the current test scenario is extracted from the matched data nodes, and the field mapping information of each data to be generated in different business systems is further read. Subsequently, using the data node or data field corresponding to the data to be generated as an index, the associated field type, field length, value range, required conditions, and business constraints are extracted from the constraint rule data to form the corresponding data constraints.

[0072] For example, in a financial institution deposit scenario, the test scenario requirements include personal customers, debit cards, deposits, and mobile banking signing. By matching with a multi-system association model, customer data, debit card data, deposit data, and signing data are identified, and the mapping relationships of cross-system shared fields such as customer number, ID number, and card number are extracted. At the same time, corresponding constraints such as customer age, mobile phone number length, ID number format, card number format, and deposit amount are read from the constraint rule data.

[0073] Specifically, the matching results between the test scenario requirements and the multi-system association model limit the system nodes, data nodes, and data interaction paths involved in the current test scenario. Based on this, the corresponding data fields are further extracted, ensuring that subsequent data generation processes only handle data associated with the current test scenario. For the same data to be generated, the corresponding constraint records can also be retrieved from the constraint rule data using the corresponding data node or field identifier.

[0074] This step maps test scenario requirements to a pre-formed multi-system data structure and simultaneously extracts the corresponding data constraints and cross-system field mapping relationships, thereby converting test scenario requirements into specific data objects for subsequent data instantiation processing.

[0075] Step S300: Match the data attributes of the data to be generated with the preset data generation conditions to obtain the target generation method corresponding to each data to be generated. In accordance with the target generation method and data constraints, instantiate the data to be generated, and collect the instantiated data to form the initial test dataset.

[0076] Here, data attributes are those that characterize the generation scenario and data form of the data to be generated. Preset data generation conditions refer to the applicable conditions for different data generation methods. The target generation method refers to the data generation method that matches the data attributes of the data to be generated, such as static generation, dynamic generation, or model generation. Data instantiation refers to the process of converting the data to be generated and its constraints into specific data records, such as generating field values ​​according to data rules, forming structured data using templates, forming test data through interactive data, or forming data records through generative models.

[0077] As an example, the data attributes of the data to be generated are read, and the data attributes are matched with the generation conditions corresponding to different data generation methods.

[0078] For basic data with fixed format or fixed constraints, match the static generation method;

[0079] For data that needs to simulate real-time interaction between multiple business systems, a dynamic generation method should be used.

[0080] For abnormal or boundary data, match the model generation method.

[0081] After determining the target generation method, the data constraints corresponding to the data to be generated are used as the basis for data processing in the generation process, forming data records that meet the corresponding constraints, and the data records corresponding to different data to be generated are collected into the initial test dataset.

[0082] Specifically, static generation methods employ either generation pattern derivation or template filling.

[0083] Dynamic generation methods employ either traffic recording and playback or baffle simulation.

[0084] The model generation method utilizes generative models to generate structured data records according to target fields and constraints.

[0085] Although each generation path uses a different data instantiation mechanism, they all take the data to be generated and the data constraints obtained in step S200 as the processing objects, and finally form specific data that can be aggregated into the initial test dataset.

[0086] This step selects the appropriate data instantiation mechanism according to the data attributes of the data to be generated. It can perform corresponding data generation processing for fixed data, real-time interactive data, and abnormal or boundary data, and unify the data generated by different generation paths into an initial test dataset.

[0087] Step S400: According to the cross-system field mapping relationship, extract the data fields that belong to different business systems and are related to each other in the initial test dataset. Based on the cross-system field mapping relationship, perform field value transfer and synchronization between the related data fields to obtain the target test dataset.

[0088] Interrelated data fields refer to data fields that exist in the data structures of different business systems but correspond to the same business data or have data transfer dependencies. Examples include customer number fields, ID number fields, or card number fields in different business systems. Field value transfer and synchronization refers to writing the data values ​​corresponding to related fields into the corresponding fields according to the cross-system field mapping relationship, and synchronizing the changed field value to other related fields when the data value of one related field changes.

[0089] As an example, the initial test dataset is traversed according to the cross-system field mapping relationship. Data fields with mapping relationships are extracted from the data records corresponding to different business systems. The source data fields and target data fields are determined based on the data flow path and upstream and downstream interface parameter transmission relationship in the multi-system association model. The field values ​​of the source data fields are extracted and written into the target data fields corresponding to each business system. When the field value of any associated data field changes, other associated data fields are determined according to the cross-system field mapping relationship, and the changed field value is written into the other associated data fields.

[0090] Specifically, the data transfer of shared fields across systems can be tracked by combining the data source and data association information recorded during the test data generation process. When related data in a certain business system changes, fields in other business systems that have a mapping relationship with that field are retrieved, and the corresponding field values ​​are updated synchronously. For example, when the customer number in the customer information management system is adjusted, the customer numbers in other related business systems are updated synchronously according to the existing mapping relationship.

[0091] This step maintains the data correspondence between shared data across different business systems by performing field value transfer and change synchronization between related data fields in different business systems, thereby reducing the occurrence of mismatches in related data between test data of different business systems.

[0092] In one implementation of this embodiment, before instantiating the data to be generated, the test data generation method provided in this application embodiment further includes:

[0093] The business attributes of the data to be generated are matched with preset priority rules to obtain the generation priority of each data item. The data to be generated are sorted according to the generation priority to obtain a data generation sequence, and the data to be generated are instantiated sequentially according to the data generation sequence.

[0094] Priority is used to define the order in which different data to be generated is generated. For example, core business master data can be configured as level P0, core business related data as level P1, auxiliary business data as level P2, and edge data or abnormal data as level P3.

[0095] As an example, after obtaining the data to be generated, the business attributes corresponding to each piece of data are read, the business attributes are matched with the data categories in the preset priority rules, and a corresponding generation priority is configured for each piece of data. After the priority configuration is completed, the data to be generated is sorted according to the generation priority, and data instantiation is performed sequentially according to the sorting results.

[0096] For example, in a deposit testing scenario, core business master data such as customer number, account number, and card number are generated first, followed by related data such as basic customer information and basic account information, and then auxiliary business data and edge or abnormal data used as needed are generated.

[0097] The business importance and time urgency of the test scenarios are combined and prioritized. Business importance is categorized into core transaction scenarios, master data management scenarios, channel access scenarios, management report scenarios, and auxiliary function scenarios; time urgency is categorized into features to be launched in the current iteration, defect fix verification, regression testing, performance testing, and exploratory testing. The processing order of each test scenario is determined based on the combined results of business importance and time urgency.

[0098] In one implementation of this embodiment, during the formation of the initial test dataset, the test data generation method provided in this application further includes: recording the data generation source and field association information corresponding to each piece of data in the initial test dataset to form a data tracking record. The data tracking record is then associated and stored with the corresponding data in the initial test dataset.

[0099] Among them, the data tracking record is used to record the source of test data generation and the relationship between test data.

[0100] As an example, when generating test data using static, dynamic, or model-based methods, the source of each generated data is recorded, and the association information for data with cross-system sharing or transmission relationships is recorded. This information is then compiled into data tracking records. After the initial test dataset is constructed, each data tracking record is associated with and saved in relation to the corresponding data in the initial test dataset, ensuring that the test data, its source, and association information remain consistent.

[0101] Specifically, for data such as customer numbers and ID numbers that need to be shared between multiple business systems, the relationship between each field is recorded in the corresponding data tracking record; when the fields change later, the corresponding relationship information is used to locate other related data.

[0102] This step saves the generation source and related information of the test data, providing a queryable data association basis for cross-system field value transfer and subsequent data change synchronization.

[0103] In one implementation of this embodiment, after obtaining the target test dataset, the test data generation method provided in this application embodiment further includes:

[0104] The data in the target test dataset is categorized according to business attributes and usage scenarios, and the categorized data is version-marked and stored accordingly. Incremental test data requests are received, and new or changed fields are extracted from these requests. Cross-system field mapping relationships corresponding to the new or changed fields are extracted from the multi-system association model, and data constraints corresponding to the new or changed fields are extracted from the constraint rule data. The data attributes of the new or changed fields are matched with preset data generation conditions to obtain the corresponding incremental generation method. According to the incremental generation method and the extracted data constraints, the new or changed fields are instantiated. Field values ​​are passed and synchronized based on the extracted cross-system field mapping relationships, and the synchronized data is written to the corresponding version of the test data. The categorized and stored data is matched with preset cleanup conditions, and data that meets the preset cleanup conditions is deleted, with the corresponding data cleanup information recorded.

[0105] The newly added fields are those added to the current version of the test data but already recorded in the multi-system association model and constraint rule data. For newly added or changed fields, the corresponding cross-system field mapping relationship is extracted from the multi-system association model, and the corresponding data constraint conditions are extracted from the constraint rule data. After incremental instantiation is completed, the field values ​​of the associated fields are passed and synchronized according to the extracted cross-system field mapping relationship, and then the synchronized data is written into the test data of the corresponding version.

[0106] Categorized storage involves storing different test data separately according to their business attributes, generation methods, or usage scenarios.

[0107] Test data is categorized by business attributes, including core business data, general business data, and temporary test data.

[0108] According to the generation method, it includes static basic data, dynamic interactive data, and model-generated data;

[0109] According to the usage scenario, such as functional test data, performance test data, anomaly test data, and regression test data.

[0110] As an example, after obtaining the target test dataset, the test data is stored according to the corresponding data categories, and version information is recorded for the stored data. When subsequent test requirements only add some fields or some existing fields change, the newly added or changed fields are identified from the incremental test data requirements, their data attributes are matched with preset data generation conditions, the appropriate incremental generation method is selected, and new data is generated according to the corresponding data constraints. This new data is then written into the corresponding version of the data, without having to regenerate all the test data.

[0111] For data that has already been categorized and stored, further configure cleanup rules. Preset cleanup conditions include time conditions, event conditions, or capacity conditions. For example, clean up temporary test data that exceeds the retention period based on the data generation time; clean up corresponding data after the test task ends or the test environment is reset; or clean up data in priority order when the test data storage space reaches a preset usage rate. Cleanup operations can record the cleanup time, the range of data cleaned, the reason for cleanup, and operation information.

[0112] This step involves classifying and storing the target test data, managing its version, generating incremental data, and automatically cleaning it up, thus implementing lifecycle management for the already generated test data.

[0113] In one optional implementation, the generation time, usage scenario, modification history, and cleanup time of the target test dataset are recorded, and different storage and cleanup rules are configured according to core business data, ordinary business data, and temporary test data. Preset cleanup conditions include time conditions, test task completion conditions, test environment reset conditions, and storage capacity conditions; cleanup methods include soft deletion with a retention period and direct physical deletion, and the cleanup time, cleanup data range, cleanup reason, and operation information are recorded.

[0114] In one implementation of this embodiment, such as Figure 3 As shown, step S100 includes the following sub-steps:

[0115] S101 performs structured parsing of the interface information and data dictionary to obtain interface description data, and decomposes the business process description to obtain a directed business process graph.

[0116] S102, perform interface affiliation clustering on the interface description data to obtain multiple system nodes, and extract data nodes from the interface parameters corresponding to each system node.

[0117] S103: Perform field matching on data nodes belonging to different system nodes, and combine the data flow path in the business process directed graph and the upstream and downstream interface parameter transmission relationship in the interface description data to perform cross-system association mapping on data nodes to obtain a multi-system association model.

[0118] S104 extracts data format constraints, value range constraints, business logic constraints, and cross-system correlation constraints from interface information, data dictionary, and business process description, and classifies and structures the extracted constraints to obtain constraint rule data.

[0119] Interface description data is a collection of interface metadata formed after structured parsing of interface information and a data dictionary. It includes interface name, request parameters, response parameters, parameter types, and parameter constraints. A directed business process graph is a data structure that represents a business process using business nodes and the flow direction between nodes. System nodes are system-level nodes formed according to the business affiliation of interfaces; their attributes include system name, interface list, and data dictionary summary. Data nodes are collections of fields with common business meaning extracted from the interface parameters corresponding to system nodes, such as customer basic information nodes, account data nodes, and transaction data nodes.

[0120] For example, in step S101, the collected interface information and data dictionary are parsed in a structured manner to extract interface metadata such as interface name, request parameters, response parameters, parameter types and parameter constraints, and form interface description data; at the same time, the business process description is decomposed to identify business nodes, flow conditions and data dependencies, and form a directed graph of the business process.

[0121] In step S102, the interface attribution information in the interface description data is clustered, and interfaces belonging to the same business domain or calling the same set of basic services are grouped into system nodes. Then, data nodes are extracted from the interface parameters corresponding to each system node according to business semantics, so that one system node can correspond to multiple data nodes, and data nodes that need to be referenced across systems retain the corresponding reference relationship.

[0122] In step S103, field matching is performed on data nodes belonging to different system nodes, and cross-system association mapping is further established by combining the data flow path in the directed graph of the business process and the upstream and downstream interface parameter transmission relationship in the interface description data. For example, synonym field mapping can be established by field name similarity, data association can be identified by the path of data transmission from upstream nodes to downstream nodes in the business process, and association can also be established by the transmission of upstream and downstream interface request parameters and response parameters. After the association is completed, the system nodes, data nodes and corresponding association relationships are organized into a multi-system association model.

[0123] In step S104, constraint information is extracted from interface information, data dictionary, and business process description, and divided into data format constraints, value range constraints, business logic constraints, and cross-system relational constraints. Subsequently, each constraint is converted into structured rule records, forming constraint rule data. The structured rule records contain attributes such as rule identifier, rule type, applicable objects, constraint condition expression, validation method, and priority.

[0124] For example, in the deposit scenario of financial institutions, a unified customer service platform node, customer information management system node, core system node, and mobile banking node are established, and customer basic information node, debit card account node, deposit transaction node, and mobile banking signing node are extracted; corresponding data node associations are established through fields such as customer number, ID number, and card number, and constraints such as mobile phone number length, ID number format, card number format, and consistency of customer number across systems are extracted and formed into constraint rule data.

[0125] In one optional implementation, interface documents, data dictionaries, and business process descriptions from various business systems are collected through application programming interface (API) integration, user interface visual recognition, or precision testing. After structured parsing of the collected data, the interface description data is stored in JSON format, and a scenario topology is formed using system nodes, data nodes, and relationships between nodes. Constraint rule data is also stored in a structured format, with version marking and incremental updates. The accuracy of the constraint rules is verified by replaying sample data, and constraint rules with high misjudgment rates are reviewed and adjusted.

[0126] In one implementation of this embodiment, such as Figure 4 As shown, step S300 includes the following sub-steps:

[0127] S301, when the target generation method is static generation, perform generation mode derivation on the data constraints, call the data generator corresponding to the derived generation mode to generate field values, and obtain the corresponding instantiated test data; or, load the preset data template corresponding to the data to be generated, obtain the variable values ​​corresponding to the placeholders of each variable in the preset data template, and fill the variable values ​​into the preset data template to obtain the corresponding instantiated test data.

[0128] S302, when the target generation method is dynamic generation, obtain the parameter values ​​corresponding to the data to be generated and satisfying the data constraints, fill the parameter values ​​into the parameterized traffic template, generate a request message, perform traffic replay on the request message, obtain the corresponding response message, and associate the request message and the response message to form corresponding instantiated test data; or based on the received interaction request, match the interaction request with the preset matching rules, fill the data into the matched response template to obtain a response message, and associate the interaction request and the response message to form corresponding instantiated test data.

[0129] S303, when the target generation method is model generation method, input the data to be generated and the corresponding data constraints into the generative model to generate data records, and determine the generated data records as the corresponding instantiated test data.

[0130] S304, gathers instantiated test data to form the initial test dataset.

[0131] Among them, the generation pattern refers to the field value generation rules derived from data constraints; the parameterized traffic template refers to the reusable message template formed by replacing the variable fields in the original interactive traffic with parameter placeholders; the response template refers to the data template used to form response messages during the baffle simulation process, such as including response status codes, response headers and response bodies; and the generative model refers to the model that generates structured data records based on target fields and constraints.

[0132] As an example, during the generation pattern derivation process in step S301, the data type, length, value range, or regular expression constraints of the target field are read, and the corresponding data generation strategy is selected according to the constraint type. For example, numeric fields generate field values ​​according to their numerical range, string fields generate field values ​​according to the corresponding regular expression, and date fields generate field values ​​according to the corresponding time interval. For data to be generated using template filling, a data template with fixed fields and variable placeholders is loaded, variable values ​​are obtained from the rule generation results, dictionary, or sequence generator, and written to the corresponding placeholder positions to form a complete data record.

[0133] When data dependencies exist between different fields, a dependency topology order is formed based on these dependencies, and field values ​​are generated sequentially according to this order. A pre-defined data template includes template metadata, field definitions, and variable placeholders. The template metadata includes a template identifier, template name, applicable scenarios, and version information. Field definitions include field names, field types, and field lengths. Pre-defined data templates may also include conditional branches, loop structures, or function calls.

[0134] During traffic recording and playback, request and response messages in the test environment are collected. The collected messages are parsed according to the protocol and structured traffic records are generated based on timestamps. Variable and fixed fields are identified by comparing multiple calls to the same interface. Variable fields are replaced with parameter placeholders, and parameter dependencies are established based on business relationships between parameters. During playback, parameter values ​​corresponding to the current test scenario are filled into the parameter placeholders, a request message is generated and sent to the target business system, and the response message returned by the target business system is obtained.

[0135] During the block simulation process, a response template is selected based on the request path and request parameters, using exact matching, regular expression matching, conditional matching, or default matching. The request parameters, context data, simulated database data, or randomly generated data are then filled into the response template. Block simulation can also generate delayed responses, service unavailability responses, abnormal format responses, or rate-limited responses based on preset conditions.

[0136] In step S303, when using a generative model, a Transformer-based generative pre-trained model is employed in conjunction with a conditional variational autoencoder to model the data distribution. Constraints such as the data type, value range, and business rules corresponding to the fields to be generated are encoded into corresponding representations, and a sequence of field values ​​satisfying these constraints is generated accordingly. The generated data is in the form of structured records, with each record containing the target field and its value corresponding to the current data to be generated.

[0137] Specifically, after the generative model generates data records, a data validation process verifies the constraint satisfaction of the generated records. Then, a batch database write operation stores the validated data records into the database. The database's primary key, foreign key, or unique index can further perform corresponding constraint checks on the written data.

[0138] The training data for the generative model includes anonymized historical business data, historical test data, and sample data constructed according to business rules. The model receives the target field, field constraints, field relationships, and the number of records to be generated, producing structured data records containing the target field and its values. During data record generation, constraint satisfaction is verified on the generated results; data that fails verification is regenerated; data that passes verification is written to the database in batches, and corresponding generation logs and data tracking information are recorded.

[0139] In step S304, the instantiated test data generated in steps S301 to S303 are aggregated to form an initial test dataset. In other words, data generated by different target generation methods are all incorporated into the same initial test dataset according to the data structure corresponding to the current test scenario, for further cross-system field value transfer and synchronization in step S400.

[0140] In one implementation of this embodiment, step S400 further includes the following sub-steps:

[0141] S401, based on the cross-system field mapping relationship, determines the source data field and target data field corresponding to the same data object from the interrelated data fields, extracts the field value of the source data field, and writes the extracted field value into the target data field corresponding to each business system in the initial test dataset.

[0142] S402, obtain the field value change data of any data field, determine other data fields that are related to the data field whose field value has changed according to the cross-system field mapping relationship, and write the changed field value into the other data fields.

[0143] In this context, a data field corresponding to the same data object refers to a data field that, although distributed across data records in different business systems, is used to represent the same business object or the same business attribute. Examples include a customer number field corresponding to the same customer, an ID number field corresponding to the same document, or a card number field corresponding to the same card in different business systems. A source data field refers to the data field that provides the value to be transmitted in the cross-system field mapping relationship, while a target data field refers to the data field that receives the value. The source and target data fields can be determined based on the data flow path represented by the multi-system association model and the upstream and downstream interface parameter transmission relationships.

[0144] Exemplary, in step S401, the initial test dataset is traversed according to the cross-system field mapping relationship to identify data fields distributed across different business systems that correspond to the same data object, and the source data fields and target data fields are determined according to the corresponding data flow paths. The generated field values ​​in the source data fields are extracted, and these field values ​​are written into the target data fields corresponding to each business system, so that the associated fields corresponding to the same data object have corresponding field values.

[0145] For example, if the customer number field in the customer information management system is the source data field, and the customer number fields in the core system and mobile banking are the target data fields, the value of the customer number field in the customer information management system is extracted, and the value of the customer number field is written into the corresponding customer number fields in the core system and mobile banking, respectively.

[0146] In step S402, the field value changes of the interrelated data fields in the initial test dataset are identified. When the field value of any data field changes, the field value change data containing the changed field value and the identifier of the changed data field is obtained. Based on the data field identifier, the cross-system field mapping relationship is queried to determine other data fields that correspond to the same data object as the data field whose field value has changed, and the changed field value is written into the other data fields.

[0147] For example, when the customer number in the customer information management system is changed from the first customer number to the second customer number, the corresponding customer number fields in the core system and mobile banking are determined according to the cross-system field mapping relationship corresponding to the customer number field, and the second customer number is written into the determined customer number fields respectively.

[0148] For example, in a financial institution's deposit scenario, customer numbers and identification numbers can establish cross-system field mapping relationships between the unified customer service platform, customer information management system, core system, and mobile banking. Product codes can establish cross-system field mapping relationships between the unified customer service platform and the core system, and card numbers can establish cross-system field mapping relationships between the core system and mobile banking. When forming the initial test dataset, the corresponding source data fields and target data fields are determined based on each cross-system field mapping relationship, and the field values ​​of the source data fields are written into the corresponding target data fields of each business system. When the value of any of the customer number, identification number, product code, or card number changes, other related data fields are determined based on the cross-system field mapping relationship corresponding to the changed data field, and the changed field value is synchronously written into the other related data fields.

[0149] The scope of protection for the test data generation method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0150] This application also provides a test data generation device, which can implement the test data generation method described in this application. However, the implementation device of the test data generation method described in this application includes, but is not limited to, the structure of the test data generation device listed in this embodiment. All structural modifications and substitutions of the prior art made in accordance with the principles of this application are included within the protection scope of this application.

[0151] like Figure 5 As shown, this embodiment provides a test data generation apparatus. Exemplarily, the apparatus 100 includes:

[0152] The data acquisition module 110 is used to acquire system description data of multiple business systems, perform data association parsing and constraint extraction on the system description data, and obtain multi-system association model and constraint rule data.

[0153] The requirement acquisition module 120 is used to receive test scenario requirements, perform association matching between the test scenario requirements and the multi-system association model, extract the data to be generated and the cross-system field mapping relationship corresponding to the data to be generated from the association matching result, and extract the data constraint conditions corresponding to the data to be generated from the constraint rule data.

[0154] The data matching module 130 is used to match the data attributes of the data to be generated with the preset data generation conditions to obtain the target generation method corresponding to each data to be generated, and to instantiate the data to be generated according to the target generation method and the data constraints, and to collect the instantiated data to form an initial test dataset.

[0155] The data extraction module 140 is used to extract data fields belonging to different business systems and related to each other in the initial test dataset according to the cross-system field mapping relationship, and to transfer and synchronize field values ​​between the related data fields based on the cross-system field mapping relationship to obtain the target test dataset.

[0156] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units 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 of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0157] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0158] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0159] This application also provides an electronic device. Figure 6 The diagram shown is a structural schematic of the electronic device described in an embodiment of this application. Figure 6 As shown, in this embodiment, the electronic device 200 includes a memory 210 and a processor 220.

[0160] The memory 210 is used to store computer programs; preferably, the memory 210 includes various media that can store program code, such as ROM, RAM, magnetic disk, USB flash drive, memory card or optical disk.

[0161] Specifically, memory 210 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. Electronic device 200 may further include other removable / non-removable, volatile / non-volatile computer system storage media. Memory 210 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application. It is understood that memory 210 may be volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memories.

[0162] The processor 220 is connected to the memory 210 and is used to execute the computer program stored in the memory 210 so that the electronic device 200 performs the method described in any embodiment of this application.

[0163] Specifically, the processor 220 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0164] Specifically, in this embodiment, the electronic device 200 may further include a display 230. The display 230 is communicatively connected to the memory 210 and the processor 220, and is used to display the methods described in the embodiments of this application.

[0165] This application also provides a computer-readable storage medium. When executed by a processor, the program implements the methods described in any embodiment of this application. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0166] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0167] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0168] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for generating test data, characterized in that, include: Obtain system description data from multiple business systems, perform data association parsing and constraint extraction on the system description data, and obtain multi-system association model and constraint rule data; Receive test scenario requirements, perform association matching between the test scenario requirements and the multi-system association model, extract the data to be generated and the cross-system field mapping relationship corresponding to the data to be generated from the association matching results, and extract the data constraint conditions corresponding to the data to be generated from the constraint rule data. The data attributes of the data to be generated are matched with the preset data generation conditions to obtain the target generation method corresponding to each data to be generated. The data to be generated is instantiated according to the target generation method and the data constraints. The instantiated data is collected to form an initial test dataset. According to the cross-system field mapping relationship, extract the data fields that belong to different business systems and are related to each other from the initial test dataset. Based on the cross-system field mapping relationship, perform field value transfer and synchronization between the related data fields to obtain the target test dataset.

2. The test data generation method according to claim 1, characterized in that, Before instantiating the data to be generated, the method further includes: The business attributes of the data to be generated are matched with preset priority rules to obtain the generation priority corresponding to each data to be generated; The data to be generated is sorted according to the generation priority to obtain a data generation sequence, and the data to be generated is instantiated sequentially according to the data generation sequence.

3. The test data generation method according to claim 1, characterized in that, In the process of forming the initial test dataset, the method further includes: Record the data generation source and field association information corresponding to each data item in the initial test dataset to form a data tracking record; The data tracking records are associated and stored with the corresponding data in the initial test dataset.

4. The test data generation method according to claim 1, characterized in that, After obtaining the target test dataset, the method further includes: The data in the target test dataset are classified according to business attributes and usage scenarios, and the classified data is then version-marked and stored accordingly. Receive incremental test data requests, extract new or changed fields from the incremental test data requests, extract cross-system field mapping relationships corresponding to the new or changed fields from the multi-system association model, and extract data constraint conditions corresponding to the new or changed fields from the constraint rule data. The data attributes of the newly added or changed fields are matched with the preset data generation conditions to obtain the corresponding incremental generation method. According to the incremental generation method and the extracted data constraints, the newly added or changed fields are instantiated. Based on the extracted cross-system field mapping relationship, the field values ​​of the instantiated data are passed and synchronized. The synchronized data is written into the test data of the corresponding version. The data stored in categories is matched with preset cleanup conditions, and the data that meets the preset cleanup conditions is deleted, and the corresponding data cleanup information is recorded.

5. The test data generation method according to claim 1, characterized in that, The system description data includes interface information, a data dictionary, and a business process description; the process of performing data association parsing and constraint extraction on the system description data to obtain a multi-system association model and constraint rule data includes: The interface information and the data dictionary are structured and parsed to obtain interface description data, and the business process description is decomposed to obtain a directed business process graph. The interface description data is clustered by interface affiliation to obtain multiple system nodes, and data nodes are extracted from the interface parameters corresponding to each system node. Field matching is performed on data nodes belonging to different system nodes, and the cross-system association mapping is performed on the data nodes by combining the data flow path in the business process directed graph and the upstream and downstream interface parameter transmission relationship in the interface description data to obtain the multi-system association model. Data format constraints, value range constraints, business logic constraints, and cross-system association constraints are extracted from the interface information, the data dictionary, and the business process description. The extracted constraints are then classified and structured to obtain the constraint rule data.

6. The test data generation method according to claim 1, characterized in that, The process involves instantiating the data to be generated according to the target generation method and the data constraints, and then aggregating the instantiated data to form an initial test dataset, including: When the target generation method is static generation, the generation mode is deduced for the data constraints, and the data generator corresponding to the deduced generation mode is called to generate field values ​​to obtain the corresponding instantiated test data; or, a preset data template corresponding to the data to be generated is loaded, the variable values ​​corresponding to the placeholders of each variable in the preset data template are obtained, and the variable values ​​are filled into the preset data template to obtain the corresponding instantiated test data. When the target generation method is dynamic generation, the parameter values ​​corresponding to the data to be generated and satisfying the data constraints are obtained, the parameter values ​​are filled into the parameterized traffic template, a request message is generated, the request message is replayed, and the corresponding response message is obtained. The request message and the response message are associated to form corresponding instantiated test data; or, based on the received interaction request, the interaction request is matched with a preset matching rule, and the data of the matched response template is filled to obtain a response message. The interaction request and the response message are associated to form corresponding instantiated test data. When the target generation method is a model generation method, the data to be generated and the corresponding data constraints are input into the generative model to generate data records, and the generated data records are determined as the corresponding instantiated test data. The instantiated test data is collected to form the initial test dataset.

7. The test data generation method according to claim 1, characterized in that, The process of transferring and synchronizing field values ​​between the interconnected data fields based on the cross-system field mapping relationship includes: Based on the cross-system field mapping relationship, the source data field and target data field corresponding to the same data object are determined from the interrelated data fields, the field value of the source data field is extracted, and the extracted field value is written into the target data field corresponding to each business system in the initial test dataset; Obtain the field value change data of any of the data fields, determine other data fields that are related to the data field whose field value has changed according to the cross-system field mapping relationship, and write the changed field value into the other data fields.

8. A test data generation device, characterized in that, include: The data acquisition module is used to acquire system description data from multiple business systems, perform data association parsing and constraint extraction on the system description data, and obtain multi-system association model and constraint rule data. The requirement acquisition module is used to receive test scenario requirements, perform association matching between the test scenario requirements and the multi-system association model, extract the data to be generated and the cross-system field mapping relationship corresponding to the data to be generated from the association matching result, and extract the data constraint conditions corresponding to the data to be generated from the constraint rule data. The data matching module is used to match the data attributes of the data to be generated with the preset data generation conditions to obtain the target generation method corresponding to each data to be generated, and to instantiate the data to be generated according to the target generation method and the data constraints, and to collect the instantiated data to form an initial test dataset. The data extraction module is used to extract data fields belonging to different business systems and related to each other from the initial test dataset according to the cross-system field mapping relationship, and to transfer and synchronize field values ​​between the related data fields based on the cross-system field mapping relationship to obtain the target test dataset.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing a computer program stored in the memory to cause the electronic device to perform the test data generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the test data generation method according to any one of claims 1 to 7.

Images