Test data generation method, program product, electronic equipment and storage medium

Abstract

The invention provides a test data generation method, a program product, electronic equipment and a storage medium. The method comprises the following steps: acquiring request data, aiming at a target function, of a user on a tested system and response data corresponding to the request data; the request data comprises a request field; the response data comprises a response field; comparing the request data with the response data, and determining an interface field mapping relation of the tested system; the interface field mapping relation is used for describing a corresponding relation between a response field of the tested system and a request field used for generating response data; obtaining configuration list data of the tested system, and converting the configuration list data of the tested system into test request data for the target function based on the interface field mapping relation; wherein the configuration list data comprises at least one piece of data expressed in the format of the response data. The process of independent development and data configuration for automatic testing is omitted, and the efficiency of automatic testing is improved.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a test data generation method, a program product, an electronic device, and a storage medium. Background Technology

[0002] In automated testing, test cases typically rely on pre-configured test data. Currently, this data is mostly stored independently in JSON, YAML, or Excel files. Because the interface requests of the system under test have numerous fields, and the field names often don't intuitively correspond to the displayed functions on the page, writing test data is extremely difficult. This not only increases the workload of testers but also causes the updates to automated test data to lag behind actual system configuration changes, resulting in low efficiency for automated testing. Summary of the Invention

[0003] The purpose of this application is to provide a test data generation method, program product, electronic device, and storage medium to improve the above-mentioned problems.

[0004] In a first aspect, embodiments of this application provide a test data generation method, comprising: acquiring user request data for a target function on a system under test, and response data corresponding to the request data; the request data includes request fields; the response data includes response fields; comparing the request data and the response data to determine the interface field mapping relationship of the system under test; the interface field mapping relationship is used to describe the correspondence between the response fields of the system under test and the request fields used to generate the response data; acquiring configuration list data of the system under test, and converting the configuration list data of the system under test into test request data for the target function based on the interface field mapping relationship; wherein, the configuration list data includes at least one piece of data represented in the format of response data.

[0005] In the above implementation process, the configuration page and existing data of the system under test are directly used as the source, eliminating the need for separate development and data configuration for automated testing. By establishing field mapping relationships and automatically converting them, testers no longer need to spend a lot of time manually consulting interface documentation to write and maintain complex test data files, reducing the difficulty of preparing automated test data. Because all data essentially originates from and is synchronized with the actual configuration interface of the system under test, viewing and modifying the configuration is as intuitive as operating a regular software interface. When the version of the system under test is updated, only the field mapping relationships need to be relearned to quickly generate test data adapted to the new version, improving the maintenance efficiency of test data synchronization with software version iterations and enhancing the efficiency of automated testing.

[0006] Optionally, in this embodiment of the application, obtaining the user's request data for the target function on the system under test, and the corresponding response data, includes: obtaining the request data sent by the user to the server of the system under test through a configuration operation triggered by a data packet capture tool; wherein the configuration operation is executed by the user through the graphical user interface of the system under test; and capturing the list response returned by the server of the system under test through the data packet capture tool; the list response includes response data; and the response data includes configuration item information created after the request is successful.

[0007] In the above implementation process, by accurately capturing the raw request data generated by users operating on the real interface, as well as the complete configuration information actually stored in the system, the difficulties and errors encountered by testers manually writing complex interface request data out of thin air, detached from the system interface, are mitigated. Since all data originates from capturing real network communication, the accuracy of the obtained request data format and response data structure is ensured to a certain extent, thereby improving the accuracy of the mapping relationship. This reduces the problem of unrealistic or inaccurate test data sources, improves the efficiency and reliability of the automated test data preparation process, and reduces test script debugging and maintenance caused by data format errors.

[0008] Optionally, in this embodiment of the application, comparing request data and response data to determine the interface field mapping relationship of the system under test includes: comparing the values ​​of multiple request fields in the request data with the values ​​of multiple response fields in the response data to obtain comparison results; establishing a mapping relationship between target request fields and target response fields with the same characterization value in the comparison results to generate field pairs; and summarizing multiple field pairs to generate interface field mapping relationships.

[0009] The above implementation process accurately analyzes the correspondence between request and response fields in the interface of the system under test, forming an interface field mapping relationship. This reduces the tedious work and potential errors that testers need to manually consult interface documentation and rely on guesswork or trial and error to manually sort out field correspondences. By aggregating scattered field pairs into a unified mapping relationship, subsequent data conversion processes can be performed in batches, eliminating the need for individual processing of each field. This reduces the difficulty and cost of understanding the system interface data structure and improves the efficiency and accuracy of converting system configuration data to test request data.

[0010] Optionally, in this embodiment of the application, obtaining the configuration list data of the system under test and converting the configuration list data of the system under test into test request data for the target function based on the interface field mapping relationship includes: obtaining the configuration list data, wherein the configuration list data includes at least one configuration item entry, each configuration item entry includes multiple field information stored in the form of a first key-value pair, the key of the first key-value pair being the response field name in the response data of the system under test; for the configuration item entry, performing the following conversion operation: determining the request field name in the request field that has a mapping relationship with the response field name according to the interface field mapping relationship; constructing a second key-value pair with the request field name as the key and the field value corresponding to the response field name in the first key-value pair as the value; and generating test request data corresponding to the configuration item entry from the multiple constructed second key-value pairs.

[0011] In the above implementation process, the configuration list data stored internally by the system is accurately converted back into test request data. The entire process relies on the interface field mapping relationship, eliminating the need for testers to manually write or memorize complex field correspondence rules, thus reducing human error. Since the conversion process can be executed in batches, it saves time and manpower required for preparing test data. Because the conversion source comes directly from the system under test itself, the generated test request data perfectly matches the actual interface requirements of the current version of the system, improving the accuracy and reliability of automated testing.

[0012] Optionally, in this embodiment of the application, after obtaining the request data and before obtaining the response data, the method further includes: refreshing the graphical user interface of the system under test or re-requesting the configuration list data; and querying the response data corresponding to the request data from the configuration list data based on the request identifier of the request data.

[0013] In the above implementation process, the update operation ensures that the captured list response can promptly reflect the latest state of the system after the configuration operation. The automated data association method utilizes the characteristic information of the request data itself as an identifier to reliably filter out the response data directly corresponding to a specific test operation from the configuration list data, which may contain a large number of entries. The combination of these two steps ensures that the request data and response data upon which the mapping relationship analysis depends are logically corresponding, improving the accuracy and reliability of subsequent establishment of interface field mapping relationships.

[0014] Optionally, in this embodiment of the application, comparing request data and response data to determine the interface field mapping relationship of the system under test includes: establishing the interface field mapping relationship of the functional module according to the request data and response data corresponding to different functional modules in the system under test; wherein the interface field mapping relationship is updated with the version iteration of the functional module.

[0015] In the above implementation process, interface field mapping relationships are established for each independent functional module in the system under test. This expands from single-function testing to test data applicable to multiple functions of the entire system, with mapping rules for different modules remaining independent. Furthermore, it enables synchronized updates of mapping relationships with software module version iterations. When a module is upgraded, only the mapping relationship of that module needs to be updated locally, while the mapping relationships of other unchanged modules can remain unchanged and continue to be used, improving the overall efficiency of automated test data.

[0016] Optionally, in this embodiment of the application, after comparing the request data and the response data to determine the interface field mapping relationship of the system under test, the method further includes: converting the response data into verification request data based on the interface field mapping relationship; comparing the verification request data with the original request data; if the comparison is consistent, the interface field mapping relationship is confirmed to be valid; if they are inconsistent, the interface field mapping relationship is determined to be abnormal.

[0017] In the above implementation process, the verification step enables self-verification after the mapping relationship is established, ensuring that the data transformed through this relationship is consistent with the original request data. This reduces errors in subsequent batch test data generation caused by inaccurate mapping relationships. Through automated comparison and judgment, problems in the mapping relationship can be quickly identified and located, such as incorrect or missing fields, allowing for timely correction. This improves the reliability of the entire test data generation method, reduces the risk of deploying defective mapping relationships in actual applications, and enhances the overall efficiency and quality of the automated test data preparation process.

[0018] Secondly, embodiments of this application also provide a test data generation apparatus, comprising: a data acquisition module, configured to acquire user request data for a target function on a system under test, and response data corresponding to the request data; the request data includes request fields; the response data includes response fields; a relationship mapping module, configured to compare the request data and the response data to determine the interface field mapping relationship of the system under test; the interface field mapping relationship is used to describe the correspondence between the response fields of the system under test and the request fields used to generate the response data; and a data generation module, configured to acquire configuration list data of the system under test, and based on the interface field mapping relationship, convert the configuration list data of the system under test into test request data for the target function; wherein the configuration list data includes at least one piece of data represented in the format of response data.

[0019] Thirdly, embodiments of this application also provide a computer program product, including computer program instructions, which are executed by a processor to perform the method provided in the first aspect or any implementation thereof.

[0020] Fourthly, embodiments of this application also provide an electronic device, including: a processor and a memory, the memory storing computer program instructions, which are executed by the processor to perform the method provided in the first aspect or any implementation thereof.

[0021] Fifthly, embodiments of this application also provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, perform the method provided in the first aspect or any implementation thereof.

[0022] This application provides a test data generation method, program product, electronic device, and storage medium that directly utilizes the configuration page and existing data of the system under test (SUT) as the source, eliminating the need for separate development and data configuration for automated testing. By establishing field mapping relationships and automatically converting them, testers no longer need to spend a significant amount of time manually consulting interface documentation to write and maintain complex test data files, thus reducing the difficulty of preparing automated test data. Because all data essentially originates from and is synchronized with the actual configuration interface of the SUT, viewing and modifying the configuration is as intuitive as operating a regular software interface. When the SUT version is updated, only the field mapping relationships need to be relearned to quickly generate test data adapted to the new version, improving the maintenance efficiency of test data synchronization with software version iterations and enhancing the efficiency of automated testing. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a test data generation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the test data generation device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this application.

[0027] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0028] In automated testing, test cases typically rely on pre-configured test data, often stored in formats such as JSON, YAML, or Excel. Because the interfaces of the system under test have numerous fields, and the field names often don't intuitively correspond to the displayed functions, writing, maintaining, and visualizing automated test data becomes extremely difficult. This increases the workload for testers and negatively impacts the efficiency and sustainability of automated testing.

[0029] It is evident that existing automated test data sources are complex to configure, difficult to write, and not easy to maintain and visualize; test data is disconnected from the actual system configuration, resulting in untimely data updates and high maintenance costs.

[0030] This application provides a test data generation method, program product, electronic device, and storage medium. It directly utilizes the configuration page and existing data of the system under test (SUT) as the source, eliminating the need for separate development and data configuration for automated testing. By establishing field mapping relationships and automatically converting them, testers no longer need to spend significant time manually consulting interface documentation to write and maintain complex test data files, thus reducing the difficulty of preparing automated test data. Because all data essentially originates from and is synchronized with the actual configuration interface of the SUT, viewing and modifying the configuration is as intuitive as operating a regular software interface. When the SUT version is updated, only the field mapping relationships need to be relearned to quickly generate test data adapted to the new version, improving the maintenance efficiency of test data synchronization with software version iterations and enhancing the efficiency of automated testing.

[0031] Please see Figure 1 The illustration shows a flowchart of a test data generation method provided in an embodiment of this application. The test data generation method provided in this application can be applied to electronic devices, which may include physical devices such as servers, PCs, tablets, or smartphones, or virtual devices such as virtual machines or containers. The electronic device can be a single device, a combination of multiple devices, or a cluster of a large number of devices. The test data generation method may include: Step S110: Obtain the user's request data for the target function on the system under test, and the corresponding response data; the request data includes request fields; the response data includes response fields.

[0032] Step S120: Compare the request data and response data to determine the interface field mapping relationship of the system under test; the interface field mapping relationship is used to describe the correspondence between the response fields of the system under test and the request fields used to generate the response data.

[0033] Step S130: Obtain the configuration list data of the system under test, and convert the configuration list data of the system under test into test request data for the target function based on the interface field mapping relationship; wherein, the configuration list data includes at least one piece of data represented in the format of response data.

[0034] In step S110, the request data refers to the submission data contained in the HTTP / HTTPS request message sent by the browser or client to the server when the tester performs a specific configuration operation through the graphical user interface of the system under test, such as adding a rule. This data is usually encapsulated in JSON format in the request body. The data structure is defined by the add interface of the system under test, and each request field consists of a key, where the key is the field name and the value is the user input.

[0035] One implementation method is to pre-configure and launch a packet capture tool (such as Fiddler or Charles) on the test terminal to obtain the request data. The packet capture tool acts as a system proxy, transparently capturing all passing network packets. After the user completes a valid interface configuration and submits it, the packet capture tool can filter out requests for operations such as "add" or "submit" corresponding to the target function from the recorded session, and extract the request body from these requests to obtain the required request data.

[0036] Response data refers to the data returned by the server to the client after processing the add request. Response data can be a direct response to the add request or list data reflecting the configuration result. For example, the client can send a query request to the server (such as a list query) by triggering a UI refresh or manually requesting the list. Data capture tools will also capture the server response corresponding to this query request. The main data extracted from this response message is the response data, which is also structured data, specifically key-value pairs used by the server to describe the complete state of a configuration item. Through step S110, a pair of raw data samples with a causal relationship is obtained: request data (operation instructions) and corresponding response data (operation results).

[0037] In step S120, the interface field mapping relationship is a correspondence table. The purpose of the interface field mapping relationship is to establish the association between the field names of the data stored internally in the system (response data) and the field names of the input required to create the data (request data).

[0038] For example, request and response data can be parsed into operable structured objects. Since the request and response data describe the same business entity generated by the same operation, many of their field values ​​are semantically identical. For instance, for the same threat intelligence rule, the user-input rule name is the same. Therefore, the values ​​of all fields in the two datasets can be programmatically traversed and compared. For each request field and its value in the request data, an item with the exact same value is searched among all response fields in the response data. When a matching response field is found, it is considered that there is a correspondence between the request field and the response field, and this pair of field names is recorded: request field name corresponds to response field name. For example, if "rule_name: test rule A" in the request data and "name: test rule A" in the response data have the same value, both being test rule A, then the mapping relationship can be determined: "rule_name corresponds to name". This process can be automated until all response fields with corresponding values ​​have been queried in the request data. The successfully matched mapping relationships are then organized and persistently stored as a mapping table or dictionary, thus obtaining the interface field mapping relationship used to describe the specific interface of the system under test.

[0039] In step S130, the configuration list data refers to the collection of all currently valid configuration items under a certain functional module, which is obtained in real time from the system under test. The configuration list data can be obtained by sending a standard list query request (such as an HTTP GET request) to the system under test. The data format returned by the server is consistent with the "response data" format in step S110, which can be an array containing multiple configuration item entries, each of which is a complete description of a configuration item.

[0040] The acquisition process is as follows: The system under test's query interface is called to retrieve and parse the list data. Each configuration item in the configuration list data is then transformed. Based on the interface field mapping relationship determined in step S120, the program iterates through all response fields in the current configuration item. For each response field name, its corresponding request field name is searched in the interface field mapping relationship. Then, a new key-value pair is constructed using the found request field name as the new key and the field value corresponding to that response field name in the current configuration item as the value.

[0041] After the iteration is complete, all newly constructed key-value pairs are combined according to the format requirements of the request data, forming a new set of test request data that can be used to drive automated test scripts. This process is repeated for each configuration item in the list, thereby batch and automatically converting the entire configuration list data interface field mapping relationship into a complete set of test request data. This generated test request data is compatible with the format of the original request data generated by manual operation on the interface, and can be directly called by automated test scripts to simulate users performing the same add or configuration operations.

[0042] In the implementation of the above embodiments: the configuration page and existing data of the system under test are directly used as the source, eliminating the need for separate development and data configuration for automated testing. By establishing field mapping relationships and automatically converting them, testers no longer need to spend a lot of time manually consulting interface documentation to write and maintain complex test data files, reducing the difficulty of preparing automated test data. Because all data essentially originates from and is synchronized with the actual configuration interface of the system under test, viewing and modifying the configuration is as intuitive as operating a regular software interface. When the version of the system under test is updated, only the field mapping relationships need to be relearned to quickly generate test data adapted to the new version, improving the maintenance efficiency of test data synchronization with software version iterations and enhancing the efficiency of automated testing.

[0043] Optionally, in this embodiment of the application, obtaining user request data for the target function on the tested system, and corresponding response data, includes: Using a data packet capture tool, obtain the request data sent by the user to the server of the system under test, triggered by the configuration operation; wherein, the configuration operation is executed by the user through the graphical user interface of the system under test.

[0044] Packet capture tools are software (such as Fiddler, Charles, or Wireshark) installed on the tester's computer or network nodes in the test environment. Their functions include listening to, recording, and analyzing network packets passing through the network interface card (NIC). For example, this tool can be configured as a proxy for the system or browser, ensuring that all HTTP / HTTPS traffic originating from the client or browser of the "system under test" passes through it, thus enabling monitoring.

[0045] When a user logs in and operates the graphical user interface of the "System Under Test", fills out a form in the target function and clicks the "Submit" or "Save" button, the browser sends an HTTP POST or PUT request to the server. This complete submission action is the user's configuration operation.

[0046] The request data refers to the request body of the HTTP request message, which can be structured data in JSON or XML format. The request data includes all content filled in by the user in the form. Each data item consists of a "request field" name and the value entered by the user. When proxying traffic, the data capture tool parses and stores detailed information for each session in real time. By viewing the list of sessions captured by the tool, filtering out the latest session with the same domain name as the target function page and a request method of POST / PUT, and extracting the request body content from it, the request data can be obtained. This step obtains a sample of correctly formatted raw input data needed to simulate user operations.

[0047] Use a packet capture tool to capture the list response returned by the server of the system under test; the list response includes response data; the response data includes configuration item information created after the request is successful.

[0048] After a user performs a configuration operation, such as adding or successfully submitting a request, the server of the system under test will return a direct response indicating that the operation was successful. If this direct response contains updated configuration items after the configuration operation was performed, then the direct response can be used as the response data. If the direct response only contains brief information such as "operation successful," then refreshing the target function's page will cause the system to re-request the list response. For example, operations such as refreshing the list, switching tabs, or manually clicking the "Search" button on the graphical user interface can trigger the client to send a list query request to the server.

[0049] A list response refers to the complete HTTP response returned by the server for this list query request. The body of the response, the response data, is a structured dataset containing an array where each element is a complete description of a configuration item object. The configuration item information created after a successful request should include the configuration record just added through the configuration operation, presented as a collection of "response fields." Each response field is a key-value pair, where the key is the system-defined field name, and the value is the specific data corresponding to that field.

[0050] For example, in a data capture tool, after a request session, you can find the GET request session pointing to the list query interface and extract the response body from its server response list to obtain the "response data". This data not only contains information entered by the user, but may also contain automatically generated fields, such as rule ID and creation time, used to describe the status of configuration items in the system.

[0051] In the implementation of the above embodiments: by accurately capturing the raw request data generated by the user when operating on the real interface, as well as the complete configuration information actually stored by the system, the difficulties and errors encountered by testers manually writing complex interface request data out of thin air without the system interface are improved. Since all data comes from the capture of real network communication, the accuracy of the obtained request data format and response data structure is ensured to a certain extent, thereby improving the accuracy of the mapping relationship. This reduces the problem of unreal or inaccurate test data sources, improves the efficiency and reliability of the automated test data preparation process, and reduces the debugging and maintenance of test scripts caused by data format errors.

[0052] Optionally, in this embodiment of the application, comparing the request data and response data to determine the interface field mapping relationship of the system under test includes: The values ​​of multiple request fields in the request data are compared with the values ​​of multiple response fields in the response data to obtain the comparison results.

[0053] First, the request and response data are parsed into structured data objects in memory, such as converting a JSON string into a dictionary or object in the program. The comparison process can be based on the value of each request field in the request data, searching through all response fields in the response data for items with identical values. For example, if the request data contains a request field "src_ip:1.2.3.6", the program will iterate through the response data object, searching for any response field with the same value of "1.2.3.6". The value of each request field in the request data can be compared.

[0054] The comparison result is a structured record, which can be a list or a map, clearly indicating which field value in the request data matches which field(s) value in the response data. If a request field's value cannot be found in the response data, that field may be marked as a no-match in the comparison result. This step forms the logical foundation for subsequent mapping; the key is to perform precise value matching, rather than matching field name similarity.

[0055] In the comparison results, establish a mapping relationship between the target request field and the target response field with the same characterization value to generate field pairs; summarize multiple field pairs to generate interface field mapping relationships.

[0056] A successful match means that a request field and a response field semantically describe the same information. Establishing a mapping relationship involves recording the correspondence between these field names. This relationship can be encapsulated, for example, in a tuple or a small key-value pair. The aggregation process involves collecting the individual field pairs generated for all successfully matched request fields into a mapping table (such as a Python dictionary or a Java Map) or a lookup list.

[0057] In an optional embodiment, if a request field value corresponds to multiple fields with the same value in the response data, it may be necessary to determine a unique mapping based on preset rules or by triggering manual intervention. For example, the preset rules may select the first matching item as the unique mapping and record the relationship, or they may select a matching item with a preset identifier as the unique mapping and record the mapping relationship.

[0058] In the implementation of the above embodiments: the correspondence between request and response fields in the interface of the system under test can be accurately analyzed, and an interface field mapping relationship can be formed. This reduces the tedious work and potential errors that testers need to manually consult interface documentation and rely on guesswork or trial and error to manually sort out field correspondences. By aggregating scattered field pairs into a unified mapping relationship, subsequent data conversion processes can be performed in batches, eliminating the need to process each field individually. This reduces the difficulty and cost of understanding the system interface data structure and improves the efficiency and accuracy of converting system configuration data to test request data.

[0059] Optionally, in this embodiment, the configuration list data of the system under test is obtained, and based on the interface field mapping relationship, the configuration list data of the system under test is converted into test request data for the target function, including: Obtain configuration list data, wherein the configuration list data includes at least one configuration item entry, and each configuration item entry includes multiple field information stored in the form of a first key-value pair, wherein the key of the first key-value pair is the response field name in the response data of the system under test.

[0060] The configuration list data refers to the data set obtained by calling the list query interface of the system under test. The data set can be returned in the form of a JSON array. Each configuration item represents a complete configuration record that has been successfully created and stored in the system, and its data structure is consistent with the format of the response data. Each configuration item consists of multiple first key-value pairs, where the key is the name used to identify the data attribute in the response, i.e., the response field name; and the value is the specific data content corresponding to that field.

[0061] For configuration item entries, perform the following transformation operation: Based on the interface field mapping relationship, determine the request field name among the request fields that have a mapping relationship with the response field name. For each response field name, it is necessary to query the interface field mapping relationship. The process is, for example, to traverse all keys of the configuration item entry, i.e., the response field name, and use each response field name as the key to search in the interface field mapping relationship dictionary, thereby determining the request field name it maps to.

[0062] Construct a second key-value pair using the request field name as the key and the field value corresponding to the response field name in the first key-value pair as the value.

[0063] Once the request field name corresponding to each response field name is identified, the request field name is used as the new key, and the original field value corresponding to that response field name in the current configuration item is used as the new value to form a new key-value pair.

[0064] The constructed second key-value pairs generate test request data corresponding to the configuration item entries.

[0065] After iterating through all mappable fields of a configuration item and constructing multiple independent second key-value pairs, all constructed second key-value pairs are merged into a new dictionary or JSON object, which is the test request data corresponding to that configuration item. The test request data simulates the request data format that should be sent when creating this configuration through the user interface. By repeating steps two through four for each configuration item in the configuration list data, a complete set of test request data can be generated in batches for direct use by automated test scripts.

[0066] In the implementation of the above embodiments: the configuration list data stored internally by the system is accurately converted back into test request data. The entire process relies on interface field mapping relationships, eliminating the need for testers to manually write or memorize complex field correspondence rules, thus reducing human error. Since the conversion process can be executed in batches, it saves time and manpower required for preparing test data. Because the conversion source comes directly from the system under test itself, the generated test request data perfectly matches the actual interface requirements of the current version of the system, improving the accuracy and reliability of automated testing.

[0067] Optionally, in this embodiment of the application, after obtaining the request data and before obtaining the response data, the method further includes: Refresh the graphical user interface of the system under test or re-request the configuration list data.

[0068] After successfully submitting a request for data through the graphical user interface, the system server has saved the configuration, but the list currently displayed on the client may still be old data from the cache. Therefore, refreshing the page or re-requesting the configuration list through the interface will trigger the browser to send a new request to the server, specifically to obtain the complete set of current configurations for the target functional module.

[0069] Based on the request identifier in the request data, the corresponding response data is retrieved from the configuration list data.

[0070] Within the acquired full configuration list data, the request identifier of the request data allows for the precise identification of the configuration record created by a specific request. The request identifier refers to one or more fields and their values ​​in the request data that uniquely or highly distinguish the operation. By comparing the values ​​of these identifier fields in the request data with the values ​​of the response fields in each configuration item entry, when all identifier field values ​​in a configuration item entry completely match, that entry is determined to be the response data corresponding to the request data. This process automatically associates and extracts the result of a single operation from batch list data.

[0071] In the implementation of the above embodiments: through update operations, the captured list responses can promptly reflect the latest state of the system after the configuration operation is performed. An automated data association method utilizes the characteristic information of the request data itself as an identifier to reliably filter out response data directly corresponding to a specific test operation from configuration list data that may contain a large number of entries. The combination of these two steps ensures that the request data and response data upon which the mapping relationship analysis depends are logically corresponding, improving the accuracy and reliability of subsequent establishment of interface field mapping relationships.

[0072] Optionally, in this embodiment of the application, comparing the request data and response data to determine the interface field mapping relationship of the system under test includes: Based on the request and response data corresponding to different functional modules in the system under test, establish the interface field mapping relationship of each functional module; the interface field mapping relationship is updated with the version iteration of the functional module.

[0073] The system under test typically contains multiple independent functional modules, such as the threat intelligence module, log query module, and policy management module in a network auditing system. For each different functional module, a complete process needs to be executed separately, including obtaining request and response data, comparing fields, and generating mapping relationships. This is because the interface definitions and field structures of different modules are usually independent.

[0074] A separate mapping configuration item can be created for each target functional module. During execution, the system follows the guidance of the configuration item to perform data capture and analysis on each module, generating and storing a separate interface field mapping relationship for each module, and organizing and managing it through the functional module's identifier.

[0075] When the software version of a certain functional module is upgraded or the interface fields change, a new and accurate interface field mapping relationship can be obtained by simply re-executing the complete creation process for that specific module. This replaces the old version and enables dynamic maintenance and synchronous updates of the mapping relationship without changing other unchanged modules.

[0076] In the implementation of the above embodiments: interface field mapping relationships are established for each independent functional module in the system under test, expanding from single-function testing to test data applicable to multiple functions of the entire system, with mapping rules for different modules not interfering with each other. Furthermore, the mapping relationships can be linked to software module version iterations for updates. When a module is upgraded, only the mapping relationship of that module needs to be updated locally, while the mapping relationships of other unchanged modules can remain unchanged and continue to be used, improving the overall efficiency of automated test data.

[0077] Optionally, in this embodiment of the application, after comparing the request data and response data to determine the interface field mapping relationship of the system under test, the method further includes: Based on the interface field mapping relationship, the response data is converted into verification request data. The captured response data is obtained; it is a structured object containing complete information about a specific configuration item. The program then uses this response data as input and performs a conversion operation based on the interface field mapping relationship. Specifically, it iterates through each response field name in the response data, finds the corresponding request field name through the mapping table, and reconstructs a data object using that request field name as the new key and the original response field's value as the new value. This newly generated object is the verification request data. Theoretically, this data should be able to reconstruct the request data sent when the configuration item was initially created.

[0078] The verification request data is compared with the original request data. The verification request data is then precisely compared with the request data captured in step S110. If they match, the interface field mapping relationship is confirmed to be valid; if they do not match, the interface field mapping relationship is determined to be abnormal.

[0079] For example, two data objects can be parsed in memory and checked field by field. The comparison includes, but is not limited to: checking if the total number of fields is the same, if each key (i.e., the requested field name) is exactly the same, and if the values ​​of fields under each identical key are completely equal. The program will traverse all segments, recording all inconsistencies found, such as different field names, different field values, or a missing field. The entire comparison process is completed automatically by the program, generating a detailed discrepancy report as an internal result to provide a basis for the final judgment.

[0080] For example, if the verification request data is completely consistent with the original request data in all field names and values, then the interface field mapping relationship currently used for conversion is confirmed to be accurate and valid, and can be safely used for subsequent batch data generation tasks. If any inconsistency is found during comparison, then the mapping relationship is confirmed to be abnormal or incorrect. After identifying the abnormality, subsequent processing can be triggered, such as automatically recording the abnormality details, including which specific field mapping is incorrect, issuing an alert to testers, or guiding the system to re-execute the learning phase to obtain the correct mapping relationship, thereby ensuring the reliability of the entire data generation process.

[0081] In the implementation process of the above embodiments: through the verification step, self-verification can be performed after the mapping relationship is established to ensure that the data converted through this relationship is consistent with the original request data, reducing errors in subsequent batch test data generation caused by inaccurate mapping relationships. Through automated comparison and judgment, problems in the mapping relationship can be quickly discovered and located, such as incorrect or missing field correspondences, and corrected in a timely manner. This improves the reliability of the entire test data generation method, reduces the risk of using defective mapping relationships in actual applications, and improves the overall efficiency and quality of the automated test data preparation process.

[0082] Optionally, in this embodiment of the application, the method for obtaining user request data for a target function on the system under test, and the corresponding response data, further includes: Analyze the field values ​​of one or more response fields in the response data to identify the field types of the response fields; determine data constraint rules through pattern matching based on the field types; the data constraint rules are used to characterize the conditions satisfied by the input data that generates the response fields; based on the identified data constraint rules, generate one or more synthetic test request data that conform to the data constraint rules and are different from the request data; use the synthetic test request data for automated testing of the target function.

[0083] Field types include enumeration (values ​​are limited to a fixed set of options), numeric (values ​​are numbers, allowing for further analysis), format string (values ​​conform to a specific pattern, such as IP address or email address), and / or free text. For example: if all observations of a field come from a small, fixed set, it is considered enumeration; if all values ​​can be matched by a specific regular expression (such as an IP address regular expression), it is considered format string; if the values ​​are purely numeric and have a computable range, it is considered numeric.

[0084] Data constraint rules are used to characterize the conditions that the corresponding input data (i.e., the corresponding field in the request data) must satisfy when generating a response field. For example, in pattern matching, for enumeration fields, the "data constraint rule" is the complete set of all possible values ​​for that field. For format string fields, a regular expression describing their common characteristics can be derived or verified through analysis of sample values; this regular expression constitutes the constraint rule. For numeric fields, a reasonable range or boundary of values ​​is determined by calculating statistics such as the maximum, minimum, and average values ​​in the sample values; this range information constitutes the constraint rule.

[0085] The process of generating synthetic test request data involves, for example, invoking the corresponding test data generation algorithm based on the type and content of each data constraint rule. For instance, for enumeration constraints, all possible values ​​are generated; for numerical range constraints, boundary values ​​(such as minimum, maximum, 0, or negative values) and random values ​​within the range are generated; for regular expression constraints, a string generation algorithm based on the regular expression is used to generate a large number of correctly formatted but diverse test cases. These newly generated data entries collectively constitute a rich supplementary test dataset.

[0086] The synthetic test request data can be used as a separate data source file, or added to the test dataset obtained by the original method.

[0087] When automated test scripts are executed, in addition to using test cases based on existing configuration transformations, synthetic data is also invoked for testing. This is particularly suitable for tests that need to cover a large number of boundary cases, abnormal inputs, and stress scenarios. For example, submitting out-of-range values, slightly anomalously formatted strings, or illegal values ​​outside the enumeration to verify the system's robustness and fault tolerance. It enables automated testing to have more powerful exploration and discovery capabilities, without relying entirely on manually configured data samples already in the system. It can automatically learn data constraint rules for fields from existing data samples and generate a large number of valid and diverse synthetic test request data in batches based on these rules. It expands the range of input data and scenario coverage for automated testing, and can automatically generate key test cases for boundary value testing, outlier testing, and format tolerance testing.

[0088] Please see Figure 2 The diagram shown is a structural schematic of the test data generation device provided in an embodiment of this application; this application provides a test data generation device 200, including: The data acquisition module 210 is used to acquire user request data for the target function on the system under test, as well as the corresponding response data; the request data includes request fields; the response data includes response fields. The relationship mapping module 220 is used to compare request data and response data to determine the interface field mapping relationship of the system under test; the interface field mapping relationship is used to describe the correspondence between the response fields of the system under test and the request fields used to generate the response data; The data generation module 230 is used to obtain the configuration list data of the system under test and convert the configuration list data of the system under test into test request data for the target function based on the interface field mapping relationship; wherein, the configuration list data includes at least one piece of data represented in the format of response data.

[0089] Optionally, in this embodiment, the test data generation device 200 and the data acquisition module 210 are used to acquire request data sent by the user to the server of the system under test through a configuration operation triggered by a data packet capture tool; wherein the configuration operation is performed by the user through the graphical user interface of the system under test; the data packet capture tool captures the list response returned by the server of the system under test; the list response includes response data; the response data includes configuration item information created after the request is successful.

[0090] Optionally, in this embodiment of the application, the test data generation device 200 and the relationship mapping module 220 are used to compare request data and response data to determine the interface field mapping relationship of the system under test, including: comparing the values ​​of multiple request fields in the request data with the values ​​of multiple response fields in the response data to obtain comparison results; establishing a mapping relationship between target request fields and target response fields with the same characterization value in the comparison results to generate field pairs; and summarizing multiple field pairs to generate interface field mapping relationships.

[0091] Optionally, in this embodiment, the test data generation device 200 and the data generation module 230 are used to obtain configuration list data, wherein the configuration list data includes at least one configuration item entry, and each configuration item entry includes multiple field information stored in the form of a first key-value pair, where the key of the first key-value pair is the response field name in the response data of the system under test; for each configuration item entry, the following conversion operation is performed: based on the interface field mapping relationship, the request field name in the request field that has a mapping relationship with the response field name is determined; using the request field name as the key and the field value corresponding to the response field name in the first key-value pair as the value, a second key-value pair is constructed; and test request data corresponding to the configuration item entry is generated from the multiple constructed second key-value pairs.

[0092] Optionally, in this embodiment of the application, the test data generation device 200 further includes: a refresh module, used to refresh the graphical user interface of the system under test or re-request the configuration list data; and to query the response data corresponding to the request data from the configuration list data based on the request identifier of the request data.

[0093] Optionally, in this embodiment of the application, the test data generation device 200 and the relationship mapping module 220 are specifically used to establish the interface field mapping relationship of the functional module according to the request data and response data corresponding to different functional modules in the system under test; wherein, the interface field mapping relationship is updated with the version iteration of the functional module.

[0094] Optionally, in this embodiment of the application, the test data generation device 200 further includes a verification module, which is used to convert response data into verification request data based on the interface field mapping relationship; compare the verification request data with the original request data; if the comparison is consistent, the interface field mapping relationship is confirmed to be valid; if they are inconsistent, the interface field mapping relationship is determined to be abnormal.

[0095] It should be understood that this device corresponds to the above-described test data generation method embodiment and is capable of performing the various steps involved in the above method embodiment. The specific functions of this device can be found in the description above, and detailed descriptions are omitted here to avoid repetition. The device includes at least one software functional module that can be stored in memory or embedded in the device's operating system (OS) in the form of software or firmware.

[0096] Please see Figure 3 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the method described above is performed.

[0097] Figure 3 The components shown can be implemented using hardware, software, or a combination thereof. Electronic device 300 may be a physical device, such as a server or PC, or a virtual device, such as a virtual machine or virtualization container. Furthermore, electronic device 300 is not limited to a single device; it can be a combination of multiple devices or a cluster of numerous devices.

[0098] This application also provides a storage medium storing a computer program, which is executed by a processor to perform the above-described method.

[0099] The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0100] This application also provides a computer program product, including computer program instructions, which are executed by a processor to perform the method described above.

[0101] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, given the several embodiments provided in this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0102] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0103] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for generating test data, characterized in that, include: Acquire user request data for the target function on the system under test, and corresponding response data for the request data; The request data includes request fields; the response data includes response fields. The request data and the response data are compared to determine the interface field mapping relationship of the system under test; the interface field mapping relationship is used to describe the correspondence between the response fields of the system under test and the request fields used to generate the response data; Obtain the configuration list data of the system under test, and based on the interface field mapping relationship, convert the configuration list data of the system under test into test request data for the target function; wherein, the configuration list data includes at least one piece of data represented in the format of the response data.

2. The method according to claim 1, characterized in that, Acquiring user request data for a target function on the system under test, and corresponding response data, including: Using a data packet capture tool, request data sent by the user to the server of the system under test, triggered by a configuration operation; wherein, the configuration operation is executed by the user through the graphical user interface of the system under test; The data packet capture tool captures the list response returned by the server of the system under test; the list response includes the response data; the response data includes configuration item information created after the request is successful.

3. The method according to claim 1, characterized in that, The request data and the response data are compared to determine the interface field mapping relationship of the system under test, including: The values ​​of multiple request fields in the request data are compared with the values ​​of multiple response fields in the response data to obtain the comparison results; In the comparison results, establish a mapping relationship between the target request field and the target response field with the same characterization value to generate field pairs; By aggregating multiple field pairs, the interface field mapping relationship is generated.

4. The method according to claim 1, characterized in that, Obtain the configuration list data of the system under test, and based on the interface field mapping relationship, convert the configuration list data of the system under test into test request data for the target function, including: Obtain the configuration list data, wherein the configuration list data includes at least one configuration item entry, and each configuration item entry includes multiple field information stored in the form of a first key-value pair, wherein the key of the first key-value pair is the response field name in the response data of the system under test; For the configuration item entry, perform the following transformation operation: Based on the interface field mapping relationship, determine the request field name in the request field that has a mapping relationship with the response field name; A second key-value pair is constructed using the request field name as the key and the field value corresponding to the response field name in the first key-value pair as the value. The test request data corresponding to the configuration item entry is generated from the constructed multiple second key-value pairs.

5. The method according to claim 1, characterized in that, After obtaining the request data and before obtaining the response data, the method further includes: Refresh the graphical user interface of the system under test or re-request the configuration list data; Based on the request identifier of the request data, the response data corresponding to the request data is retrieved from the configuration list data.

6. The method according to claim 1, characterized in that, The request data and the response data are compared to determine the interface field mapping relationship of the system under test, including: Based on the request data and response data corresponding to different functional modules in the system under test, establish the interface field mapping relationship of the functional module; wherein, the interface field mapping relationship is updated with the version iteration of the functional module.

7. The method according to claim 1, characterized in that, After comparing the request data and the response data to determine the interface field mapping relationship of the system under test, the method further includes: Based on the interface field mapping relationship, the response data is converted into verification request data; The verification request data is compared with the original request data; If the comparison is consistent, the mapping relationship of the interface fields is confirmed to be valid; if they are inconsistent, the mapping relationship of the interface fields is determined to be abnormal.

8. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: A processor and a memory, the memory storing computer program instructions that, when executed by the processor, perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

Images