A fuzzy testing method for a relational distributed database

Abstract

The application provides a fuzzy test method for a relational distributed database, which significantly improves the test coverage, vulnerability discovery capability and test efficiency of the distributed database through a test case generation method based on syntax variation and random fault injection, a code coverage and reinforcement learning feedback mechanism, and a prophet combining consistency verification and difference test. Compared with the existing method, the application not only improves the pertinence and coverage of the test case, but also can more effectively discover potential vulnerabilities of the distributed database in complex scenarios, and improve the intelligentization and automation degree of the overall test.

Description

Technical Field

[0001] This invention belongs to the field of relational distributed database testing technology, specifically relating to a fuzzy testing method for relational distributed databases. Background Technology

[0002] Database Management Systems (DBMS), as critical information infrastructure, are widely used in various software applications, and their reliability and security are of paramount importance. Database testing techniques can be used to verify whether a DBMS meets expected standards in terms of functionality, performance, and security. By promptly identifying errors and vulnerabilities, these techniques assist developers in fixing the system and improving the overall quality of the database.

[0003] With the rapid growth of data volume and application load, the single-server architecture of traditional standalone databases can no longer meet the demands of modern applications for large-scale storage and transaction processing. In recent years, distributed databases have been widely deployed in internet applications due to their excellent scalability and fault tolerance. These systems improve scalability and reliability by distributing data across multiple nodes. Relational distributed databases, in particular, combine structured data processing capabilities with the advantages of distributed architecture, becoming a crucial support platform for high consistency, strong transaction guarantees, and complex query scenarios. Therefore, comprehensive and systematic testing is essential to ensuring their reliability, security, and stability.

[0004] Compared to single-machine databases, distributed databases require broader testing scope and higher standards. Besides verifying basic data operation functions (such as insert, delete, update, and query), testing must also cover integrity constraints, query optimization capabilities, and exception handling mechanisms. Testing should ensure the system maintains data correctness and operational stability under high concurrency and multi-transaction scenarios, preventing consistency issues such as dirty reads and phantom reads. Furthermore, the inherent complexity of the distributed architecture further increases the testing difficulty. Testing must focus on evaluating data consistency and synchronization capabilities between nodes, system fault recovery capabilities, and stability and performance under dynamic environments such as network fluctuations and topology changes. Simultaneously, typical concurrency anomalies such as race conditions and deadlocks that may arise during concurrent access must be considered.

[0005] Existing methods for testing distributed systems are mainly divided into static analysis and dynamic analysis techniques. Static analysis examines the program text to check for all possible race conditions and deadlocks that may occur during the execution of the program under test. Conversely, dynamic analysis analyzes runtime information collected during program execution to detect race conditions and potential vulnerabilities. Among all existing techniques for detecting program errors, static proof analysis is accurate; however, it is cumbersome, expensive, not fully automated, and requires significant human resources to implement. Dynamic analysis methods applied to distributed systems are limited to analyzing a single instance of program execution on a given input. They are inaccurate, exploring only a small portion of the state space and are prone to probe effects, where the system can identify test cases or environments with obvious testing intent and treat them specially, causing the system to behave differently during testing than during actual runtime.

[0006] Database fuzzing is a dynamic, automated testing technique that introduces large amounts of invalid, anomalous, or random data to test database robustness and security vulnerabilities. This approach significantly reduces the time and cost associated with manual testing while increasing the coverage of vulnerability detection. Fuzzing techniques are categorized into black-box fuzzing, white-box fuzzing, and gray-box fuzzing. Gray-box fuzzing, in particular, strikes a balance between efficiency and effectiveness by using a feedback function derived from observed test executions to perform biased random searches across the program's input domain. For distributed database system testing, current work relies solely on black-box tools, which cannot infer or leverage any knowledge of the system's past behavior to guide the search for errors.

[0007] In summary, testing distributed relational databases still faces numerous challenges. First, the complexity of distributed environments significantly increases the requirements for test coverage and accuracy. Second, while traditional database testing methods can verify basic functionality, in distributed scenarios, factors such as fault recovery, cross-node transactions, and dynamic topology changes make testing tasks much more complex, making it difficult for traditional methods to effectively detect errors caused by distributed characteristics. Furthermore, existing tools for verifying distributed characteristics often cannot delve into the internal logic of the database management system, making it difficult to comprehensively discover potential vulnerabilities. Therefore, designing testing methods and tools that can comprehensively cover all aspects of distributed database systems is particularly important. Summary of the Invention

[0008] To address the aforementioned problems in existing technologies, this invention provides a fuzz testing method for relational distributed databases. The technical problem to be solved by this invention is achieved through the following technical solution: A fuzzing method for relational distributed databases includes: S100, Input the database configuration file of the database to be tested as the initial seed, and use the initial selection probability to mutate the initial seed to obtain the current seed; S200: In the current round, the code coverage of the previous round is used to guide the mutation direction of the current seed, thereby mutating the current seed to obtain the SQL test cases of the current round, and testing them on two different databases to obtain the code coverage of the current round. S300, In the current round, the current fault factor is selected using the factor selection probability updated in the previous round, and each current fault factor is combined with the SQL test case of the current round to obtain the current complete test case. S400, perform consistency testing and crash testing on any current complete test case, record the current state of the database under test, and adjust the factor selection probability using the current state and update the seed selection probability using the code coverage of the current round; S500, repeat S200-S400 until the test target is reached.

[0009] Beneficial effects: 1. Traditional database testing methods primarily rely on random SQL generation and static test cases, lacking testing capabilities for distributed environments. Meanwhile, consistency testing tools focused on distributed systems fail to deeply cover logical errors within the database. This invention proposes a fuzzy testing method for relational distributed databases. Through test case generation methods based on syntax variation and random fault injection, code coverage and reinforcement learning feedback mechanisms, and an oracle combining consistency verification and difference testing, it significantly improves the test coverage, vulnerability discovery capabilities, and testing efficiency of distributed databases.

[0010] 2. The SQL test case generation method based on syntax variation proposed in this invention improves the diversity of test statements through IR variation strategy, and combines random fault injection to simulate real distributed anomaly scenarios, ensuring that the test is more in line with the operating environment of distributed database.

[0011] 3. Traditional testing tools often cannot dynamically optimize the testing process, while the feedback mechanism of this invention can dynamically adjust the SQL mutation strategy and fault injection probability based on the execution results, enabling the test to trigger high-risk code paths more efficiently and improve the vulnerability discovery capability.

[0012] 4. Existing oracle methods cannot fully detect various errors in distributed databases and are prone to missed detections. This invention combines consistency verification and difference testing, and achieves comprehensive detection of database consistency and logical errors by comparing the execution results of different databases and the operation history of the distributed system.

[0013] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating a fuzz testing method for relational distributed databases provided by the present invention. Figure 2 This is a test schematic diagram of an embodiment of the present invention applied to Dqlite 3.30.1; Figure 3 This is a schematic diagram of the SQL statement transformation into IR process provided by the present invention. Detailed Implementation

[0015] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0016] The specific implementation of this invention includes three parts: generating test cases based on syntax variation and random fault injection, utilizing feedback algorithms based on code coverage and reinforcement learning, and oracles based on consistency verification and difference testing.

[0017] Combination Figure 1 and Figure 2 This invention provides a fuzz testing method for relational distributed databases, comprising: S100, Input the database configuration file of the database to be tested as the initial seed, and use the initial selection probability to mutate the initial seed to obtain the current seed; S200: In the current round, the code coverage of the previous round is used to guide the mutation direction of the current seed, thereby mutating the current seed to obtain the SQL test cases of the current round, and testing them on two different databases to obtain the code coverage of the current round. The two different databases are the test database and the control database.

[0018] This invention employs a feedback algorithm based on code coverage and reinforcement learning to optimize test case generation and fault injection strategies for distributed databases. The algorithm first uses code instrumentation to obtain code branch coverage and models the temporal behavior of the distributed database as an abstract timeline. It then combines branch coverage and abstract timeline features to guide the mutation direction of SQL statements, thereby improving the effectiveness of test cases. Secondly, it uses a Q-learning reinforcement learning algorithm to dynamically adjust the fault factors used for fault injection decisions, making the tests more focused on high-risk scenarios. Through this feedback-driven approach, testing can more comprehensively cover the critical paths of the system, improving vulnerability discovery capabilities and testing efficiency.

[0019] S300, In the current round, the current fault factor is selected using the factor selection probability updated in the previous round, and each current fault factor is combined with the SQL test case of the current round to obtain the current complete test case. This invention introduces a random fault injection mechanism to simulate faults such as node crashes and network partitions in a distributed environment. Combined with the aforementioned SQL mutation test cases, it comprehensively evaluates the functionality and fault tolerance of distributed databases under complex fault scenarios.

[0020] S400, perform consistency testing and crash testing on any current complete test case, record the current state of the database under test, and adjust the factor selection probability using the current state and update the seed selection probability using the code coverage of the current round; S500, repeat S200-S400 until the test target is reached.

[0021] The testing objective is to reach the maximum number of test rounds or to achieve a code coverage threshold.

[0022] In one specific embodiment of the present invention, S100 includes: S110, Input the database configuration file and parse the database configuration file to construct an abstract syntax tree; The test case generation method used in this invention mainly includes three stages: SQL statement generation, mutation processing, and fault injection. First, an AST (Abstract Syntax Tree) model is constructed by parsing the database schema, and initial SQL statements are generated based on this model as test seeds. Second, the SQL statements are mutated using IR (Intermediate Representation). Syntax-preserving mutation and semantic-guided instantiation mutation generate diverse SQL test cases, ensuring that the test statements not only conform to syntactic rules but also satisfy semantic dependencies, thereby effectively triggering deep database errors.

[0023] S120, Generate an initial SQL statement based on the abstract syntax tree and use it as the initial seed; S130, using a predetermined initial selection probability, and mutating the initial seed through IR to obtain the current seed.

[0024] IR is a linearized representation of SQL structure, employing a static single assignment (SSA) format for more unified and concise mutation operations. The core characteristic of the IR structure is the removal of specific data, retaining only the structural information of the SQL query. Each SQL query consists of multiple IR statements, each essentially an assignment operation, with the target variable on the left and a constant or an operator containing operands on the right. Each IR node can contain a maximum of two child nodes, and mutation operations only modify these two child nodes. Figure 3This is an example of SQL statement mutation (IR). The goal of IR mutation is to generate diverse query statements to trigger deep database errors while maintaining the correctness of SQL syntax.

[0025] In one specific embodiment of the present invention, S200 includes: S210, calculate the seed selection probability using the code coverage of the previous round, update the seed selection probability of the previous round, and obtain the seed selection probability of the current round. S220: Utilize the seed selection probability of the current round and mutate the current seed of the current round through IR mutation to obtain the SQL test cases of the current round. After IR mutation, the SQL structure remains a skeleton without concrete data and needs to be instantiated using a data dependency graph. The core goal of instantiation is to populate it with appropriate data so that the SQL query conforms to both syntactic requirements and semantic constraints. The specific process is as follows: 1. Construct a data dependency graph: Analyze the relationships between different data elements in the IR structure, including element dependencies (such as a column belonging to a table) and availability dependencies (such as a data element can come from multiple candidate values) to construct a data dependency graph.

[0026] 2. Populate dependency graph data according to node type: Define type nodes, generate unique data and store it in the data mapping table.

[0027] Use type nodes to retrieve existing data from the data map table, ensuring that variables are used in accordance with semantic constraints. Text type nodes are populated with predefined numerical values.

[0028] 3. Traverse the dependency graph to ensure data consistency: Fill in the data step by step according to the syntax structure and dependency relationship of the SQL statement, and finally generate an executable SQL query.

[0029] S230, Test the SQL test cases of the current round on two different databases respectively, and obtain the code coverage of the current round and a record table recording error seeds.

[0030] Existing testing tools typically focus only on consistency verification in distributed systems or logical error detection in databases, lacking an oracle solution that can cover both simultaneously. This invention proposes an oracle construction method that combines consistency verification and difference testing for efficient and accurate error detection in distributed database systems. This method improves the accuracy and coverage of testing by combining linear consistency verification based on abstract timelines and difference testing.

[0031] First, by comparing the database's operation history and event history, the system's linear consistency is ensured, and cross-replica state anomalies are detected. Second, during difference testing, the same test case is executed in three different environments: (1) Complete test cases are executed on the distributed database under test; (2) Test cases that remove fault factors are executed on the same distributed database; (3) The same test cases are executed on a non-distributed database.

[0032] Then, the three test results are compared: the number of rows returned, the query results, and the final data state. If inconsistencies are found, it is determined that the database has potential logical errors or consistency issues. This oracle approach comprehensively covers internal database logical errors and consistency problems in distributed environments, improving the efficiency and accuracy of error detection, ensuring that testing tools can adapt to complex distributed database scenarios, and enhancing vulnerability discovery capabilities.

[0033] In one specific embodiment of the present invention, S210 includes: S211, The temporal behavior of the database under test is modeled as an abstract timeline, and the code coverage increment is calculated on the abstract timeline using the code coverage of the previous round; S212, calculate the frequency of occurrence of each mutant seed in the seed pool and use it as a novelty score; S213, combining the incremental code coverage, signature changes on the abstract timeline, and novelty score, calculate the seed selection probability for each mutant seed.

[0034] (1) Abstract Timeline Construction Method The construction of an abstract timeline is used to analyze the causal relationships of events in a distributed system, providing more complete information for the feedback mechanism. The entire process includes three core steps: global timeline construction, timeline abstraction, and hash mapping.

[0035] 1. Global Timeline Construction In distributed systems, events occur asynchronously, and the clocks of different nodes are not synchronized, making it impossible to directly build a causal graph based on timestamps. Therefore, the event data from each node is first collected and sorted chronologically to form an initial timeline. To ensure the integrity of causal relationships, the timeline is constructed using the prefix closure principle: if an event is included in the timeline, all its causal predecessor events must also be included.

[0036] Specifically, the causal range is first initialized by calculating the event prefix range for each node and considering the maximum clock skew to ensure that no causal events across nodes are missed. Next, causal relationships are traced, identifying event dependencies across nodes, such as message sending and receiving relationships, and then corresponding causal links are added to the timeline. Then, the traced events are merged, and events are added to the timeline step by step according to the prefix closure rule to ensure that all causal dependencies are correctly represented. Finally, the timeline is transformed into a causal event graph, where each event is a node in the graph, and causal relationships are connected by edges to accurately reflect the temporal dependencies of the system.

[0037] 2. Timeline Abstraction The original timeline contains a large amount of redundant information (such as timestamps and data packet content), which is not conducive to test analysis. Therefore, EventHistory is introduced as a high-level timeline abstraction, retaining only key events and their causal relationships. The timeline abstraction mainly includes: event types and the order of events. Event types record the categories of events, such as requests, responses, failures, etc.; the order of events refers to the causal sequence between events, representing the time dependencies in a distributed system.

[0038] The construction of event history is achieved gradually through continuous update and merging operations. Update operations maintain the event order within the same node. When a new event occurs, the system adds it to the event set and checks its causal relationship with previous events. If a dependency exists, the occurrence order pair is recorded to track the node's operation history. Merging operations handle causal relationships across nodes. By traversing the event history of each node, the occurrence order pairs of different nodes are merged to construct a global event history. The key to constructing event history is preserving the causal order of each node to accurately reflect the dependencies between nodes in the distributed system and ensure the consistency of the global timeline.

[0039] 3. Timeline Hash Mapping Since the timeline abstraction still involves a large amount of data, directly applying it to state management would be computationally too costly. Therefore, this paper adopts the MinHash locality-sensitive hashing method to map the timeline to a fixed-length hash signature, thereby reducing computational complexity. The method first extracts event type and occurrence sequence pairs from the timeline to form a feature set. Then, a set of random hash functions is used to map the features to fixed-length MinHash signatures. Next, a similarity assessment is performed by comparing the hash signatures of different timelines to calculate their similarity. Based on a pre-defined similarity difference threshold, it is determined whether the system state has changed.

[0040] Hash mapping ensures efficient state management and can detect the state stability of a distributed system by setting a similarity threshold. When the system state changes significantly, the feedback mechanism can trigger SQL mutations or fault tolerance to optimize the testing process.

[0041] This invention uses a feedback mechanism based on code coverage and timeline abstraction to guide the mutation direction of SQL statements. During testing, branch coverage can be obtained through code instrumentation, and combined with signature changes in the abstract timeline, the selection probability of SQL statements entering the seed pool can be dynamically adjusted to prioritize the generation of test cases that can trigger new system behaviors.

[0042] First, calculate the coverage increment, i.e., the code coverage increment corresponding to the new SQL statement. Second, if the SQL statement execution causes a significant change in the timeline signature, it is considered to have affected the state of the distributed system, further increasing its selection probability. Then, calculate the novelty score, i.e., the frequency of the SQL statement's occurrence in the seed pool. Taking into account the coverage increment, timeline signature change, and novelty score, the selection probability of the SQL statement is determined. The seed selection probability can be expressed by the formula:

[0043] In the formula, Indicates the increment of code coverage. This represents the similarity difference between the timeline signatures. If the difference exceeds a set similarity threshold, then... Otherwise take , This represents the frequency of occurrence of the variant seed in the seed pool; the lower the frequency, the higher its novelty. and It is a weighting coefficient used to balance the influence of different factors on the seed selection probability.

[0044] In one specific embodiment of the present invention, S220 includes: S221, The initial seed is separated into a structural part and a data part using IR; S222, according to the different types of IR structure, the structure part is mutated and the data part is replaced with a predefined placeholder. During the mutation process, the seed selection probability of the current round is used to select the top k mutation seeds with the highest probability. This paper proposes two strategies: structural data separation and type-driven mutation. 1. Separation of Structure and Data: SQL queries are divided into a structure part (SQL keywords, operators, etc.) and a data part (table names, column names, constants, etc.). During mutation, only the structure part is modified, while the data part is replaced with predefined placeholders (e.g., 'x' represents a name, and '1' represents a numerical constant), ensuring that the mutated SQL remains valid. This also allows for a wider range of structure mutations, improving the flexibility and effectiveness of mutation.

[0045] 2. Type-Driven Mutation: Three mutation operations are used based on the different types of IR structures: Insertion operation, which adds new child nodes to the IR structure, such as inserting an ORDER BY statement into a SELECT statement to increase the complexity of the query; Replacement operation, which replaces existing parts with IR fragments of the same type, such as replacing SELECT x FROM x with SELECT COUNT(x) FROM x; Introducing aggregate functions to change the query logic; and Deletion operation, which removes parts of the SQL statement, such as deleting the WHERE clause, to observe whether the DBMS exhibits abnormal behavior.

[0046] S223, Instantiate the mutant seed through the data dependency graph to obtain the SQL test cases for the current round.

[0047] In one specific embodiment of the present invention, S400 includes: S410, In the current round, perform consistency testing and crash testing on any current complete test case, and record the current state of the database under test; S420, the current state is used as the input of reinforcement learning. The fault injection feedback mechanism of reinforcement learning is used to select fault factors from the fault database and update the factor selection probability of the current round. This invention uses the current state as input for reinforcement learning, selects a fault factor from the fault database and injects it into the test database, and calculates the Q value of the fault factor based on the changes in the test database; and uses the Q value to update the factor selection probability of the current round.

[0048] This invention proposes a fault injection feedback mechanism based on Q-learning to optimize factor selection probability. Traditional fault injection methods are usually static and cannot adjust testing strategies according to the real-time state of the system, resulting in low testing efficiency. This invention uses a fault injection feedback mechanism based on Q-learning, which can dynamically adjust the selection probability of fault factors to improve test coverage and vulnerability discovery capabilities. Q-learning mainly includes four core parts: state, action, reward, and Q-value update, and its specific implementation in this invention is as follows: 1. State: The system state is represented by the MinHash signature of the timeline. In each test cycle, the current state of the system is modeled by the timeline abstraction method and used as the input of Q-learning.

[0049] 2. Action Selection: In each test cycle, this invention selects a fault injection strategy (such as network partition, node crash, message loss, etc.) from the fault database and executes it. The probability of fault selection is affected by the value calculated by Q-learning.

[0050] 3. Reward Calculation: After performing fault injection, this invention observes whether the system's timeline changes. If the fault causes the system to enter a new state, a positive reward is given; otherwise, a small negative reward is given to reduce the situation of repeatedly testing invalid faults.

[0051] 4. Value update: Updating the failure factor using Q-learning The value adjusts its future selection probability. Specifically, in the execution of failures... Then, the system will adjust according to the new status. calculate Value update:

[0052] in, For the learning rate, control Value update step size; As a discount factor, it determines the impact of future rewards on current decisions.

[0053] With the iterative updates of Q-learning, Faults with higher values ​​are more likely to be selected in subsequent tests. In other words, the system will prioritize fault factors that are more likely to trigger new states, thereby making the test more efficient and avoiding the impact of too many invalid faults.

[0054] Injecting random faults aims to simulate various abnormal situations in a distributed database environment. By combining this with previously generated SQL test cases, the stability and fault tolerance of the system can be comprehensively evaluated. First, fault injection uses a random method to control the trigger probability of faults, avoiding excessively frequent faults that could impact system performance. For each SQL test case, it is determined whether to add a fault according to the set injection probability. If selected, the number of faults to be injected is further randomly determined, and a specific fault type is selected from a predefined fault database (including network partitions, node crashes, consistency violations, etc.).

[0055] In the process of combining fault models with SQL statements, each SQL test case is paired with a set of fault scenarios to form a diverse set of test cases.

[0056] This combined strategy ensures that different types of SQL statements can run in various distributed fault environments, thereby more effectively evaluating database behavior. To further optimize testing results, this paper introduces a feedback-based dynamic adjustment mechanism, which dynamically adjusts the selection probability of each fault based on the frequency of error triggering, making the system more inclined to select fault factors that can efficiently expose vulnerabilities. For the selected fault factors The feedback value indicates the frequency at which the fault model triggers errors. The calculation method is as follows:

[0057] Based on feedback value The factor selection probability of the fault factor can be updated using the following formula. :

[0058] in, and It is an adjustment factor that controls the speed of feedback adjustment; Q is the Q-value of the fault model, representing the potential of the fault model to induce new errors under a given state. The value of can be calculated using reinforcement learning algorithms. The larger the value, the more effectively the fault factor can trigger system errors, and the greater the probability of selecting the fault factor. The specific calculation method will be described in detail later.

[0059] The above describes a test case generation method based on syntax variation and random fault injection. This method effectively covers potential fault scenarios in distributed database systems under complex environments, ensuring that different types of faults and SQL query combinations are thoroughly tested. Dynamically adjusting the fault injection probability allows testing to focus on the most challenging test cases, thereby improving testing efficiency and coverage.

[0060] S430 determines the seed that needs to be updated by recording the record table of erroneous seeds, and calculates the seed selection probability using the two code coverage rates of the current round, thereby updating the seed selection probability of the current round.

[0061] This invention significantly improves the test coverage, vulnerability discovery capabilities, and testing efficiency of distributed databases by employing a test case generation method based on syntax mutation and random fault injection, a code coverage and reinforcement learning feedback mechanism, and an oracle combining consistency verification and difference testing. Traditional database testing methods mainly rely on random SQL generation and static test cases, lacking testing capabilities specific to distributed environments. Meanwhile, consistency testing tools focused on distributed systems fail to deeply cover logical errors within the database. The SQL test case generation method based on syntax mutation proposed in this invention increases the diversity of test statements through an IR mutation strategy and, combined with random fault injection, simulates real-world distributed anomaly scenarios, ensuring that the test is more consistent with the operating environment of the distributed database. Furthermore, traditional testing tools often cannot dynamically optimize the testing process, while the feedback mechanism of this invention can dynamically adjust the SQL mutation strategy and fault injection probability based on the execution results, enabling tests to trigger high-risk code paths more efficiently and improving vulnerability discovery capabilities. In addition, existing oracle methods cannot completely detect various errors in distributed databases, easily leading to missed detections. This invention, combining consistency verification and difference testing, achieves comprehensive detection of database consistency and logical errors by comparing the execution results of different databases and the operational history of the distributed system. Therefore, compared with existing methods, this invention not only improves the relevance and coverage of test cases, but also more effectively discovers potential vulnerabilities in distributed databases in complex scenarios, thereby improving the overall intelligence and automation of testing.

[0062] Taking the application of this invention to Dqlite 3.30.1 as an example, its execution flow is as follows: Figure 2 First, the test database Dqlite 3.30.1 and the reference database MySQL 8.0.25 are started and database connections are established. Then, the test environment configuration file and database schema information conforming to Dqlite syntax rules are used as input to build the initial test environment. Next, initial SQL statement seeds are generated based on the abstract syntax tree, and the IR mutation method is used to perform structure data separation and type-driven mutation on the SQL statements to generate diverse SQL test cases. Subsequently, fault models, including network partitioning, node crashes, consistency violations, etc., are randomly selected and combined with SQL statements according to the set fault injection probabilities to form a complete set of test cases.

[0063] After test cases are generated, they are input into Dqlite 3.30.1 for execution. The system records the execution results of the SQL statements and changes in the database state, and constructs a global timeline by recording event information at each node through timeline modeling. During testing, the system uses LLVM code instrumentation to calculate code coverage and analyzes the execution impact of SQL statements by combining the signature of the abstract timeline to calculate the selection probability of the SQL statement. Subsequently, a Q-learning feedback mechanism based on reinforcement learning is used to dynamically adjust the fault injection strategy. If a fault can efficiently trigger an error, its selection probability is increased; otherwise, its impact is reduced to improve testing efficiency.

[0064] After execution, the system uses oracles to analyze the test results, employing a combination of consistency verification and difference testing to compare the SQL execution results. Specifically, the same SQL statement is run in three environments: Dqlite 3.30.1 under a complete fault environment, Dqlite 3.30.1 without the impact of the fault, and a non-distributed comparison database MySQL 8.0.25. If the test results differ, it is determined that the database may have a logical error; if the test results violate consistency rules, it is considered that the system has a consistency violation vulnerability. The system then records the relevant SQL statements and fault information.

[0065] Finally, the system will optimize the probability of fault factor selection based on feedback and update the SQL test case seed pool. If no new errors are found during testing, the SQL statements and fault combinations will be adjusted, and the test will be re-executed until the preset test cycle is completed or the coverage threshold is reached. Whenever a new database error is found, a test report containing the SQL statement, fault model, error log, and reproduction steps will be generated and continuously updated for developers to analyze and fix the vulnerability.

[0066] It is worth noting that the terms "first" and "second" in this invention are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0067] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for fuzz testing a relational distributed database, the method comprising: receiving a query from a user; generating a plurality of queries based on the query; and sending the plurality of queries to the relational distributed database. include: S100, Input the database configuration file of the database to be tested as the initial seed, and use the initial selection probability to mutate the initial seed to obtain the current seed; S200: In the current round, the code coverage of the previous round is used to guide the mutation direction of the current seed, thereby mutating the current seed to obtain the SQL test cases of the current round, and testing them on two different databases to obtain the code coverage of the current round. S300, In the current round, the current fault factor is selected using the factor selection probability updated in the previous round, and each current fault factor is combined with the SQL test case of the current round to obtain the current complete test case. S400, perform consistency testing and crash testing on any current complete test case, record the current state of the database under test, and adjust the factor selection probability using the current state and update the seed selection probability using the code coverage of the current round; S500, repeat S200-S400 until the test target is achieved; S200 includes: S210, calculate the seed selection probability using the code coverage of the previous round, update the seed selection probability of the previous round, and obtain the seed selection probability of the current round. S220: Utilize the seed selection probability of the current round and mutate the current seed of the current round through IR mutation to obtain the SQL test cases of the current round. S230, Test the SQL test cases of the current round on two different databases respectively, and obtain the code coverage of the current round and a record table recording error seeds.

2. The method of claim 1, wherein, S100 includes: S110, Input the database configuration file and parse the database configuration file to construct an abstract syntax tree; S120, Generate an initial SQL statement based on the abstract syntax tree and use it as the initial seed; S130, using a predetermined initial selection probability, and mutating the initial seed through IR to obtain the current seed.

3. The method of claim 2, wherein the method further comprises: S210 includes: S211, The temporal behavior of the database under test is modeled as an abstract timeline, and the code coverage increment is calculated on the abstract timeline using the code coverage of the previous round. S212, calculate the frequency of each variant seed in the seed pool and use it as a novelty score; S213, combining the incremental code coverage, signature changes on the abstract timeline, and novelty score, calculate the seed selection probability for each mutant seed.

4. The method of claim 3, wherein the method further comprises: The seed selection probability in S213 is expressed by the formula: In the formula, Indicates the increment of code coverage. This represents the similarity difference between the timeline signatures. If the difference exceeds a set similarity threshold, then... Otherwise take , This represents the frequency of occurrence of the variant seed in the seed pool; the lower the frequency, the higher its novelty. and It is a weighting coefficient used to balance the influence of different factors on the seed selection probability.

5. The method for fuzz testing relationally-oriented distributed databases of claim 2, wherein, S220 includes: S221, the initial seed is separated into a structural part and a data part using IR; S222, according to the different types of IR structure, the structure part is mutated and the data part is replaced with a predefined placeholder. During the mutation process, the seed selection probability of the current round is used to select the top k mutation seeds with the highest probability. S223, Instantiate the mutant seed through the data dependency graph to obtain the SQL test cases for the current round.

6. The method of claim 2, wherein the method further comprises: The S400 includes: S410, In the current round, perform consistency testing and crash testing on any current complete test case, and record the current state of the database under test; S420, the current state is used as the input of reinforcement learning. The fault injection feedback mechanism of reinforcement learning is used to select fault factors from the fault database and update the factor selection probability of the current round. S430 determines the seed that needs to be updated by recording the record table of erroneous seeds, and calculates the seed selection probability using the two code coverage rates of the current round, thereby updating the seed selection probability of the current round.

7. The method of claim 6, wherein the method further comprises: The S420 includes: The current state is used as input for reinforcement learning. A fault factor is selected from the fault database and injected into the test database. The Q value of the fault factor is calculated based on the changes in the test database. The factor selection probability of the current round is updated using the Q value.

8. The method of claim 1, wherein the method is performed by a relationship-oriented distributed database. The testing objectives are to reach the maximum number of test rounds or to achieve a code coverage threshold.

Images