Database fuzzing method based on write-copying
By constructing a two-layer storage structure of persistent and temporary layers, and combining it with copy-on-write technology, the problem of excessive time consumption for repository initialization and reset in database fuzzing is solved, achieving efficient and well-isolated database fuzzing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINESE PEOPLES LIBERATION ARMY UNIT 61660
- Filing Date
- 2026-05-15
- Publication Date
- 2026-06-26
AI Technical Summary
In existing database fuzzing, the initialization and reset processes of the repository are time-consuming, inefficient, resource-intensive, and cumbersome, affecting testing efficiency and stability.
A database fuzzing method based on copy-on-write is adopted. A two-layer storage structure is constructed, consisting of a persistent layer and a temporary layer. The persistent layer is used to store baseline data, and the temporary layer is used to record data changes generated during the test. The copy-on-write mechanism is used to handle database operations to ensure that the data in the persistent layer remains unchanged. After the test is completed, the temporary layer is quickly reset.
It significantly improves testing efficiency, ensures the isolation and reproducibility of test cases, reduces resource consumption, and is suitable for various relational and non-relational databases.
Smart Images
Figure CN122285528A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of database testing, and more specifically to a database fuzzing method based on copy-on-write. Background Technology
[0002] With the widespread application of database technology in various fields, the stability and reliability of database systems have become crucial. Database fuzzing, as an important means of ensuring database quality, continuously sends various test data and commands to the database to simulate various abnormal scenarios, thereby discovering potential problems in how the database handles these situations.
[0003] In database fuzzing, to ensure consistent initial conditions for each test and guarantee the reproducibility of test results, it is typically necessary to periodically reset the database repository to its initial state. However, traditional repository initialization and reset processes are often time-consuming, severely impacting testing efficiency.
[0004] Currently, in database fuzzing, a common method for resetting a repository is to reinitialize the repository, which involves deleting the existing repository and then creating a new repository with the initial configuration. The core of this method is to reset the state by completely rebuilding the repository.
[0005] However, existing technologies have a high technical threshold for configuration during database fuzzing, and the initialization and reset processes are time-consuming, inefficient, and resource-intensive. Therefore, their stability and ease of use in parallel testing need to be improved, and they also have a certain number of false alarms. Summary of the Invention
[0006] The purpose of this invention is to provide a database fuzzing method based on copy-on-write, which solves the problems of excessive time consumption, low efficiency, high resource consumption and cumbersome operation in the initialization and reset process of the database during database fuzzing.
[0007] To achieve the above objectives, the present invention employs the following technical solution: Database fuzzing methods based on copy-on-write include: Construct and initialize the persistence layer, and determine the baseline state of the persistence layer; wherein the baseline state remains unchanged during the test. Create a temporary layer and associate it with the persistent layer, and build a union storage view, pointing the database storage access to the union storage view; wherein the temporary layer is used to record data generated during the test. The test cases provided by the fuzz testing engine are executed, and the database write operations are handled through the copy-on-write mechanism. The storage management module captures the write operation requests issued by the database to the storage layer, and checks the data block corresponding to the write operation against its internally maintained data block mapping table to see if the data block has been copied to the temporary layer before the operation is performed. Read operations are completed through the collaborative processing of temporary and persistent layers; After the test cases are completed, a quick reset is performed to recreate the temporary layer and establish an association with the persistent layer in order to determine the new federated storage view and modify the database storage access pointer. The test cases are executed repeatedly until all tests are completed and a test report is generated.
[0008] Furthermore, the persistence layer is constructed and initialized, and the baseline state of the persistence layer is determined, including: The persistent layer is a storage area used to store the database baseline data, and its form includes, but is not limited to, file system directories, disk partitions, or block devices; The storage management module obtains the configuration information for the initialization of the persistence layer; based on the configuration information, it creates a file system directory structure that meets the database requirements under the specified storage path; it writes the basic parameters required for database operation into the configuration file of the persistence layer; according to the test requirements, it writes preset initial test data into the persistence layer; the initial test data includes: basic table structure, initialization records, and preset stored procedures; it checks whether the file system structure, configuration file, and initial test data of the persistence layer are complete, and after confirming that there are no errors, it marks the persistence layer as being in a usable baseline state.
[0009] Furthermore, a temporary layer is created and associated with the persistent layer, and a union storage view is constructed, directing database storage access to the union storage view, including: The storage management module obtains the creation parameters required to create the temporary layer, including the storage path of the temporary layer, the storage space size limit, and the associated persistent layer identifier; Based on the creation parameters, a new and empty temporary layer is created under the specified storage path; the temporary layer is a storage area used to record the data changes generated by all write operations during the test, and its form is the same as that of the persistent layer, and it is associated with the persistent layer. The storage management module records the association between the temporary layer and the persistent layer, including: the storage path of the persistent layer, the storage path of the temporary layer, and the data block mapping table; the data block mapping table is used to record the status of data blocks that have been modified and copied from the persistent layer to the temporary layer; The storage management module directs database storage access to a combined storage view consisting of a temporary layer and a persistent layer; when the database initiates a read or write operation, the storage management module determines whether to access the persistent layer or the temporary layer based on the aforementioned relationship.
[0010] Furthermore, the test cases provided by the fuzzing engine are executed, and database write operations are handled through the copy-on-write mechanism, including: The fuzzing engine generates test cases based on a preset mutation strategy and sends the test cases to the database for execution through the database client interface. The database runs in a simulation environment or a real environment and parses, optimizes and executes the test cases according to its own execution logic. During the execution process, the database will generate read and write operation requests to the storage layer. The storage management module captures write operation requests issued by the database to the storage layer; the write operations include, but are not limited to: data addition, data modification, data deletion, index update, and log writing; When the storage management module intercepts a write operation request, it first determines whether the data block targeted by the write operation has been copied to the temporary layer. The determination method is to query the data block mapping table maintained internally by the storage management module to check whether the data block already exists in the temporary layer.
[0011] Furthermore, if the data block has not yet been copied to the temporary layer, a copy operation is performed. The storage management module reads the original data of the data block from the persistent layer, copies it completely to the corresponding location in the temporary layer, and records the status of the data block being copied to the temporary layer in the data block mapping table. After the data block is copied, the storage management module redirects the write operation request to the temporary layer, where the data block is modified, added, or deleted. At this time, the original data block in the persistent layer remains unchanged. If the data block has already been copied to the temporary layer, the storage management module directly redirects the write operation request to the temporary layer for execution.
[0012] Furthermore, the read operation is completed through the collaborative processing of the temporary layer and the persistent layer, including: The storage management module captures read operation requests issued by the database to the storage layer; The system determines whether the data block requested by the read operation exists in the temporary layer; the storage management module queries the data block mapping table to check whether the data block has been copied to the temporary layer. If the data block exists in the temporary layer, the storage management module will redirect the read operation request to the temporary layer, read the latest modified data of the data block from the temporary layer, and return it to the database; If the data block does not exist in the temporary layer, the storage management module will direct the read operation request to the persistent layer, read the original, unmodified data from the data block from the persistent layer, and return it to the database.
[0013] Furthermore, after the test cases are executed, a rapid reset process is performed to recreate the temporary layer and establish an association with the persistent layer, in order to determine the new federated storage view and modify the database storage access pointers, including: The storage management module determines that the current test case has been completed by monitoring the database execution status or receiving notifications from the fuzzing engine. Then, it performs a cleanup operation on the temporary layer, including but not limited to: deleting all data files and directory structures in the temporary layer, clearing the data block mapping table, and releasing the storage space occupied by the temporary layer. The storage management module creates a new and empty temporary layer in the same or a new storage path as the data change recording area for the next test. The storage management module associates the newly created temporary layer with the persistent layer, updates its internal data block mapping table to empty, and directs database storage access to the joint storage view of the persistent layer and the new temporary layer; it checks the storage status of the database to confirm that all data reads point to the original data in the persistent layer, the new temporary layer is empty, and the status of the persistent layer is consistent with the baseline status after initialization.
[0014] Furthermore, the test cases are executed repeatedly until all tests are completed and a test report is generated, including: The fuzzing engine maintains a queue of test cases and checks in real time whether there are any unexecuted test cases in the queue. If there are test cases to be executed, then the following steps are taken for the next test case: send the test case, execute the copy-on-write mechanism to handle the write operation, complete the read operation through the collaborative processing of the temporary layer and the persistent layer, and perform a fast reset after the test case has been executed. The fuzz testing engine collects anomalies found during testing and generates test reports, including the total number of test cases, the number of anomalies found, the anomaly types, and information about the test cases that triggered the anomalies.
[0015] A terminal device includes a processor, a memory, and a computer program stored in the memory; when the processor executes the computer program, it implements the database fuzz testing method based on copy-on-write.
[0016] A computer-readable storage medium storing a computer program; when executed by a processor, the computer program implements the database fuzz testing method based on copy-on-write.
[0017] Compared with the prior art, the present invention has the following technical features: 1. Significantly improves testing efficiency: The persistent layer only needs to be initialized once, avoiding the tedious process of re-initializing every time the repository is reset in traditional technologies. Reset only requires deleting the temporary layer, making the operation simple and fast, greatly accelerating the overall progress of database fuzzing.
[0018] 2. Good test case isolation: Each test case is executed on an independent temporary layer, and data changes between test cases do not interfere with each other, avoiding inaccurate test results caused by state pollution.
[0019] 3. Ensure test reproducibility: After each reset, the repository can be quickly restored to the same state as the initial state (containing only persistent layer data), ensuring that the initial conditions are the same for each test, thereby guaranteeing the accuracy and reproducibility of the test results.
[0020] 4. Wide applicability: This technology is not dependent on a specific database type and can be widely applied to fuzz testing of various relational databases (such as MySQL, Oracle, SQL Server, etc.) and non-relational databases (such as Redis, etc.), and has strong versatility and practicality. Attached Figure Description
[0021] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is an architectural diagram of the technical solution of the present invention; Figure 3 This is a flowchart illustrating one embodiment of the present invention. Detailed Implementation
[0022] The main challenges faced in designing this invention are: how to reduce the number of repository initializations to avoid repetitive, time-consuming initialization operations; how to achieve rapid repository reset to improve the overall efficiency of database fuzzing; and how to reduce resource consumption during repository reset while ensuring test reproducibility. To address these issues, this invention provides a database fuzzing method based on Copy-on-Write (COW). By constructing a two-layer storage structure of a persistent layer and a temporary layer, it achieves rapid repository initialization and reset, thereby improving the efficiency of database fuzzing. The specific steps of this invention are as follows: Step 1: Construct and initialize the persistence layer, and determine the baseline state of the persistence layer; wherein the baseline state remains unchanged during the test.
[0023] Step 1.1: The persistent layer refers to the storage area used to store the database baseline data. Its form includes, but is not limited to, file system directories, disk partitions, or block devices. Obtain the configuration information for initializing the persistent layer, including: file system type (such as ext4, xfs), storage path, basic parameter configuration, and initial test data. This configuration information can be obtained through user-input configuration files or command-line parameters. The persistent layer is initialized only once and remains unchanged in its initial state throughout the entire test process, serving as the baseline data layer for the test.
[0024] Step 1.2: Based on the acquired configuration information, the storage management module creates a file system directory structure that meets the database requirements under the specified storage path; for example, if the database is MySQL, it creates a data directory, log directory, tablespace directory, etc.; if the database is PostgreSQL, it creates a base directory, subdirectories, configuration files, etc. The storage management module is a software component running on the host machine, responsible for managing all storage-related operations such as the creation, association, read / write operation routing, and reset of the persistent and temporary layers.
[0025] Step 1.3: The storage management module writes the basic parameters required for database operation (such as buffer size, number of connections, character set, etc.) into the configuration file of the persistence layer to ensure that the database can start and run normally on the persistence layer.
[0026] Step 1.4: The storage management module writes preset initial test data into the persistence layer according to the test requirements. The initial test data includes: basic table structure, initialization records, and preset stored procedures. This initial test data serves as the starting state for fuzz testing and provides a basis for the execution of subsequent test cases.
[0027] Step 1.5: The storage management module checks whether the file system structure, configuration files and initial test data of the persistence layer are complete. After confirming that there are no errors, it marks the persistence layer as a usable baseline state. This baseline state remains unchanged throughout the test.
[0028] In this step, the solution designs an initialization process for the persistence layer, the purpose of which is to establish a database baseline state that remains unchanged throughout the test, providing the original data source for the subsequent copy-on-write mechanism and ensuring that the starting state of each test is consistent.
[0029] Step 2: Create a temporary layer and associate it with the persistent layer, and build a union storage view, pointing the database storage access to the union storage view; wherein the temporary layer is used to record the data generated during the test.
[0030] Step 2.1: The storage management module obtains the creation parameters required to create the temporary layer; the creation parameters include: the storage path of the temporary layer, the storage space size limit, the associated persistent layer identifier, etc.; the temporary layer can be deleted and recreated.
[0031] Step 2.2: Based on the creation parameters, the storage management module creates a new, empty temporary layer under the specified storage path. Initially, the temporary layer does not contain any data files or directory structures. The temporary layer is a storage area used to record data changes generated by all write operations during the test. Its form is the same as the persistent layer (such as a file system directory) and it is associated with the persistent layer.
[0032] Step 2.3: The storage management module records the association between the temporary layer and the persistent layer, including: the storage path of the persistent layer, the storage path of the temporary layer, and the data block mapping table. This association is stored in the internal data structure of the storage management module and is used to guide the routing of subsequent read and write operations. The data block mapping table is used to record the status of data blocks that have been modified and copied from the persistent layer to the temporary layer. Step 2.4: The storage management module directs the database storage access to the combined storage view consisting of the temporary layer and the persistent layer; when the database initiates a read or write operation, the storage management module determines whether to access the persistent layer or the temporary layer based on the aforementioned relationship.
[0033] In this step, the solution designs a mechanism for creating and associating temporary layers, with the aim of providing independent storage space for write operations during the testing process, so that the original data of the persistent layer can be preserved, laying the foundation for quickly resetting the repository.
[0034] Step 3: Execute the test cases provided by the fuzz testing engine and process the database write operations through the copy-on-write mechanism. The storage management module captures the write operation requests issued by the database to the storage layer and checks, in conjunction with its internally maintained data block mapping table, whether the data block corresponding to the write operation has been copied to the temporary layer before the operation is performed.
[0035] Step 3.1: The fuzz testing engine is a test case generation and sending module running on the host machine. It generates various complex SQL statements as test cases according to a preset mutation strategy, and sends the test cases to the database for execution through database client interfaces (such as JDBC, ODBC, command line tools).
[0036] Step 3.2: The database runs in a simulation environment or a real environment, receives test cases sent by the fuzz testing engine, and parses, optimizes and executes the test cases according to the database's own execution logic; during the execution process, the database will generate read and write operation requests to the storage layer.
[0037] Step 3.3: The storage management module captures write operation requests issued by the database to the storage layer through file system hooks, system call interception, or database storage engine interfaces. The write operations include, but are not limited to: data insertion (INSERT), data modification (UPDATE), data deletion (DELETE), index update, log writing, etc.
[0038] Step 3.4: When the storage management module intercepts a write operation request, it first determines whether the data block targeted by the write operation has been copied to the temporary layer. The determination method is to query the data block mapping table maintained internally by the storage management module to check whether the data block already exists in the temporary layer. If the data block has not yet been copied to the temporary layer, the copy operation is performed. The storage management module reads the original data of the data block from the persistent layer, copies it completely to the corresponding location in the temporary layer, and records the status of the data block being copied to the temporary layer in the data block mapping table. After the data block is copied, the storage management module redirects the write operation request to the temporary layer, where the data block is modified, added, or deleted. At this time, the original data block in the persistent layer remains unchanged. If the data block has already been copied to the temporary layer (i.e., it has been modified before), the storage management module will directly redirect the write operation request to the temporary layer for execution, without having to copy it again.
[0039] In this step, the solution designs a write operation processing mechanism based on copy-on-write, which aims to ensure that all data changes generated during the test are only recorded in the temporary layer, and the baseline data in the persistent layer remains unchanged, thereby supporting subsequent fast reset operations.
[0040] Step 4: The read operation is completed through the collaborative processing of the temporary layer and the persistent layer.
[0041] Step 4.1: The storage management module captures read operation requests from the database to the storage layer through file system hooks, system call interception, or database storage engine interfaces.
[0042] Step 4.2: Determine if the data block requested by the read operation exists in the temporary layer; the storage management module queries the data block mapping table to check whether the data block has been copied to the temporary layer (i.e., whether it has been modified in the previous test process); If the data block exists in the temporary layer, the storage management module will redirect the read operation request to the temporary layer, read the latest modified data of the data block from the temporary layer, and return it to the database; If the data block does not exist in the temporary layer, the storage management module will direct the read operation request to the persistent layer, read the original, unmodified data from the data block from the persistent layer, and return it to the database.
[0043] In this step, the solution designs a read operation processing mechanism based on a two-layer storage structure. The purpose is to provide a unified storage view for the database, ensure that the database can access the data correctly, and at the same time ensure that the integrity of the persistent layer data is not affected by read operations.
[0044] Step 5: After the test cases are completed, perform a quick reset process, recreate the temporary layer and establish an association with the persistent layer to determine the new federated storage view and modify the database storage access pointer.
[0045] Step 5.1: The storage management module determines that the current test case has been completed by monitoring the database execution status or by receiving notifications from the fuzz testing engine.
[0046] Step 5.2: The storage management module performs cleanup operations on the temporary layer, including but not limited to: deleting all data files and directory structures in the temporary layer, clearing the data block mapping table, and releasing the storage space occupied by the temporary layer.
[0047] Step 5.3: The storage management module creates a new and empty temporary layer in the same (the same path as the previous temporary layer) or a new storage path, as the data change recording area for the next test.
[0048] In step 5.4, the storage management module associates the newly created temporary layer with the persistent layer, updates its internal data block mapping table to empty, and directs the database storage access to the joint storage view of the persistent layer and the new temporary layer.
[0049] Step 5.5: The storage management module checks the storage status of the database, confirms that all data reads point to the original data in the persistent layer, the new temporary layer is empty, and the status of the persistent layer is consistent with the baseline status after initialization in Step 1.
[0050] In this step, the solution designs a fast reset mechanism based on temporary layer deletion and reconstruction. The purpose is to restore the database to its initial state simply by deleting the temporary layer and rebuilding it after the test cases are executed, without having to reinitialize the entire database, thus significantly shortening the test interval time.
[0051] Step 6: Execute the test cases repeatedly until all tests are completed and a test report is generated.
[0052] Step 6.1: The fuzzing engine maintains a test case queue and checks in real time whether there are any unexecuted test cases in the queue. If there are test cases to be executed, return to step 3 and execute the processing flow from step 3 to step 5 for the next test case; specifically including: sending the test case, executing the copy-on-write mechanism to handle the write operation, completing the read operation through the collaborative processing of the temporary layer and the persistent layer, and performing a fast reset process after the test case is executed; If all test cases have been executed, the test process ends; the storage management module can retain the persistent layer for subsequent testing or clean it up according to user configuration.
[0053] Step 6.2: The fuzz testing engine collects anomalies found during the testing process (such as database crashes, error logs, assertion failures, etc.) and generates a test report, including information such as the total number of test cases, the number of anomalies found, the anomaly type, and the test cases that triggered the anomalies.
[0054] In this step, the solution designs a cyclic test execution mechanism, which aims to execute all test cases sequentially through automated iteration and quickly reset the stored state after each test case is executed, ensuring that test cases are isolated from each other and avoiding state pollution that could affect the accuracy of test results.
[0055] Through the above steps, this application constructs a two-layer storage structure consisting of a persistent layer and a temporary layer, and combines this with copy-on-write technology to record all data changes generated during the testing process only in the temporary layer. After a test is completed, the repository can be quickly restored to its initial state simply by deleting the temporary layer and rebuilding it, avoiding the time-consuming process of a complete repository initialization, thereby significantly improving the efficiency of database fuzzing.
[0056] In addition to the above solutions, a base snapshot can be created for the repository in its initial state. Each test generates an incremental snapshot based on this base snapshot, recording write operations during the test. When resetting the repository, simply delete the incremental snapshot; no re-initialization is required. This technique achieves rapid repository reset through hierarchical snapshot management, similar to this method, but using snapshots instead of explicit persistent and temporary layer divisions. Alternatively, logical volume management techniques can be used to snapshot the logical volume containing the repository. During testing, operations are performed on the snapshot volume; after testing, the snapshot volume is deleted, restoring the original logical volume state. This method leverages the snapshot functionality of logical volumes to achieve rapid repository reset, also avoiding repeated initialization operations. Another approach is to map the persistent layer data into memory. Write operations during testing are performed in memory (equivalent to the temporary layer being in memory). During reset, only the temporary data in memory needs to be cleared, and the persistent layer data is remapped to memory. This solution is suitable for scenarios with extremely high speed requirements, as memory operations are faster than disk operations, but it is limited by memory capacity.
[0057] Example: This embodiment performs fuzz testing on a MySQL database, achieving rapid initialization and reset of the storage repository through a storage management scheme based on copy-on-write technology. The detailed process is as follows.
[0058] Step 1: Initialize the persistence layer and establish the baseline storage state of the MySQL database, as follows: Step 1.1: Obtain the initialization configuration information for the persistence layer. In this embodiment, the persistence layer refers to the storage area used to store the baseline data of the MySQL database, specifically in the form of a file system directory (e.g., / var / lib / mysql). The initialization configuration information includes: data directory path, database name (e.g., test_db), character set settings (e.g., utf8mb4), initial test data definition, etc. This configuration information is obtained through a user-provided configuration file.
[0059] Step 1.2: Create the file system structure for the persistent layer. The MySQL storage management module creates the data directory structure required by the MySQL database under the specified storage path, including the data directory, log directory, and temporary file directory. The MySQL storage management module is a software component running on the host machine, responsible for managing all storage-related operations such as the creation, association, read / write operation routing, and reset of the MySQL database's persistent and temporary layers.
[0060] Step 1.3: Configure the basic parameters of the persistence layer. The MySQL storage management module writes the basic parameters required for MySQL to run into the persistence layer's configuration file, including but not limited to: data directory path (datadir), port number (port), buffer size (innodb_buffer_pool_size), log file size, etc., to ensure that MySQL can start and run normally on the persistence layer.
[0061] Step 1.4: Write initial test data to the persistence layer. The MySQL storage management module writes preset initial data to the persistence layer according to the test requirements. In this embodiment, the created database includes a user table (users), which contains fields: id (primary key) and name (username). Initial test data is inserted, such as a user with id 1, name "Zhang San", and email "zhangsan@example.com". This initial data serves as the starting state for fuzz testing, providing the foundation for the execution of subsequent test cases.
[0062] Step 1.5: Verify that the persistence layer initialization is complete. The MySQL storage management module checks whether the directory structure, configuration files, and initial data of the persistence layer are complete, confirms that MySQL can start normally and access the initial data, and marks the persistence layer as being in a usable standard initial state.
[0063] The purpose of this step is to initialize the persistence layer through the MySQL storage management module in this embodiment, establish a baseline state of the MySQL database containing user tables, order tables and initial data, and provide a unified starting point for subsequent fuzz testing.
[0064] Step 2: Create a temporary layer and associate it with the persistent layer to record data changes during the test, as follows: Step 2.1: Obtain the creation parameters for the temporary layer. In this embodiment, the storage format of the temporary layer is the same as that of the persistent layer, which is a file system directory. The creation parameters include the storage path of the temporary layer (e.g., / tmp / mysql_temp), the storage space size limit (e.g., 1GB), and the associated persistent layer identifier.
[0065] Step 2.2, Create a temporary layer. Based on the creation parameters obtained in Step 2.1, the MySQL storage management module creates a new empty temporary layer directory under the specified storage path. Initially, the temporary layer directory does not contain any data files or subdirectories.
[0066] Step 2.3 establishes the association between the temporary layer and the persistent layer. The MySQL storage management module records the mapping relationship between the temporary layer and the persistent layer, including: the data directory path of the persistent layer, the data directory path of the temporary layer, and the mapping table of data pages. This association relationship is stored in the internal data structure of the MySQL storage management module and is used to guide the routing of subsequent read and write operations.
[0067] Step 2.4: Configure the MySQL storage access path. The MySQL storage management module directs MySQL storage access to a combined view of the persistent and temporary layers by modifying the MySQL configuration or using file system interception mechanisms. When initiating read or write operations, the MySQL storage management module determines whether to access the persistent or temporary layer based on the association relationship.
[0068] In this step, this embodiment creates a temporary layer and establishes an association with the persistent layer through the MySQL storage management module, providing independent storage space for write operations during the testing process and ensuring that the baseline data of the persistent layer is preserved.
[0069] Step 3: Execute the test cases to handle write operations on the MySQL database using the copy-on-write mechanism, as detailed below: Step 3.1: The fuzzing engine generates test cases and sends them to the MySQL database. The fuzzing engine refers to the test case generation and sending module running on the host machine. In this embodiment, the fuzzing engine generates an UPDATE type SQL test case: "UPDATE users SET age = 30 WHERE id = 1" (modifies the age of the user with id 1 to 30). This test case is sent to the MySQL database for execution via a MySQL client interface (such as the mysql command-line tool or JDBC connection).
[0070] Step 3.2: The MySQL database receives and processes test cases. Running on the host machine or in a simulation environment, the MySQL database receives SQL test cases sent by the fuzzing engine and parses, optimizes, and executes the SQL statements according to its own execution logic. During execution, the MySQL database issues read and write operation requests to the storage layer to modify the data in the users table.
[0071] Step 3.3: The MySQL storage management module intercepts write operation requests from the MySQL database. The MySQL storage management module captures write operation requests issued by MySQL to the storage layer through file system hooks or the MySQL storage engine interface. In this embodiment, the write operation request modifies the age field of the record with id=1 in the users table.
[0072] Step 3.4: Trigger the write-on-write replication mechanism. When the MySQL storage management module intercepts a write operation request, it first determines whether the data page targeted by the write operation has already been copied to the temporary layer. This is done by querying the data page mapping table maintained internally by the MySQL storage management module to check if the data page already exists in the temporary layer.
[0073] Step 3.5: If the data page has not yet been copied to the temporary layer, then perform the copy operation. In this embodiment, the data page containing the user data with id 1 has not yet been copied to the temporary layer. Therefore, the MySQL storage management module reads the original data of the data page (including the user record with name zhangsan) from the persistent layer, copies it completely to the corresponding position in the temporary layer, and records the status of the data page being copied to the temporary layer in the data page mapping table.
[0074] Step 3.6: Perform the write operation in the temporary layer. After the data page replication is complete, the MySQL storage management module redirects the write operation request to the temporary layer, where the data page is modified, updating the age field from 25 to 30. At this time, the original data page in the persistent layer remains unchanged (still age=25).
[0075] Step 3.7: If there are other write operations on the same data page, the MySQL storage management module will directly redirect the write operation request to the temporary layer for execution, without needing to copy it again.
[0076] In this step, this embodiment implements write operation processing based on copy-on-write through the MySQL storage management module, ensuring that data changes generated during the test are only recorded in the temporary layer, and the baseline data in the persistent layer remains unchanged.
[0077] Step 4: The MySQL database read operation is completed through the collaborative processing of the temporary layer and the persistent layer, as detailed below: Step 4.1: The MySQL storage management module intercepts read operation requests from the MySQL database. In this embodiment, when the MySQL database executes a query operation (such as "SELECT age FROM users WHERE id = 1"), the MySQL storage management module captures the read operation request.
[0078] Step 4.2: Determine if the data page requested by the read operation exists in the temporary layer. The MySQL storage management module queries the data page mapping table to check if the data page containing the user with id 1 has been copied to the temporary layer.
[0079] Step 4.3: If the data page exists in the temporary layer, read the data from the temporary layer. In this embodiment, since the user data page with id 1 was copied to the temporary layer and modified in step 3, this data page exists in the temporary layer. The MySQL storage management module redirects the read operation request to the temporary layer, reads the modified data from the temporary layer, and returns age=30 to the MySQL database.
[0080] Step 4.4: If the data page does not exist in the temporary layer, then the data is read from the persistent layer. For example, if a subsequent test case queries the user with ID 2 (which has not been modified), then this data page does not exist in the temporary layer. The MySQL storage management module will direct the read operation request to the persistent layer, read the unmodified original data from the persistent layer, and return it.
[0081] In this step, this embodiment implements read operation processing based on a two-layer storage structure through the MySQL storage management module, ensuring that the MySQL database can access data correctly, while ensuring that the integrity of the persistent layer data is not affected by read operations.
[0082] Step 5: After completing a test, quickly reset the repository to its initial state, as follows: Step 5.1: Detect the completion of the current test case. In this embodiment, the MySQL storage management module determines that the UPDATE test case has been completed by notifying or monitoring the MySQL execution status through the fuzzing engine.
[0083] Step 5.2: Delete the data changes recorded in the temporary layer. The MySQL storage management module performs a cleanup operation on the temporary layer, including deleting all data files and subdirectories in the temporary layer directory, clearing the data page mapping table, and releasing the storage space occupied by the temporary layer.
[0084] Step 5.3: Create a new temporary layer. The MySQL storage management module creates a new empty temporary layer directory under the same storage path (e.g., / tmp / mysql_temp) as the data change recording area for the next test.
[0085] Step 5.4: Establish the association between the new temporary layer and the persistent layer. The MySQL storage management module associates the newly created temporary layer with the persistent layer, updates the internal data page mapping table to empty, and MySQL storage access points to the joint view of the persistent layer and the new temporary layer.
[0086] Step 5.5: Verify that the repository has been restored to its initial state. At this point, if the query "SELECT ageFROM users WHERE id = 1" is executed, the MySQL storage management module will access the persistence layer and return the original data age=25, proving that the repository has been restored to its initial state.
[0087] In this step, this embodiment achieves a rapid reset of the repository by deleting the temporary layer and rebuilding it, without having to reinitialize the entire MySQL database, thus significantly shortening the test interval.
[0088] Step 6: Execute the test cases repeatedly until all tests are completed, as follows: Step 6.1: Determine if there are any test cases to be executed. The fuzz testing engine generates and executes test cases. In this embodiment, other test cases are also included, such as "UPDATE users SET age = 35 WHERE id = 2", "INSERT INTO orders (user_id, amount, status) VALUES (1, 100, 'pending')", and "DELETE FROM users WHERE id = 3".
[0089] Step 6.2: If there are test cases to be executed, return to step 3 and execute the processing flow of steps 3 to 5 for the next test case. Specifically, this includes: sending the test case, executing the copy-on-write mechanism to handle write operations, handling read operations through a two-layer storage structure, and resetting the repository after the test is completed.
[0090] Step 6.3: If all test cases have been executed, the testing process ends. The MySQL storage management module can retain the persistent layer for subsequent testing or clean it up according to user configuration.
[0091] Step 6.4, Output Test Report. The fuzz testing engine collects anomalies found during the test (such as MySQL crashes, error logs, assertion failures, query timeouts, etc.) and generates a test report, including information such as the total number of test cases, the number of anomalies found, the anomaly type, and the test case that triggered the anomaly.
[0092] In this step, this embodiment uses a loop execution mechanism to execute all test cases sequentially and quickly reset the storage state after each test case is executed, ensuring that the test cases are isolated from each other and avoiding state contamination that could affect the accuracy of the test results.
[0093] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A database fuzzing method based on copy-on-write, characterized in that, include: Build and initialize the persistence layer, and determine the baseline state of the persistence layer; The baseline state remains unchanged during the test; Create a temporary layer and associate it with the persistent layer, and build a union storage view, pointing the database storage access to the union storage view; wherein the temporary layer is used to record data generated during the test. The test cases provided by the fuzz testing engine are executed, and the database write operations are handled through the copy-on-write mechanism. The storage management module captures the write operation requests issued by the database to the storage layer, and checks the data block corresponding to the write operation against its internally maintained data block mapping table to see if the data block has been copied to the temporary layer before the operation is performed. Read operations are completed through the collaborative processing of temporary and persistent layers; After the test cases are completed, a quick reset is performed to recreate the temporary layer and establish an association with the persistent layer in order to determine the new federated storage view and modify the database storage access pointer. The test cases are executed repeatedly until all tests are completed and a test report is generated.
2. The database fuzzing method based on copy-on-write as described in claim 1, characterized in that, Construct and initialize the persistence layer, and determine the baseline state of the persistence layer, including: The persistent layer is a storage area used to store the database baseline data, and its form includes, but is not limited to, file system directories, disk partitions, or block devices; The storage management module obtains the configuration information for the initialization of the persistence layer; based on the configuration information, it creates a file system directory structure that meets the database requirements under the specified storage path; it writes the basic parameters required for database operation into the configuration file of the persistence layer; according to the test requirements, it writes preset initial test data into the persistence layer; the initial test data includes: basic table structure, initialization records, and preset stored procedures; it checks whether the file system structure, configuration file, and initial test data of the persistence layer are complete, and after confirming that there are no errors, it marks the persistence layer as being in a usable baseline state.
3. The database fuzzing method based on copy-on-write as described in claim 1, characterized in that, Create a temporary layer and associate it with the persistent layer, and build a union storage view to direct database storage access to the union storage view, including: The storage management module obtains the creation parameters required to create the temporary layer, including the storage path of the temporary layer, the storage space size limit, and the associated persistent layer identifier; Based on the creation parameters, a new and empty temporary layer is created under the specified storage path; the temporary layer is a storage area used to record the data changes generated by all write operations during the test, and its form is the same as that of the persistent layer, and it is associated with the persistent layer. The storage management module records the association between the temporary layer and the persistent layer, including: the storage path of the persistent layer, the storage path of the temporary layer, and the data block mapping table; the data block mapping table is used to record the status of data blocks that have been modified and copied from the persistent layer to the temporary layer; The storage management module directs database storage access to a combined storage view consisting of a temporary layer and a persistent layer; when the database initiates a read or write operation, the storage management module determines whether to access the persistent layer or the temporary layer based on the aforementioned relationship.
4. The database fuzzing method based on copy-on-write as described in claim 1, characterized in that, Execute the test cases provided by the fuzzing engine, and handle database write operations through the copy-on-write mechanism, including: The fuzzing engine generates test cases based on a preset mutation strategy and sends the test cases to the database for execution through the database client interface. The database runs in a simulation environment or a real environment and parses, optimizes and executes the test cases according to its own execution logic. During the execution process, the database will generate read and write operation requests to the storage layer. The storage management module captures write operation requests issued by the database to the storage layer; the write operations include, but are not limited to: data addition, data modification, data deletion, index update, and log writing; When the storage management module intercepts a write operation request, it first determines whether the data block targeted by the write operation has been copied to the temporary layer. The determination method is to query the data block mapping table maintained internally by the storage management module to check whether the data block already exists in the temporary layer.
5. The database fuzzing method based on copy-on-write as described in claim 4, characterized in that, If the data block has not yet been copied to the temporary layer, the copy operation is performed; the storage management module reads the original data of the data block from the persistent layer, copies it completely to the corresponding position in the temporary layer, and records the status of the data block being copied to the temporary layer in the data block mapping table; After the data block copy is complete, the storage management module redirects write operation requests to the temporary layer, where data blocks can be modified, added, or deleted; at this time, the original data blocks in the persistent layer remain unchanged. If the data block has already been copied to the temporary layer, the storage management module directly redirects the write operation request to the temporary layer for execution.
6. The database fuzzing method based on copy-on-write as described in claim 1, characterized in that, Read operations are completed through the collaborative processing of a temporary layer and a persistent layer, including: The storage management module captures read operation requests issued by the database to the storage layer; The system determines whether the data block requested by the read operation exists in the temporary layer; the storage management module queries the data block mapping table to check whether the data block has been copied to the temporary layer. If the data block exists in the temporary layer, the storage management module will redirect the read operation request to the temporary layer, read the latest modified data of the data block from the temporary layer, and return it to the database; If the data block does not exist in the temporary layer, the storage management module will direct the read operation request to the persistent layer, read the original, unmodified data from the data block from the persistent layer, and return it to the database.
7. The database fuzzing method based on copy-on-write as described in claim 1, characterized in that, After the test cases are executed, a quick reset is performed to recreate the temporary layer and establish an association with the persistent layer. This is to determine the new federated storage view and modify the database storage access pointers, including: The storage management module determines that the current test case has been completed by monitoring the database execution status or receiving notifications from the fuzzing engine. Then, it performs a cleanup operation on the temporary layer, including but not limited to: deleting all data files and directory structures in the temporary layer, clearing the data block mapping table, and releasing the storage space occupied by the temporary layer. The storage management module creates a new and empty temporary layer in the same or a new storage path as the data change recording area for the next test. The storage management module associates the newly created temporary layer with the persistent layer, updates its internal data block mapping table to empty, and directs database storage access to the joint storage view of the persistent layer and the new temporary layer; it checks the storage status of the database to confirm that all data reads point to the original data in the persistent layer, the new temporary layer is empty, and the status of the persistent layer is consistent with the baseline status after initialization.
8. The database fuzzing method based on copy-on-write as described in claim 1, characterized in that, The test cases are executed repeatedly until all tests are completed and a test report is generated, including: The fuzzing engine maintains a queue of test cases and checks in real time whether there are any unexecuted test cases in the queue. If there are test cases to be executed, then the following steps are taken for the next test case: send the test case, execute the copy-on-write mechanism to handle the write operation, complete the read operation through the collaborative processing of the temporary layer and the persistent layer, and perform a fast reset after the test case has been executed. The fuzz testing engine collects anomalies found during testing and generates test reports, including the total number of test cases, the number of anomalies found, the anomaly types, and information about the test cases that triggered the anomalies.
9. A terminal device, comprising a processor, a memory, and a computer program stored in the memory; characterized in that, When the processor executes a computer program, it implements the database fuzzing method based on copy-on-write as described in any one of claims 1-8.
10. A computer-readable storage medium storing a computer program; characterized in that, When the computer program is executed by a processor, it implements the database fuzzing method based on copy-on-write as described in any one of claims 1-8.