Fuzzy testing method for relational distributed database

Abstract

The invention provides a relational distributed database-oriented fuzzy testing method, which comprises the following steps of: through a test case generation method based on grammar variation and random fault injection, a code coverage rate and reinforcement learning feedback mechanism, and an oracle machine combined with consistency verification and difference testing, performing fuzzy testing on a relational distributed database; and the test coverage rate, the vulnerability discovery capability and the test efficiency of the distributed database are remarkably improved. Compared with an existing method, the method not only improves the pertinence and coverage rate of the test cases, but also can more effectively discover potential vulnerabilities of the distributed database in a complex scene, and improves the intelligence and automation degree of the whole test.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of relational distributed database testing, and particularly relates to a fuzzy testing method for a relational distributed database. BACKGROUND

[0002] As a key information infrastructure, database management systems (DBMS) are widely used in various software, and their reliability and security are crucial. Database testing technology can be used to verify whether the DBMS meets the expected standards in terms of function, performance and security, and by discovering errors and vulnerabilities in a timely manner, it can assist developers in repairing the system and improve the overall quality of the database.

[0003] With the rapid growth of data volume and application load, the single server architecture of traditional single-machine databases has been difficult to meet the needs of large-scale storage and transaction processing in modern applications. In recent years, distributed databases have been widely deployed in Internet applications due to their good scalability and fault tolerance. Such systems improve the scalability and reliability of the system by distributing data across multiple nodes. In particular, relational distributed databases combine structured data processing capabilities and distributed architecture advantages, becoming an important support platform for high consistency, strong transaction guarantee and complex query scenarios. Therefore, comprehensive and systematic testing is of great significance to ensure the reliability, security and stability of the system.

[0004] Compared with single-machine databases, the testing range of distributed databases is wider and the requirements are higher. In addition to verifying basic data operation functions (such as insertion, deletion, update and query), it also needs to cover integrity constraints, query optimization capabilities and exception handling mechanisms. Testing should ensure that the system can maintain data correctness and operation stability in high-concurrency and multi-transaction scenarios, and prevent consistency problems such as dirty reads and phantom reads. In addition, the complexity brought by the distributed architecture further increases the difficulty of testing, and testing needs to focus on evaluating the data consistency and synchronization capabilities between nodes, the fault recovery capabilities of the system, and the stability and performance in dynamic environments such as network fluctuations and topology changes. At the same time, attention should be paid to typical concurrent anomalies such as race conditions and deadlocks that may occur in concurrent access.

[0005] Existing approaches to testing distributed systems are mainly divided into static analysis techniques and dynamic analysis techniques. Static analysis techniques examine program text to verify the set of all possible contention and deadlocks that can occur during the execution of the program under test. In contrast, dynamic analysis techniques analyze runtime information collected during program execution to detect race conditions and potential vulnerabilities. Among all existing techniques for detecting program errors, static proof analysis techniques are accurate, but they are very tedious, expensive, not fully automated, difficult to use, and require a huge human cost. Dynamic analysis methods applied to distributed systems are limited to analyzing a single program execution instance on a given input, they are inaccurate, can only explore a small part of the state space, and are prone to probe effects, i.e. the system can recognize test cases or environments whose test intention is obvious and process them specially, causing the system to behave differently during testing than during actual runtime.

[0006] Fuzzing techniques for databases are an automated testing technique of dynamic analysis, the goal of which is to test DBM against robustness and security vulnerabilities by introducing a large number of invalid, abnormal or random data. This approach significantly reduces the time and cost associated with manual testing, while increasing the coverage of vulnerability detection. Fuzzing techniques are divided into black-box fuzzing, white-box fuzzing and gray-box fuzzing, where gray-box fuzzing provides a balance between efficiency and effectiveness by using feedback functions from observed test executions to perform a biased random search over the domain of program inputs.

[0007] In summary, testing of distributed relational databases still faces many challenges. First, the complexity of the distributed environment greatly increases the coverage and accuracy requirements of testing. Second, while traditional database testing methods can verify basic functionality, in a distributed scenario, factors such as fault recovery, cross-node transactions, and dynamic topology changes make the testing task more complex, and traditional methods are difficult to effectively detect errors due to distributed characteristics. In addition, existing tools that verify distributed characteristics often cannot delve into the internal logic of the database management system, making it difficult to fully discover potential vulnerabilities. Therefore, it is particularly important to design testing methods and tools that can fully cover all aspects of distributed database systems. SUMMARY

[0008] To solve the above problems existing in the prior art, the present application provides a fuzzy testing method for a relational distributed database. The technical problem to be solved by the present application is solved by the following technical scheme: A fuzzy testing method for a relational distributed database comprises: S100, input the database configuration file of the to-be-tested database as an initial seed, and mutate the initial seed by using an initial selection probability to obtain a current seed; S200, in the current round, guide the mutation direction of the current seed by using the code coverage of the previous round, thereby mutating the current seed to obtain an SQL test case of the current round, and testing the SQL test case on two different databases to obtain a code coverage of the current round; S300, in the current round, select a current fault factor by using the factor selection probability updated in the last round, and combine each current fault factor with the SQL test case of the current round to obtain a current complete test case; S400, perform consistency testing and crash testing on any current complete test case, record the current state of the to-be-tested database, and adjust the factor selection probability by using the current state and update the seed selection probability by using the code coverage of the current round; S500, repeat S200-S400 until a test target is reached.

[0009] Advantages: 1. Traditional database testing methods mainly rely on random SQL generation and static test cases, lack of testing ability for distributed environments, and consistency testing tools focusing on distributed systems cannot deeply cover internal logic errors of databases. The present application provides a fuzzy testing method for a relational distributed database, which significantly improves the test coverage, vulnerability discovery ability and test efficiency of the distributed database through a test case generation method based on syntax mutation and random fault injection, a code coverage and reinforcement learning feedback mechanism, and a prophet combining consistency verification and difference testing.

[0010] 2. The SQL test case generation method based on syntax mutation provided by the present application improves the diversity of test statements through an IR mutation strategy, and simulates real distributed abnormal scenarios by combining random fault injection, to ensure that the test is more consistent with the running environment of the distributed database.

[0011] 3. Traditional testing tools often cannot dynamically optimize the testing process, but the feedback mechanism of the present application can dynamically adjust the SQL mutation strategy and fault injection probability based on the execution result, so that the test can more efficiently trigger high-risk code paths and improve the vulnerability discovery ability.

[0012] 4. Existing prophet methods cannot completely detect multiple errors of distributed databases, and are prone to missed detection, but the present application combines consistency verification and difference testing, compares the execution results of different databases and the operation history of the distributed system, and realizes comprehensive detection of the consistency and logic errors of the database.

[0013] The application will be described in further detail below with reference to the drawings and embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 is a flowchart of a fuzzy testing method for a relational distributed database provided by the application; Figure 2 is a test schematic diagram of an embodiment of the application applied to Dqlite3.30.1 provided by the application; Figure 3 is a schematic diagram of the process of SQL statement variation to IR provided by the application. DETAILED DESCRIPTION

[0015] The application will be described in further detail below with reference to the drawings and embodiments.

[0016] The specific implementation scheme of the application includes three parts: generating test cases based on syntax variation and random fault injection, using a feedback algorithm based on code coverage and reinforcement learning, and a predictor based on consistency verification and difference testing.

[0017] In combination with Figure 1 and Figure 2 , the application provides a fuzzy testing method for a relational distributed database, comprising: S100, inputting a database configuration file of a to-be-tested database as an initial seed, and using an initial selection probability to mutate the initial seed to obtain a current seed; S200, in the current round, using the code coverage of the previous round to guide the mutation direction of the current seed, thereby mutating the current seed to obtain an SQL test case of the current round, and testing it on two different databases to obtain the code coverage of the current round; Wherein, the two different databases are the to-be-tested database and the control database.

[0018] The application uses a feedback algorithm based on code coverage and reinforcement learning to optimize the test case generation and fault injection strategy of the distributed database. The algorithm first uses code instrumentation to obtain code branch coverage, and models the timing behavior of the distributed database as an abstract timeline, and combines the branch coverage and abstract timeline features to guide the mutation direction of the SQL statement, to improve the effectiveness of the test case. Secondly, the Q-learning reinforcement learning algorithm is used to dynamically adjust the fault factors used for decision-making of fault injection, so that the test is more focused on high-risk scenarios. Through this feedback-driven method, the test can more comprehensively cover the key paths of the system, and improve the vulnerability discovery ability and test efficiency.

[0019] S300, in the current round, the current fault factor is selected by using the factor selection probability updated in the last round, and each current fault factor is combined with the SQL test case of the current round to obtain a current complete test case; The application introduces a random fault injection mechanism to simulate node crashes, network partition and other faults in a distributed environment, and combines the foregoing SQL mutation test case to comprehensively evaluate the functionality and fault tolerance capability of the distributed database under complex fault scenarios.

[0020] S400, consistency testing and crash testing are performed on any current complete test case, the current state of the to-be-tested database is recorded, and the factor selection probability is adjusted using the current state and the seed selection probability is updated using the code coverage of the current round; S500, repeating S200-S400 until the test target is reached.

[0021] The test target is that the number of rounds reaches the maximum test number or the code coverage reaches the threshold.

[0022] In a specific embodiment of the application, S100 includes: S110, inputting a database configuration file and parsing the database configuration file to build an abstract syntax tree; The test case generation method used in the application mainly includes three stages of SQL statement generation, mutation processing and fault injection. First, the database schema is parsed to build an AST (abstract syntax tree) model, and initial SQL statements are generated based on the model as test seeds. Second, the SQL statements are mutated using IR (intermediate representation), and diversified SQL cases are generated through syntax preservation mutation and semantic guided instantiation mutation, ensuring that the test statements not only conform to the syntax rules, but also meet the semantic dependencies, thereby effectively triggering deep errors of the database.

[0023] S120, generating initial SQL statements based on the abstract syntax tree and using them as initial seeds; S130, mutating the initial seeds through IR based on a predetermined initial selection probability to obtain current seeds.

[0024] IR is a linearized SQL structure representation, and adopts a static single assignment (SSA) form, making the mutation operation more unified and concise. The core feature of the IR structure is to remove specific data and only retain the structural information of the SQL query. Each SQL query is composed of multiple IR statements, and each IR statement is essentially an assignment operation, with the left side being a target variable and the right side being a constant or an operator containing an operand. Each IR node can contain at most two child nodes, and the mutation operation only modifies these two child nodes. Figure 3An example of a SQL statement mutation IR. The goal of IR mutation is to generate diversified query statements to trigger deep errors of the database while keeping the SQL syntax correct.

[0025] In a specific embodiment of the present application, S200 includes: S210, using the previous round of code coverage rate to calculate the seed selection probability, and updating the seed selection probability of the last round to obtain the seed selection probability of the current round; S220, using the seed selection probability of the current round, and mutating the current seed of the current round by IR mutation to obtain the SQL test case of the current round; After IR mutation, the SQL structure is still a skeleton without specific data, which needs to be instantiated through a data dependency graph. The core goal of instantiation is to fill in appropriate data to make the SQL query meet both the syntax requirements and the semantic constraints. The specific process is as follows: 1. Construct a data dependency graph: analyze the relationship between different data elements in the IR structure, including element dependency (such as column belonging to table) and availability dependency (such as a data element can be derived from multiple candidate values) to construct a data dependency graph.

[0026] 2. Fill in the data of the dependency graph according to the node type: define the type node to generate unique data and store it in the data mapping table.

[0027] Use the type node to obtain existing data from the data mapping table to ensure that the variable usage meets the semantic constraints. The literal type node is filled with predefined numerical values.

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

[0029] S230, test the SQL test case of the current round on two different databases respectively to obtain the two code coverage rates of the current round and the record table of the error seed.

[0030] Existing test tools usually only focus on consistency verification of distributed systems or logical error detection of databases, and lack a prophetic machine scheme that can cover both. The present application proposes a prophetic machine construction method combining consistency verification and difference testing for efficiently and accurately detecting errors of 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 operation history and event history of the database, the system is ensured to meet the linear consistency feature, and the state anomaly across the replicas is detected. Second, during the difference test process, the same test case is executed in three environments respectively: (1) The complete test case is executed on the distributed database to be tested; (2) The test case without fault factors is executed on the same distributed database; (3) The same test case is executed on a non-distributed database.

[0032] Then, the three test results are compared, including the number of returned rows, query results and final data state. If there is inconsistency, it is determined that the database has potential logical errors or consistency problems. Through this oracle scheme, the internal logic errors of the database and the consistency problems in the distributed environment can be fully covered, the efficiency and accuracy of error detection are improved, and it is ensured that the test tool can adapt to complex distributed database scenarios and improve the vulnerability discovery capability.

[0033] In a specific embodiment of the present application, S210 comprises: S211, modeling the time sequence behavior of the database to be tested as an abstract timeline, and calculating the code coverage increment on the abstract timeline using the code coverage of the previous round; S212, calculating the frequency of each mutation seed in the seed pool as a novelty score; S213, integrating the code coverage increment, signature change of the abstract timeline and novelty score to calculate the seed selection probability of each mutation seed.

[0034] (1) Abstract timeline construction method The construction of the abstract timeline is used to analyze the causal relationship of events in the distributed system and provide more complete information for the feedback mechanism. The whole process includes three core steps of global timeline construction, timeline abstraction and hash mapping.

[0035] 1. Global timeline construction Events in a distributed system occur asynchronously, and the clocks of different nodes are not synchronized, so it is not possible to directly establish a causal relationship graph according to the timestamp. Therefore, first, collect the event data of each node and sort them in chronological order to form an initial timeline. In order to ensure the integrity of the causal relationship, the construction of the timeline adopts the prefix closure principle: if an event is included in the timeline, all its causal predecessors must also be included.

[0036] Specifically, firstly, the causal range is initialized, the event prefix range of each node is calculated, and the maximum clock skew is considered to ensure that the causal events across nodes are not missed. Secondly, the causal relationship is tracked, the event dependencies across nodes such as message sending and receiving relationships are identified, and then the corresponding causal links are added in the timeline. Then the tracked events are merged, according to the prefix closure rule, the events are gradually added to the timeline, and it is ensured that all causal dependency relationships are correctly represented. Finally, the timeline is converted into a causal event graph, where each event is a node of the graph, and the causal relationship is connected by the edge, to accurately reflect the time dependency relationship of the system.

[0037] 2. Timeline abstraction The original timeline contains a large amount of redundant information (such as timestamps and packet contents), which is not conducive to test analysis. Therefore, the EventHistory is introduced as a high-level timeline abstraction, which only retains key events and their causal relationships. Timeline abstraction mainly includes: event type and event occurrence order relationship. Event type, i.e. the category of the recorded event, such as request, response, failure, etc. Event occurrence order relationship, i.e. the causal order between events, the time dependency information in distributed systems.

[0038] The construction of EventHistory is gradually realized through continuous updating and merging operations on events. Among them, the updating operation is used to maintain the event order within the same node. When a new event occurs, the system adds it to the event set and checks the causal relationship with the previous event. If there is a dependency, the occurrence order pair is recorded to track the operation history of the node. The merging operation is used to handle the causal relationship across nodes. By traversing the event history of each node, the occurrence order pairs of different nodes are merged to construct the global event history. The key to constructing the event history is to preserve the causal order of each node to accurately reflect the dependency relationship between nodes in the distributed system and ensure the consistency of the global timeline.

[0039] 3. Timeline hash mapping Since the timeline abstraction still contains a large amount of data, directly applying it to state management will result in high computational cost. Therefore, this paper uses the MinHash locality-sensitive hashing method to map the timeline to a fixed-length hash signature to reduce the computational complexity. The method first extracts the event type and occurrence order pair in the timeline to form a feature set, and then uses a set of random hash functions to map the features to a fixed-length MinHash signature. Then the similarity is evaluated by comparing the hash signatures of different timelines to calculate their similarity, and according to the set similarity difference threshold, it is judged whether the system state has changed.

[0040] The hash map ensures the efficiency of state management and can detect the state stability of the distributed system by setting a similarity threshold. When the system state changes significantly, the feedback mechanism can trigger SQL mutation or fault adjustment to optimize the test process.

[0041] The application uses a feedback mechanism based on code coverage and timeline abstraction to guide the mutation direction of SQL statements. During the test process, branch coverage can be obtained through code instrumentation, and the signature change of the abstract timeline is combined to dynamically adjust the selection probability of the SQL statement into the seed pool to preferentially generate test cases that can trigger new system behaviors.

[0042] First, the coverage increment is calculated, that is, the code coverage increment corresponding to the new SQL statement is calculated. Second, if the execution of the SQL statement causes a significant change in the timeline signature, it is considered to have affected the state of the distributed system, and the selection probability is further improved. Then, the novelty score is calculated, that is, the frequency of the appearance of the SQL statement in the seed pool. Considering the coverage increment, the timeline signature change and the novelty score, the selection probability of the SQL statement , that is, the seed selection probability is expressed by the formula:

[0043] In the formula, represents the code coverage increment, represents the similarity difference value of the timeline signature. If the difference value exceeds the set similarity threshold, take , otherwise take , represents the frequency of the appearance of the mutation seed in the seed pool. The lower the frequency, the higher the novelty, and are weight coefficients for balancing the influence of different factors on the seed selection probability.

[0044] In a specific embodiment of the application, S220 includes: S221, data separation of the initial seed using IR to obtain a structure part and a data part; S222, according to different types of IR structure, the structure part is mutated and the data part is replaced with a predefined placeholder. In the mutation process, the seed selection probability of the current round is used to select the top k mutation seeds with the highest selection probability; This paper proposes two strategies of structure data separation and type-driven mutation: 1. Structure data separation: divide the SQL query into structure part (SQL keywords, operators, etc.) and data part (table name, column name, constant, etc.). When mutation, only modify the structure part, and replace the data part with a predefined placeholder (such as x represents name, 1 represents numerical constant), ensure that the mutated SQL is still legal, while allowing a wider range of structural mutations, improving the flexibility and effectiveness of mutation.

[0045] 2. Type-driven mutation: according to the different types of IR structure, three kinds of mutation operations are adopted: insertion operation, adding new child nodes in IR structure, such as inserting ORDERBY statement in SELECT statement to increase the complexity of query; replacement operation, replacing existing parts with IR fragments of the same type, such as replacing SELECT x FROM x with SELECT COUNT(x) FROM x, introducing aggregation function to change query logic and deletion operation removing part of SQL statement, such as deleting WHERE clause to observe abnormal behavior of DBMS.

[0046] S223, the mutation seed is instantiated through the data dependency graph to obtain the SQL test case of the current round.

[0047] In a specific embodiment of the present application, S400 comprises: S410, in the current round, any current complete test case is subjected to consistency test and crash test, and the current state of the database under test is recorded; S420, taking the current state as the input of reinforcement learning, using the fault injection feedback mechanism of reinforcement learning to select a fault factor from the fault library, and updating the factor selection probability of the current round; The present application takes the current state as the input of reinforcement learning, selects a fault factor from the fault library and injects it into the database under test, and calculates the Q value of the fault factor according to the change of the database under test; the Q value is used to update the factor selection probability of the current round.

[0048] The present application proposes a fault injection feedback mechanism based on Q-learning to optimize the factor selection probability. The traditional fault injection method is usually static, which cannot adjust the test strategy according to the real-time state of the system, resulting in low test efficiency. The present application 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 ability. Q-learning mainly includes four core parts: state, action, reward and Q value update, and the specific implementation in the present application is as follows: 1. State: The state of the system is represented by the MinHash signature of the timeline. At each test period, the current state of the system is modeled by the timeline abstraction method and used as input for Q-learning.

[0049] 2. Action selection: At each test period, the invention selects a fault injection strategy (such as network partition, node crash, message loss, etc.) from the fault library to execute. The probability of fault selection is influenced by the values calculated by Q-learning.

[0050] 3. Reward calculation: After executing the fault injection, the invention observes whether the timeline of the system has changed. If the fault has caused the system to enter a new state, a positive reward is given, otherwise a small negative reward is given to reduce the repetition of testing invalid faults.

[0051] 4. Value update: The values of the fault factors are updated using Q-learning to adjust their future selection probabilities. Specifically, after executing the fault , the system calculates the new state value update:

[0052] where is the learning rate, controlling the update step size of the value; is the discount factor, determining the influence of future rewards on current decisions. As Q-learning iteratively updates,

[0053] the probability of selecting faults with higher values in subsequent tests is greater, i.e. the system will prefer to select fault factors that are more likely to trigger new states, making the test more efficient and avoiding the impact of too many invalid faults.

[0054] Random fault injection aims to simulate various abnormal situations in a distributed database environment. By combining with previously generated SQL test cases, the stability and fault tolerance of the system can be fully evaluated. First, fault injection uses a random method to control the triggering probability of faults, avoiding too frequent faults affecting system performance. For each SQL test case, the injection probability is set to determine whether to add faults. If selected, the number of faults to be injected is further randomly determined, and the specific fault type is selected from the predefined fault library (including network partition, node crash, consistency destruction, etc.).

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

[0056] This combination strategy ensures that different types of SQL statements can run under various distributed failure environments, thus more effectively evaluating the behavior of the database. To further optimize the test effect, this paper introduces a feedback-based dynamic adjustment mechanism, which dynamically adjusts the selection probability of each fault according to the frequency of error triggered by the fault, so that the system is more inclined to select the fault factor that can efficiently expose vulnerabilities. Set The feedback value of the selected fault factor represents the frequency of errors triggered by the fault model. The calculation method is as follows:

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

[0058] wherein and are adjustment factors that can control the speed of feedback adjustment; is the Q value of the fault model, indicating the potential of the fault model to trigger new errors in a given state. The value of can be calculated by a reinforcement learning algorithm. The larger the value, the more effectively the fault factor can trigger system errors, and the probability of selecting the fault factor will be greater. The specific calculation method will be described in detail later.

[0059] The above is a test case generation method based on syntax variation and random fault injection. The test cases generated in this way can effectively cover the potential fault scenarios of distributed database systems in complex environments, ensuring that different types of fault and SQL query combinations are fully tested. Dynamic adjustment of fault injection probability allows the test to focus on the most challenging test cases, thus improving test efficiency and coverage.

[0060] S430, determine the seeds that need to be updated by recording the error seed record table, and update the seed selection probability of the current round by using the two code coverage calculation seeds of the current round to determine the seeds that need to be updated.

[0061] The application significantly improves the test coverage, vulnerability discovery ability and test efficiency of the distributed database through the test case generation method based on syntax variation and random fault injection, the code coverage and reinforcement learning feedback mechanism, and the oracle combining consistency verification and difference test. The traditional database test method mainly relies on random SQL generation and static test cases, lacks test ability for distributed environment, and the consistency test tool focusing on distributed system cannot deeply cover the logic errors in the database. The SQL test case generation method based on syntax variation proposed in the application improves the diversity of test statements through the IR variation strategy, and combines random fault injection to simulate real distributed abnormal scenarios, ensuring that the test is more consistent with the running environment of the distributed database. At the same time, the traditional test tool often cannot dynamically optimize the test process, while the feedback mechanism of the application can dynamically adjust the SQL variation strategy and fault injection probability based on the execution result, so that the test can more efficiently trigger high-risk code paths and improve the vulnerability discovery ability. In addition, the existing oracle method cannot completely detect the multiple errors of the distributed database, and is prone to missed detection, the application combines consistency verification and difference test, compares the execution results of different databases and the operation history of the distributed system, and realizes comprehensive detection of the consistency and logic errors of the database. Therefore, compared with the existing method, the application not only improves the pertinence and coverage of the test case, but also can more effectively discover the potential vulnerabilities of the distributed database in complex scenarios, and improve the intelligentization and automation degree of the overall test.

[0062] The application is applied to Dqlite3.30.1 as an embodiment, and the execution flow is as follows Figure 2 First, start the to-be-tested database Dqlite3.30.1 and the control database MySQL8.0.25 and establish a database connection; then, input the test environment configuration file and database mode information conforming to the Dqlite syntax rules to construct an initial test environment; then, generate an initial SQL statement seed based on an abstract syntax tree, and separate the SQL statement execution structure data and type-driven variation using the IR variation method to generate diversified SQL test cases; then, randomly select a fault model, including network partition, node crash, consistency destruction, etc., and combine it with the SQL statement according to the set fault injection probability to form a complete test case set.

[0063] After the test case is generated, it is input into Dqlite3.30.1 for execution, the system records the execution result of the SQL statement and the change of the database state, and records the event information of each node through the timeline modeling to construct the global timeline. During the test process, the system will count the code coverage through the LLVM code insertion, and combine the signature analysis of the abstract timeline to analyze the execution influence of the SQL statement, so as to calculate the selection probability of the SQL statement. Subsequently, the fault injection strategy is dynamically adjusted by using the Q-learning feedback mechanism based on reinforcement learning, if a fault can efficiently trigger an error, the selection probability of the fault is increased, otherwise the influence of the fault is reduced, so as to improve the test efficiency.

[0064] After the execution is completed, the system analyzes the test result by using the oracle, and adopts the method of combining the consistency verification and the difference test to compare the SQL execution result. Specifically, the same SQL statement is respectively run in three environments: Dqlite3.30.1 in the complete fault environment, Dqlite3.30.1 without the influence of the fault, and the non-distributed control database MySQL8.0.25. If there is a difference in the test result, it is determined that the database may have a logical error, and if the test result violates the consistency rule, it is considered that the system has a consistency violation vulnerability. Then the system records the related SQL statement and fault information.

[0065] Finally, the system optimizes the fault factor selection probability based on the feedback, and updates the SQL test case seed pool. If no new error is found in the test, the SQL statement and the fault combination are continuously adjusted, and the test is re-executed until the preset test period is completed or the coverage threshold is reached. As long as a new database error is found, a test report containing the SQL statement, the fault model, the error log and the reproduction steps is generated and continuously updated, so as to provide the developer with the analysis and repair of the vulnerability.

[0066] It should be noted that the terms "first", "second" in the present application are only for description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first", "second" can explicitly or implicitly include one or more of the features. In the description of the present application, the meaning of "a plurality of" is two or more, unless otherwise specifically limited.

[0067] The above is a further detailed description of the present application in combination with specific preferred embodiments, and the specific implementation of the present application cannot be limited to these descriptions. For ordinary skilled persons in the technical field to which the present application belongs, a number of simple deductions or replacements can be made without departing from the concept of the present application, and all of them should be regarded as falling within the protection scope of the present application.

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. Comprise: 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, use the code coverage of the previous round to guide the mutation direction of the current seed, thereby mutating the current seed to obtain the SQL test case of the current round, and testing it on two different databases to obtain the code coverage of the current round; S300, in the current round, use the updated factor selection probability of the last round to select the current fault factor, and combine each current fault factor 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 to be tested, 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.

2. The method of claim 1, wherein, S100 comprises: S110, input the database configuration file and parse the database configuration file to build an abstract syntax tree; S120, generate an initial SQL statement based on the abstract syntax tree and use it as an initial seed; S130, use a predetermined initial selection probability and mutate the initial seed through IR to obtain a current seed.

3. The method of claim 2, wherein the method further comprises: S200 comprises: S210, use the code coverage of the previous round to calculate the seed selection probability and update the seed selection probability of the last round to obtain the seed selection probability of the current round; S220, use 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 case of the current round; S230, test the SQL test case of the current round on two different databases to obtain the two code coverages of the current round and record the error seed record table.

4. The method of claim 3, wherein the method further comprises: S210 comprises: S211, model the timing behavior of the database to be tested as an abstract timeline, and calculate the code coverage increment on the abstract timeline using the code coverage of the previous round; S212, calculate the frequency of each mutation seed in the seed pool and use it as a novelty score; S213, combine the code coverage increment, signature change of the abstract timeline, and novelty score to calculate the seed selection probability of each mutation seed.

5. The method for fuzz testing a relationally-oriented distributed database according to claim 4, wherein, The seed selection probability in S213 is represented by the formula: In the formula, represents the code coverage increment, represents the similarity difference value of the timeline signature, if the difference value exceeds the set similarity threshold, then , otherwise , represents the frequency of the variant seed in the seed pool, the lower the frequency, the higher the novelty, and are weight coefficients for balancing the influence of different factors on the seed selection probability.

6. The method of claim 3, wherein the method further comprises: S220 comprises: S221, use IR to separate the initial seed into a structure part and a data part; S222, according to the different types of IR structure, mutate the structure part and replace the data part with a predefined placeholder, and in the mutation process, use the seed selection probability of the current round to select the top k mutation seeds with the highest selection probability; S223, instantiate the mutation seed through the data dependency graph to obtain the SQL test case of the current round.

7. The method of claim 3, wherein the method further comprises: S400 comprises: S410, in the current round, performing consistency test and crash test on any current complete test case, and recording the current state of the database under test; S420, taking the current state as input of reinforcement learning, selecting a fault factor from the fault library by using the fault injection feedback mechanism of reinforcement learning, and updating the factor selection probability of the current round; S430, determining the seeds that need to be updated by the record table of error seeds, and updating the seed selection probability of the current round by using the two code coverage calculation seeds of the current round.

8. The method of claim 7, wherein the method further comprises: S420 includes: Taking the current state as input of reinforcement learning, selecting a fault factor from the fault library, injecting the fault factor into the database under test, and calculating the Q value of the fault factor according to the change of the database under test; and updating the factor selection probability of the current round by using the Q value.

9. The method of claim 1, wherein the method is performed by a relationship-oriented distributed database. The test target is that the round reaches the maximum number of tests or the code coverage reaches the threshold.

Images