Distributed database testing methods, related devices and media

Abstract

This disclosure provides a distributed database testing method, related apparatus, and medium. The method includes: determining the initial configuration state of the distributed database as the current configuration state; acquiring multiple test cases; executing the multiple test cases in the distributed database under the current configuration state, and after the test cases are executed, setting the call status flag of the underlying logic block called by the test cases to a first status value; adjusting the configuration parameters of the distributed database to update the current configuration state, updating the multiple test cases, and returning to the steps of executing the multiple test cases in the distributed database under the current configuration state, until the number of underlying logic blocks whose call status flags are set to the first status value reaches a predetermined condition. This disclosure improves the coverage of distributed database testing and more accurately detects vulnerabilities in the distributed database. This disclosure can be applied to distributed database testing scenarios.

Description

Technical Field

[0001] This disclosure relates to the field of databases, and in particular to a distributed database testing method, related apparatus and media. Background Technology

[0002] Distributed databases are increasingly being used in various scenarios due to their advantages of scalability, high performance, and high availability. However, to ensure the accuracy, integrity, and stability of data stored in a distributed database, it is necessary to test the distributed database before actual use.

[0003] However, some database testing tools and methods in related technologies often generate random database operation statements and execute them in the database. They then judge whether these statements were accurately executed based on the execution results, thus testing for database problems. These methods can only test for problems in a single configuration state. Distributed databases need to run in different configuration states, and the code paths and logical branches triggered in different configuration states differ. This means that some underlying logic blocks of a distributed database will not be executed in certain configuration states, and the testing process cannot cover these underlying logic blocks. Therefore, it cannot detect whether these blocks would cause errors if they were executed. Consequently, the test coverage is low, and it cannot accurately test for potential vulnerabilities in distributed databases. Summary of the Invention

[0004] This disclosure provides a distributed database testing method, related apparatus, and medium, which can improve the coverage of distributed database testing and more accurately detect potential vulnerabilities in distributed databases.

[0005] According to one aspect of this disclosure, a method for testing a distributed database is provided. The distributed database comprises multiple database nodes, each database node having multiple underlying logic blocks deployed on it. These underlying logic blocks support application operations on the database nodes, and the underlying logic blocks enabled in the distributed database are not entirely the same under different configuration states. The method includes: The initial configuration state of the distributed database is determined as the current configuration state; Obtain multiple test cases, which are used to invoke at least a portion of the underlying logic blocks opened in the distributed database; The multiple test cases are executed in the distributed database under the current configuration state, and after the test cases are executed, the call status flag of the underlying logic block called by the test cases is set to the first status value. Adjust the configuration parameters of the distributed database to update the current configuration state, update the multiple test cases, and return to the steps of executing the multiple test cases respectively in the distributed database under the current configuration state, until the number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition.

[0006] According to one aspect of this disclosure, a distributed database testing apparatus is provided, the apparatus comprising: The state determination unit is used to determine the initial configuration state of the distributed database as the current configuration state. The test case acquisition unit is used to acquire multiple test cases, wherein the test cases are used to call at least a portion of the underlying logic blocks opened in the distributed database; The test case execution unit is used to execute the plurality of test cases respectively in the distributed database under the current configuration state, and after the test case is executed, to set the call status flag of the underlying logic block called by the test case to a first status value; The configuration change unit is used to adjust the configuration parameters of the distributed database to update the current configuration status, update the multiple test cases, and trigger the test case execution unit and the configuration change unit to re-execute until the number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition.

[0007] Optionally, the distributed database testing apparatus further includes a tagging unit, which is used for: The underlying logic source code of the distributed database is divided into underlying logic blocks, a call status mark change task is generated for the underlying logic block, and the call status mark change task is associated with the underlying logic block; The underlying logic block and the call status flag change task associated with the underlying logic block are compiled to obtain a compiled file. The compiled file is then deployed to each database node so that each database node can parse the underlying logic block from the compiled file. The step of setting the call status flag of the underlying logic block called by the test case to a first status value after the test case is executed includes: after the test case is executed by calling the underlying logic block, using the call status flag change task associated with the underlying logic block, setting the call status flag of the underlying logic block to the first status value.

[0008] Optionally, the initial value of the call status flag of the underlying logic block is a second status value; The use case execution unit is further configured to: if the call status flag of the underlying logic block changes from the second status value to the first status value, increment the first count by 1, wherein the first count is used to indicate the number of the underlying logic blocks that have been called; The configuration change unit is specifically used to: if the first count reaches the predetermined condition, determine that the number of underlying logic blocks whose call status flag is set to the first status value reaches the predetermined condition.

[0009] Optionally, the configuration change unit is specifically used for: If the first count remains unchanged during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the configuration parameters of the distributed database are adjusted to update the current configuration state.

[0010] Optionally, the distributed database testing device further includes a statement generation unit, which is specifically used for: A first number of database modification code statements are generated and executed in the distributed database so that the distributed database modifies the data storage state of the distributed database according to the database modification code statements, wherein the first number is less than a first threshold. Initialize the second counter to the first number; The configuration change unit is specifically used for: If, during the execution of a predetermined number of consecutive test cases among the multiple test cases, the first count remains unchanged and the second count is less than the first threshold, then a database modification statement is added, sent to the distributed database for execution, and the number of database modification statements is increased, the second count is increased, multiple test cases are updated, and the test case execution unit and the configuration change unit are triggered to re-execute. If, during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the first count remains unchanged and the second count is not less than the first threshold, then the configuration parameters of the distributed database are adjusted to update the current configuration state.

[0011] Optionally, the configuration change unit is specifically used for: If the second count is not less than the first threshold and the third count is less than the second threshold, the distributed database is cleared, the second count is set to 0, the third count is incremented by 1, multiple test cases are updated, and the test case execution unit and the configuration change unit are triggered to re-execute. If the second count is not less than the first threshold and the third count is not less than the second threshold, adjust the configuration parameters of the distributed database and set the second count and the third count to 0.

[0012] Optionally, the use case acquisition unit is specifically used for: For each test case to be generated, the test case type is determined, and the test case template corresponding to the test case type is determined. The test case template is a database operation statement template determined based on the syntax of the distributed database. For each test case to be generated, a seed sequence to be mutated is obtained from the first seed pool, and the seed sequence to be mutated is mutated to obtain the mutated binary sequence corresponding to the test case to be generated, wherein the seed sequence to be mutated is a binary sequence. The mutated binary sequence corresponding to each test case to be generated is filled into the test case template corresponding to the test case to be generated, thereby obtaining the test case; The distributed database testing device also includes a seed sequence processing unit, which is specifically used for: If the first count changes during the execution of the test case, the mutated binary sequence corresponding to the test case is added to the first seed pool.

[0013] Optionally, the use case generation unit is specifically used for: In the first seed pool, the candidate seed sequences are sorted from largest to smallest according to the first weight coefficient, and the seed sequence to be mutated is determined from the candidate seed sequences based on the sorting result; Reduce the first weight coefficient corresponding to the seed sequence to be mutated.

[0014] Optionally, the use case execution unit is specifically used for: When the test case is a database query statement, a single-node database is created based on the data storage status of the distributed database. The data stored in the single-node database consists of the data in each storage node of the distributed database. The test cases corresponding to the test case types are executed in the distributed database and the single-node database respectively, and the first execution result of the test cases executed in the distributed database and the second execution result of the test cases executed in the single-node database are recorded. The test result is determined based on the comparison between the first execution result and the second execution result.

[0015] Optionally, the use case execution unit is specifically used for: When the test case includes multiple database modification test statements, a state snapshot is generated based on the data storage state of the distributed database. The state snapshot is used to characterize the data storage state of the distributed database before the execution of the multiple database modification test statements. The multiple database modification test statements are executed concurrently in the distributed database to obtain a third execution result, which is used to characterize the data storage status of the distributed database after the concurrent execution of the multiple database modification test statements. The multiple database modification test statements are permuted to obtain a sorted list of test statements. Each test statement is sequentially sorted to determine the order to be executed, and a first test process is executed based on the order to be executed. The first test process includes: rolling back the distributed database based on the state snapshot, and sequentially executing the multiple database modification test statements according to the order to be executed in the rolled-back distributed database to obtain a fourth execution result corresponding to the order to be executed. The fourth execution result is used to characterize the data storage state of the distributed database after the multiple database modification test statements are executed sequentially according to the order to be executed; if the fourth execution result is different from the third execution result, the next test statement is sorted to determine a new order to be executed, and the first test process is executed based on the order to be executed until the fourth execution result corresponding to the order to be executed is consistent with the third execution result or the order to be executed is the last order of the test statements, to obtain a test result.

[0016] Optionally, the configuration change unit is specifically used for: A seed configuration file is determined from a configuration file seed pool, which includes multiple configuration files of the distributed database. The seed configuration file is one of the multiple configuration files and includes multiple configuration items. A mutation configuration item is determined from a plurality of configuration items in the seed configuration file, wherein the mutation configuration item is a plurality of configuration items; The parameter mutation method is determined based on the configuration parameter type of the mutation configuration item, and the configuration parameters of the mutation configuration item are mutated based on the parameter mutation method. The configuration file of the distributed database is then updated based on the mutated configuration parameters.

[0017] Optionally, the configuration file of the distributed database includes a deployment configuration file and a non-deployment configuration file, wherein the deployment configuration file is used to add or delete database nodes of the distributed database and set the topology structure of the database nodes, and the configuration change unit is specifically used for: Each time the configuration file is modified, the fourth counter is incremented by 1, and the fourth counter is set to 0 when the number of underlying logic blocks whose call status flag is set to the first status value changes. When the fourth count is not greater than the third threshold, the mutation count of each of the non-deployment configuration files in the configuration file seed pool is determined, and the non-deployment configuration file with the fewest mutation counts is determined as the seed configuration file, and the mutation count corresponding to the seed configuration file is incremented by 1; When the fourth count is greater than the third threshold, the number of mutations of each deployment configuration file is determined, and the deployment configuration file with the fewest mutations is determined as the seed configuration file, and the fourth count is set to 0.

[0018] Optionally, the configuration change unit is specifically used for: Based on the second weight coefficient corresponding to each configuration item, the mutation probability of each configuration item is determined, and based on the mutation probability of each configuration item, the mutated configuration item is determined from multiple configuration items in the seed configuration file. The current configuration state obtained after mutating the mutated configuration item is determined as the first configuration state corresponding to the mutated configuration item. If, during the execution of a test case in the first configuration state, the number of underlying logic blocks whose call status flag is set to the first status value remains unchanged, the second weight coefficient corresponding to the mutation configuration item is reduced. If, during the execution of a test case in the first configuration state, the number of underlying logic blocks whose call status flag is set to the first status value changes, the second weight coefficient corresponding to the mutation configuration item is increased.

[0019] Optionally, the configuration change unit is specifically used for: Obtain a configuration item association model, wherein the configuration item association model is used to indicate the associated configuration items of each configuration item in the configuration file, as well as the conflict configuration parameter pairs between each configuration item and the associated configuration item corresponding to the configuration item, wherein the conflict configuration parameter pairs include a first configuration parameter corresponding to the configuration item and a second configuration parameter corresponding to the associated configuration item; Based on the configuration item association model, the associated configuration item corresponding to the mutated configuration item is determined. If the configuration parameter of the mutated configuration item is consistent with the first configuration parameter in the conflicting configuration parameter pair and the configuration parameter of the associated configuration item is consistent with the second configuration parameter in the conflicting configuration parameter pair, the configuration parameter of the mutated configuration item is mutated again based on the parameter mutation method.

[0020] Optionally, the configuration change unit is specifically used for: For each configuration item in the configuration file, set the set of available parameters for that configuration item; After mutating the configuration parameters of the mutated configuration item based on the parameter mutation method, the method further includes: If the configuration parameters of the mutated configuration item do not exist in the available parameter set corresponding to the mutated configuration item, the configuration parameters of the mutated configuration item are mutated again based on the parameter mutation method.

[0021] Optionally, the booking conditions include one of the following: The number of underlying logic blocks whose call status flag is set to the first status value is equal to the total number of underlying logic blocks in the distributed database; The number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined number, which is less than the total number of underlying logic blocks in the distributed database; According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the distributed database testing method as described above.

[0022] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the distributed database testing method described above.

[0023] According to one aspect of this disclosure, a computer program product is provided, comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the distributed database testing method as described above. In the testing of distributed databases, covering as many underlying logic blocks as possible during test case execution is crucial for accurately identifying potential vulnerabilities. If some underlying logic blocks are consistently unreachable, it becomes impossible to test whether those blocks will malfunction when invoked to perform their intended functions. Furthermore, in each configuration state, only a subset of underlying logic blocks are enabled in a distributed database, and the enabled blocks vary across different configuration states. Therefore, this embodiment of the disclosure continuously adjusts the configuration parameters of the distributed database during testing to update its current configuration state and retrieves and executes test cases within the distributed database under different current configuration states. In this way, the underlying logic blocks enabled under different configuration states can be invoked during the testing process, allowing the testing process to cover as many underlying logic blocks as possible and improving the coverage of the testing process. At the same time, the invocation status flags of the underlying logic blocks are used to consider whether each underlying logic block has been invoked. If the total number of invoked underlying logic blocks has not reached the predetermined condition, the configuration state of the distributed database is updated by modifying the configuration file, and the test cases are retrieved and executed again, thereby invoking more underlying logic blocks during the testing process until the total number of invoked underlying logic blocks reaches the predetermined condition. If the total number of invoked underlying logic blocks determined by the invocation status flags in each updated configuration state reaches the predetermined condition, it means that enough underlying logic blocks in the distributed database have been invoked during the testing process. The underlying logic blocks invoked during the testing of the distributed database have covered enough underlying logic blocks in the underlying logic source code of the distributed database. In other words, the testing process has comprehensively tested whether each underlying logic block will malfunction when it is invoked to execute the corresponding function. At this point, the potential vulnerabilities of the distributed database can be accurately detected, and the testing ends. Based on this, the embodiments of this disclosure improve the coverage of distributed database testing and can more accurately test for potential vulnerabilities in distributed databases. Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0024] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0025] Figure 1This is an architecture diagram of the system to which the distributed database testing method according to the embodiments of this disclosure is applied; Figure 2A and Figure 2B This is a schematic diagram illustrating the application of an embodiment of this disclosure in a distributed database testing scenario; Figure 3 This is a flowchart of a distributed database testing method according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram illustrating the process of collecting call status flags of various underlying logic blocks according to an embodiment of this disclosure; Figure 5 This is a schematic diagram illustrating specific conditions according to a predetermined condition in one embodiment of this disclosure; Figure 6 This is a flowchart of a distributed database testing method according to another embodiment of the present disclosure; Figure 7 yes Figure 6 A schematic diagram of step 602 in the process; Figure 8 This is a flowchart of a distributed database testing method according to another embodiment of the present disclosure; Figure 9 This is a flowchart of a distributed database testing method according to another embodiment of the present disclosure; Figure 10 This is a schematic diagram illustrating step 302 of generating test cases according to an embodiment of this disclosure; Figure 11 This is a schematic diagram of the code for the test cases generated in step 302 of an embodiment of this disclosure; Figure 12 yes Figure 9 Sub-flowchart of step 902; Figure 13 yes Figure 3 A sub-flowchart of step 303; Figure 14 This is a flowchart illustrating the process of executing test cases in step 303 according to an embodiment of this disclosure; Figure 15 yes Figure 3 A sub-flowchart of step 303; Figure 16 yes Figure 3 A sub-flowchart of step 304; Figure 17 yes Figure 16 A sub-flowchart of step 1601; Figure 18 yes Figure 17 A sub-flowchart of step 1604; Figure 19 yes Figure 18 Flowcharts of steps 1801 and 1802; Figure 20 yes Figure 3 A sub-flowchart of step 304; Figure 21 According to one embodiment of this disclosure, Figure 20 A flowchart illustrating steps 2001 to 2003. Figure 22 This is a schematic diagram of the configuration file modified in steps 2001 to 2003 according to an embodiment of this disclosure; Figure 23 yes Figure 20 A sub-flowchart of step 2001; Figure 24 This is a schematic diagram of the configuration file modified in step 2303 according to an embodiment of this disclosure; Figure 25 yes Figure 20 A sub-flowchart of step 2002; Figure 26 yes Figure 20 A sub-flowchart of step 2003; Figure 27 yes Figure 20 Another sub-flowchart of step 2003; Figure 28 This is a flowchart illustrating step 2003 according to an embodiment of the present disclosure; Figure 29 By according to Figure 3 The provided distributed database testing method is used to test the TDSQL database. (Test results are shown in the figure.) Figure 30 This is a process diagram illustrating a specific implementation example of the distributed database testing method according to an embodiment of this disclosure; Figure 31 This is a block diagram of a distributed database testing apparatus according to an embodiment of the present disclosure; Figure 32 It is performed according to the embodiments of this disclosure. Figure 3 The terminal structure diagram of the distributed database testing method is shown below; Figure 33 It is performed according to the embodiments of this disclosure. Figure 3 The server architecture diagram for the distributed database testing method is shown. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0027] Distributed databases are increasingly being used in various scenarios due to their advantages of scalability, high performance, and high availability. However, to ensure the accuracy, integrity, and stability of data stored in a distributed database, it is necessary to test the distributed database before actual use.

[0028] However, some database testing tools and methods in related technologies often generate random database operation statements and execute them in the database. They then judge whether these statements were accurately executed based on the execution results, thus testing for database problems. These methods can only test for problems in a single configuration state. Distributed databases need to run in different configuration states, and the code paths and logical branches triggered in different configuration states differ. This means that some underlying logic blocks of a distributed database may not be executed in certain configuration states, thus failing to detect whether they would cause errors if executed. Therefore, the test coverage is low and cannot accurately test for potential vulnerabilities in distributed databases.

[0029] Based on this, this disclosure proposes a distributed database testing method that can improve the coverage when testing distributed databases and more accurately detect potential vulnerabilities in distributed databases.

[0030] System architecture and scenario description of the embodiments disclosed herein Figure 1 This is an architecture diagram of a distributed database testing system applied to the distributed database testing method according to embodiments of the present disclosure. It includes: a distributed database instance 110, a configuration generator 120, a test case generator 130, a call status flag collector 140, and a controller 150. These units can be centrally deployed on a single server or terminal to form a distributed database testing system, or they can be deployed separately on different terminals or servers and communicate with each other to form a distributed database testing system.

[0031] Distributed database 110 is the database being tested. Distributed database 110 includes multiple database nodes 111 deployed on different hardware entities. These database nodes 111 each deploy components to implement various functions of the distributed database 110, such as database table components for organizing stored data, data backup and recovery components for protecting data from corruption, transaction management components for ensuring the ACID (Atomicity, Consistency, Isolation, and Durability) characteristics of the distributed database, and log components for recording all operations on the distributed database. Each database node 111's components are implemented through deployed underlying logic blocks. These underlying logic blocks are code blocks composed of the low-level code used to implement the corresponding functions of the database node 111. Each database node deploys multiple underlying logic blocks, each of which can be a basic block. When the distributed database receives an input database operation statement, it calls these underlying logic blocks to implement the corresponding operation. The underlying logic blocks called by each statement constitute the code path corresponding to that database operation statement.

[0032] Configuration generator 120 generates configuration files for the distributed database and modifies the database configuration based on the generated configuration files. Specifically, configuration generator 120 can pre-store all configuration files for the distributed database. These include configuration files defining connectivity between database nodes, and configuration files setting storage space utilization and data storage methods for each database node. These configuration files contain multiple configuration items, and configuration generator 120 generates the distributed database configuration files by modifying the configuration parameters of these items or by adding or deleting certain configuration items.

[0033] The test case generator 130 is used to generate test cases required for testing the distributed database 110. The generated test cases can include various database operation statements, such as DQL statements, DDL statements and DML statements. The test cases generated by the test case generator 130 are input into the distributed database 110 and the database operation statements contained in the test cases are executed in the distributed database 110.

[0034] The call status marker collector 140 communicates with each database operation node 111 to collect the call status markers corresponding to the underlying logic blocks of each database node 111. Each underlying logic block has a corresponding call status marker. After the test case is input into the distributed database, the corresponding function of the test case will be implemented by calling the underlying logic blocks in some database nodes 111. When a certain underlying logic block is called, the corresponding call status marker will be set to the first status value. After that, after executing each test case, the call status marker collector will collect the call status markers corresponding to each underlying logic block, determine which underlying logic blocks have been called based on the value of the call status marker, and generate the corresponding collection results.

[0035] The controller 150 is connected to the configuration generator 120, test case generator 130, and call status marker collector 140, and is used to control the testing process of the distributed database based on the information collected by the call status marker collector 140. Specifically, the controller 150 receives the collection results generated by the call status marker collector 140 and determines the subsequent testing process based on the collection results. For example, if the collection results indicate that a large number of underlying logic blocks have not been called, the controller controls the test case generator 130 to generate new test cases to continue testing the distributed database 110; or, the controller controls the configuration generator 120 to generate new configuration files to modify the configuration state of the distributed database, and after modifying the configuration state of the distributed database, the controller controls the test case generator to generate new test cases to test the distributed database after the configuration state has been modified; or, if the collection results indicate that most of the underlying logic blocks have been called, the controller stops further testing of the distributed database.

[0036] In addition, refer to Figure 1 The distributed database testing system can also be configured with a deployer for deploying the distributed database based on the configuration file generated by the configuration generator 120, and a test result collector for collecting test results during the testing process. The embodiments disclosed herein can be applied in various scenarios, such as the scenario of testing TDSQL as shown in Figure 2.

[0037] Reference Figure 2A The distributed database is a TDSQL database with four database nodes (nodes 1 to 4). Each database node deploys its corresponding database components. Multiple test cases are then obtained to test the distributed database. These test cases consist of randomly generated database operation statements. When these database operation statements are executed in the distributed database, the corresponding underlying logic blocks are automatically invoked to perform the operations corresponding to those statements. For example, in... Figure 2AIn the example, test case 1 requires some functionality from components A and B. Therefore, when executing test case 1, it will call some underlying logic blocks in nodes 2 and 3, generating the corresponding test results. After executing multiple test cases, the distributed database configuration file is modified. For example, refer to... Figure 2B Add a configuration item `memory-use-limit` to the configuration file to configure the memory usage limit for each storage node, and set its configuration parameter to 10GB, meaning each storage node can use a maximum of 10GB of storage space. Simultaneously, change the configuration parameter of the `abort-on-panic` configuration item from `true` to `false`, so that when the distributed database encounters an unhandled exception during operation, it will continue running in the abnormal state instead of immediately terminating the process to ensure data consistency. Also, modify the configuration parameter of the `block-size` configuration item in `rocksdb.lockcf`, changing the block size of the distributed database's locking tables from 16KB to 32KB. Afterwards, obtain new test cases. Because of the added memory usage limit for each storage node after the configuration file changes, when executing test cases that need to write new data to the distributed database, the underlying logic block used for memory usage detection will be executed to check whether the memory space used by each storage node exceeds 10GB. For example, the function of detecting memory usage is implemented through component C deployed on node 4. Before the configuration file of the distributed database was changed, there was no configuration item in the configuration file to set the memory usage limit for each storage node. During the execution of test cases, the underlying logic block in node 4 used to determine the amount of memory space used by the storage nodes would not be called, so it was impossible to test whether there were any problems with this part of the underlying logic block. After adding the memory-use-limit configuration item to the configuration file, when the test cases are executed, the underlying logic block used in node 4 to determine whether the memory space used by each storage node exceeds the limit will be called, thereby testing whether there are any problems with this part of the underlying logic block. In addition, when an unhandled exception is encountered during the operation of the database, the process will not be terminated directly, but the database will continue to run under the condition of exception, thereby executing some logical branches that would only be executed under the exception state and calling the underlying logic blocks required to implement these logical branches. Based on this, the coverage of the distributed database test can be improved, and vulnerabilities in the distributed database can be tested more accurately.

[0038] It should be understood that the above description only illustrates some application scenarios of this disclosure. Application scenarios of this disclosure may include, but are not limited to, the specific embodiments described above.

[0039] General Description of Embodiments in this Disclosure According to one embodiment of this disclosure, a distributed database testing method is provided for testing a distributed database. The distributed database includes multiple database nodes, and each database node deploys multiple underlying logic blocks. These underlying logic blocks support application operations on the database nodes, and the underlying logic blocks enabled in the distributed database are not entirely the same under different configuration states. (Refer to...) Figure 3 The methods include: Step 301: Use the initial configuration state of the distributed database as the current configuration state; Step 302: Obtain multiple test cases. The test cases are used to call at least a portion of the underlying logic blocks opened in the distributed database. Step 303: Execute multiple test cases in the distributed database under the current configuration state, and after the test cases are executed, set the call status flag of the underlying logic block called by the test cases to the first status value; Step 304: Adjust the configuration parameters of the distributed database to update the current configuration state, update multiple test cases, and return to the steps of executing multiple test cases in the distributed database under the current configuration state until the number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition.

[0040] Database nodes are the nodes where various database components of a distributed database are deployed. These nodes implement the functionality of their respective database components by running portions of the distributed database's source code. Low-level logic blocks are the smallest units of code required to perform various operations on the distributed database. They support user applications performing various operations on the distributed database, such as adding, deleting, modifying, and querying data, as well as organizing data into specific database tables, indexes, and views. A low-level logic block can be a basic block obtained by slicing the distributed database's source code file. It consists of several lines of code executed sequentially. During execution, the code in a low-level logic block is executed sequentially from the first line to the last. Execution does not begin from any line other than the first line, nor does it stop before reaching the last line of the block. In other words, once a low-level logic block is invoked, all its contained code statements are executed sequentially without skipping any lines. Specifically, the source code of a distributed database can be converted into a corresponding code flowchart. In the code flowchart, the code block corresponding to each process item can be regarded as a basic logic block. For example, for a switch case statement, there are multiple logical branches. When the corresponding variable takes different values, the code corresponding to different cases is executed. In this case, the code corresponding to a certain case can be regarded as a low-level logic block.

[0041] For example, consider the following code snippet: switch oldName { case "enable-slow-log": cfg.Instance.EnableSlowLog.Store(cfg.Log.EnableSlowLog.Load()) case "slow-threshold": cfg.Instance.SlowThreshold = cfg.Log.SlowThreshold } This code snippet includes a switch case example, which forms two logical branches based on the value of the variable oldName. When oldName is enabled-slow-log, the statement cfg.Instance.EnableSlowLog.Store(cfg.Log.EnableSlowLog.Load()) is executed, which can be divided into a low-level logic block. When oldName is slow-threshold, the code executed, i.e., the statement cfg.Instance.SlowThreshold = cfg.Log.SlowThreshold, can also be divided into a low-level logic block.

[0042] It is understood that, in this application, the enabled underlying logic block refers to the underlying logic block that can be invoked when executing test cases in the current configuration state. Because different underlying logic blocks are used to implement the functions of different components of the distributed database, these database components may be enabled or disabled in different configuration states, and some of their operating parameters differ when enabled. For example, parameters such as storage space utilization and database node IP addresses can vary considerably. When these component parameters change, the underlying logic blocks that can be invoked when executing database operation statements in the distributed database are not entirely the same. For example, the distributed database has two database nodes, A and B. Database node A includes underlying logic blocks A1 and A2, and database node B includes underlying logic blocks B1 and B2. In configuration state 1, underlying logic blocks A1 and B1 are enabled. In configuration state 2, underlying logic blocks A1 and B2 are enabled. Therefore, the enabled underlying logic blocks are not entirely the same in configuration state 1 and configuration state 2.

[0043] In step 301, the initial configuration state of the distributed database refers to the configuration state of the distributed database when testing begins. It can be understood that when deploying the distributed database to database nodes, corresponding configuration files are needed to configure which database nodes the distributed database uses, the connectivity between database nodes, the connection attributes of the database server, the data storage method of the storage nodes, and the database access permissions, etc. These configuration items in the configuration files constitute a configuration state of the distributed database.

[0044] In step 302, a test case is an input used to test whether the underlying logic source code of the distributed database will encounter errors during execution. It contains a specific set of inputs and corresponding standard outputs. By performing corresponding operations on the distributed database based on these inputs and comparing the actual output with the standard output, it is determined whether the distributed database has encountered errors during execution. In this embodiment, the test case includes database operation statements required for testing the distributed database. These statements are used to perform operations such as defining database objects like tables, indexes, and views in the distributed database; writing data to be stored in the distributed database; modifying or deleting data already stored in the distributed database; or querying whether the distributed database stores certain data. Specifically, a test case can consist of one or more SQL statements. These database operation statements are the code statements that users might input into the distributed database when using it. Using these statements as test cases can simulate the actual usage environment of the distributed database, thereby testing whether the distributed database will encounter errors during actual use.

[0045] Specifically, refer to Figure 1 In a system used for testing distributed databases, a test case generator 130 can be set up. This test case generator 130 can generate a large number of database operation statements and construct these database operation statements into test cases for the distributed database. Then, the test cases generated by the test case generator 130 can be retrieved.

[0046] In step 303, the call status flag is used to indicate whether the underlying logic block has been called. Specifically, a variable can be set for each underlying logic block as its corresponding call status flag, and the value of the call status flag indicates whether the underlying logic block has been called. The first status value is used to indicate that the underlying logic block has been called when executing the database operation statements contained in the test case. It can be understood that the first status value can be a pre-set value, such as 1, and the initial value of each call status flag can be a value other than 1. For example, the initial value can be set to 0. In this case, when the call status flag corresponding to a certain underlying logic block is 0, it indicates that the underlying logic block has not been called during the execution of all previous test cases. Conversely, when the call status flag corresponding to a certain underlying logic block is 1, it indicates that the underlying logic block has been called during the execution of all previous test cases.

[0047] Reference Figure 1In the distributed database test system, a call status flag collector 140 is set up. This collector 140 can communicate with each database node. When deploying the distributed database, the source code files are divided into multiple underlying logical blocks, and a variable is assigned to each block as its corresponding call status flag. A call status flag summary table can be created in the call status flag collector 140 to record the value of each variable used as a call status flag. Then, refer to... Figure 4 The various components of the distributed database are deployed to each database node. At this point, the call status flags corresponding to each underlying logic block have initial values, such as 0 for each call status flag. After executing each test case, each database node first organizes the call status flag values ​​of all underlying logic blocks on its node into a call status flag table. For example, in... Figure 4 In the example, database node 1 deploys component A, which includes four underlying logic blocks, denoted as A1, A2, A3, and A4. When executing test cases, underlying logic blocks 2 and 3 in database node 1 are invoked, and the corresponding invocation status flags are set to the first status value, i.e., 1. This results in the invocation status flag table A corresponding to database node 1. Subsequently, the invocation status flag collector 140 retrieves the corresponding invocation status flag table from each database node, thereby collecting the values ​​of the invocation status flags corresponding to each underlying logic block in each database node and summarizing them in its local invocation status flag summary table. When it detects that the invocation status flag corresponding to a certain underlying logic block sent by a database node is set to the first status value, the invocation status flag variable in the local invocation status flag summary table of the invocation status flag collector 140 is set to the first status value. It should be noted that during testing, when the call status flag corresponding to a certain underlying logic block in the call status flag summary table is set to the first status value, the call status flag of that underlying logic block will remain in the first status value and will not be reset to the initial value until the test process ends. Thus, the call status flag summary table stored in the call status flag collector 140 can be used to determine which underlying logic blocks have been called, and this can be used to control the subsequent test process. It should also be noted that some database nodes deploy the same components. For these database nodes with the same components, the underlying logic blocks they contain are the same, but the underlying logic blocks called when executing test cases can be different. For example, in... Figure 4In this scenario, database node 1 and database node 2 deploy the same component, component A. However, during test case execution, underlying logic blocks A2 and A3 in database node 1 are invoked, while underlying logic blocks A1 and A4 in database node 2 are invoked. In this case, the call status flag tables of these database nodes deploying the same component can be aggregated into a call status flag table corresponding to the component, and then summarized in the call status flag collector. Furthermore, since the number of database nodes corresponding to each component is different, for example... Figure 4 In this example, component A is deployed to two database nodes, while components B and C are deployed to only one node. To ensure the standardization and readability of the aggregated data format, the component deployed to fewer nodes can have its length padded by calling the status flag table. Specifically, this can be done by padding the length with a second status value (0 in this embodiment). Figure 4 In the process, the length of each underlying logic block in the call status flag table corresponding to component B and component C is padded to 2 digits to have the same format as the call status flag table of component A, and then summarized into the call status flag collector 140.

[0048] In one embodiment, the call status flag collector 140 can also use a bitmap to store the value of the call status flag corresponding to each underlying logic block. Specifically, the order of each underlying logic block is predefined, and then each bit of the bitmap is allocated according to this order to record the value of the call status flag corresponding to that underlying logic block. For example, if the number of underlying logic blocks is n, and they are sequentially labeled as underlying logic block 1 to underlying logic block n, then an n-bit bitmap is set, where the value of the m-th bit (1≤m≤n) is the value of the call status flag corresponding to underlying logic block m. Based on this, it is not necessary to store the variable name of each call status flag itself; only the value of the call status flag corresponding to the underlying logic block needs to be stored. This further reduces the storage space required to store the call status flags corresponding to each underlying logic block, saving storage resources.

[0049] Furthermore, some underlying logic blocks may be deployed to multiple database nodes simultaneously. During testing, it is necessary to check whether these underlying logic blocks can be accurately invoked and executed when deployed to different database nodes. That is, when the same underlying logic block is deployed to different database nodes, a call status flag for that underlying logic block needs to be generated separately on each database node. At this time, in the call status flag collector 140, a bitmap can be created for each underlying logic block, and the bits in the bitmap represent the invocation status of the underlying logic block in each database node. For example, if underlying logic block a is deployed to k database nodes from node 1 to node k, then a bitmap containing k bits is created for underlying logic block a, where the x-th bit is the value of the call status flag of underlying logic block a in the x-th database node. In this way, when the same underlying logic block is deployed to multiple database nodes simultaneously, it is also possible to accurately determine whether the underlying logic block in each database node is invoked during the execution of test cases.

[0050] Specifically, after obtaining multiple test cases, when executing these test cases in the distributed database—that is, executing the database operation statements contained within the test cases—the corresponding underlying logic blocks are invoked to implement the corresponding operations of the database operation statements. For example, when executing a test case, the required database operation statement is first parsed, and a syntax tree representing the syntax structure of that statement is generated. During this process, a portion of the database's parser component is invoked to parse the database operation statement and create the corresponding syntax tree, using underlying logic blocks. Next, underlying logic blocks for implementing permission checks are invoked to determine if sufficient permissions are available to execute the database operation statement. Finally, at least one execution plan is generated based on the syntax tree generated by the parser, and this execution plan is executed by the database's executor component. During this process, the executor calls corresponding functions (composed of underlying logic blocks) according to the execution plan to complete the operations required by the database operation statement. For example, a test case to be executed might contain a SELECT statement with the following structure: SELECT column1, column2 FROM table, where table is the field used to fill in the table name, and column1 and column2 are the fields used to fill in the column names. This statement indicates that it wants to search for data in the columns specified by column1 and column2 from the table specified by the table field. When this statement is executed, firstly, a field extraction function extracts the fields table and column1 and column2 used to specify the table name or column name from the SELECT statement; then, a field parsing function is called to parse the fields table and column1 and column2 to obtain the corresponding table name or column name; then, a lookup function is called to search the distributed database to see if there exists a table corresponding to the table name specified by the table field, and if there exists a column corresponding to the column names specified by column1 and column2 in this table. If they exist, the data in that column is returned. In this process, calling each function is actually calling the underlying logic blocks required to implement these functions. After these underlying logic blocks are invoked, the invocation status flag corresponding to the invoked underlying logic block is set to the first status value to indicate that the underlying logic block is invoked during the execution of the test case.

[0051] Understandably, when test cases are executed, corresponding test results are generated based on the execution outcomes. For example, if a distributed database stores certain data, but a query to retrieve that data shows the data is not stored in the database, this indicates an error in the execution of the database query. In this case, a corresponding error report is generated as the test result. The process of executing test cases and generating test results based on their outcomes can be found in database testing procedures in related technologies, and will not be elaborated upon here.

[0052] In step 304, after executing the acquired test cases, the database configuration parameters are adjusted to change the current configuration state of the distributed database. Specifically, the distributed database has multiple configuration files, which are used to configure the topology of the distributed database, the relevant attributes of the database server, and the relevant attributes of the database nodes themselves. Each configuration file contains several configuration items, and each configuration item is used to set the configuration parameters of attributes, such as setting the IP addresses of some database nodes, configuring whether certain functions of some nodes are enabled, etc. The current configuration state of the database can be updated by modifying the parameters of the configuration items in these configuration files. Specifically, the current configuration state can be updated by modifying the configuration values ​​of the configuration items in the distributed database configuration files. In one possible implementation, the configuration file can also be modified by writing a new configuration item to a configuration file or deleting an existing configuration item from a configuration file. The details of modifying the distributed database configuration files will be explained in detail later and will not be elaborated here.

[0053] Specifically, refer to Figure 1 The system used for testing the distributed database includes a configuration generator 120. This generator stores the various configuration files for the distributed database, allowing modification of configuration parameters for specific items within these files. After modification, the updated configuration file is sent to the deployer. The deployer then restarts the distributed database based on the received file or redeploys it according to the modified configuration, ensuring the database runs in the current configuration state corresponding to the updated file. Details regarding modifying the distributed database configuration files will be explained later and will not be elaborated upon here.

[0054] When the database configuration file is modified, the process returns to step 302 to obtain new test cases. Since the current configuration state of the distributed database has changed, executing test cases in the updated configuration state may call underlying logic blocks that were previously inaccessible. This allows testing to determine if errors occur when calling these underlying logic blocks, thereby improving test coverage and more accurately identifying vulnerabilities in the distributed database. For example, if the distributed database is a TDSQL database, and the Tdstore function on some nodes was disabled before adjusting configuration parameters, then the underlying logic blocks used to implement the Tdstore function would not be called during test case execution. However, when Tdstore is enabled during configuration parameter adjustment, subsequent test case executions will call the corresponding underlying logic blocks when database operation statements within the test cases require the use of the Tdstore function. Therefore, compared to testing the distributed database in a single configuration state, modifying the distributed database configuration file allows testing whether more underlying logic blocks will malfunction when called, resulting in a more comprehensive test of the distributed database.

[0055] Understandably, testing a distributed database involves verifying whether each underlying logical block can be correctly invoked and performs its intended function. If the number of invoked underlying logical blocks, or the percentage of invoked underlying logical blocks in the distributed database source code, does not meet certain criteria, the testing is considered incomplete. Many underlying logical blocks remain uninvoked during test case execution, making it impossible to determine whether invoking these blocks will cause errors. In such cases, the distributed database configuration file needs modification to update the current configuration and re-obtain and execute test cases under the updated configuration. This process continues until the number of invoked underlying logical blocks, or the percentage of invoked underlying logical blocks in the distributed database source code, reaches a certain threshold. At this point, the distributed database can be considered relatively comprehensively tested, and the system can fully verify whether each underlying logical block will malfunction when invoked to execute test cases. The testing process can then be considered complete, and the testing process can be terminated.

[0056] In the embodiments disclosed in steps 301 to 304, test cases are first obtained and the database operation statements contained in these test cases are executed in the distributed database. During the execution of these database operation statements, underlying logic blocks deployed on some database nodes are invoked, thereby testing whether errors occur when these underlying logic blocks are invoked to perform operations on the distributed database. Afterwards, the configuration file of the distributed database is modified, and test cases are re-obtained to test the distributed database with the modified configuration file. By adjusting the configuration parameters of the distributed database, the testing process can invoke as many underlying logic blocks as possible that are only enabled under different configuration states. During testing, for each underlying logic block, a call status flag is used to determine whether the underlying logic block has been called during the execution of test cases. The coverage of the test process is judged based on the number of underlying logic blocks whose call status flag is set to the first value. When the number of underlying logic blocks whose call status flag is set to the first value does not meet the preset condition, the configuration file is continuously modified and new test cases are obtained to test the distributed database. The test of the distributed database ends only when the number of underlying logic blocks whose call status flag is set to the first value meets the preset condition, that is, when the underlying logic blocks called during the test process have covered all the underlying logic blocks of the distributed database being tested. This improves the coverage of the test process and thus more accurately detects potential vulnerabilities in the distributed database.

[0057] Specifically, in one embodiment, reference is made to Figure 5 The pre-booking conditions may include at least one of the following: Condition 1: The number of underlying logic blocks whose call status flag is set to the first status value is equal to the total number of underlying logic blocks in the distributed database; Condition 2: The number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined number, which is less than the total number of underlying logic blocks in the distributed database. Condition 3: The ratio of the number of underlying logic blocks whose call status flag is set to the first status value to the total number of underlying logic blocks in the distributed database reaches a predetermined ratio. In condition 1, when the number of underlying logic blocks whose call status flag is set to the first state value is equal to the total number of underlying logic blocks in the distributed database, it indicates that all underlying logic blocks of the distributed database have been called during the execution of previous test cases. Based on the execution results of the test cases, it can be relatively comprehensively determined whether these underlying logic blocks will encounter errors when called to execute database operation statements. At this point, it can be considered that a relatively comprehensive test of the distributed database has been performed, and subsequent testing of the distributed database can be terminated. Therefore, in this embodiment, the number of underlying logic blocks whose call status flag is set to the first state value being equal to the total number of underlying logic blocks in the distributed database can be used as a predetermined condition to ensure that a sufficiently comprehensive test of the distributed database can be performed.

[0058] In condition 2, it is understandable that as the number of executed test cases increases, the number of underlying logic blocks that have been called will also gradually increase. When the number of called underlying logic blocks reaches a certain number, the number of remaining uncalled underlying logic blocks becomes relatively small. Since the test system cannot easily analyze under what configuration states the remaining uncalled underlying logic blocks will be called by the test cases, it may be necessary to modify the configuration file multiple times and conduct tests before the remaining uncalled underlying logic blocks can be called. In other words, towards the end of the testing process, it may take a long time to test the remaining uncalled underlying logic blocks, resulting in high time cost and low efficiency in testing the last few underlying logic blocks. Therefore, in this embodiment, a value less than the total number of underlying logic blocks can be used as a predetermined number, and the total number of called underlying logic blocks not less than the predetermined number can be used as a predetermined condition.

[0059] Specifically, the predetermined number can be obtained by subtracting a preset value from the total number of underlying logical blocks in the distributed database. For example, the predetermined number can be obtained by subtracting 100 from the total number of underlying logical blocks in the distributed database. When the number of uncalled underlying logical blocks is no more than 100, the predetermined condition can be considered met, and the testing process of the distributed database by the test system can be terminated.

[0060] In condition 3, referring to the description related to condition 2, if the number of underlying logic blocks determined to be set to the first state value is equal to the total number of underlying logic blocks in the distributed database is used as a predetermined condition, the efficiency of testing the remaining uncalled underlying logic blocks in the later stages of testing is low. Therefore, in one possible implementation, the predetermined condition can be determined according to the ratio between the called underlying logic blocks and the total number of underlying logic blocks. Specifically, the quotient between the first count and the total number of underlying logic blocks in the distributed database can be calculated, and the quotient can be compared with a predetermined ratio. When the quotient is greater than the predetermined ratio, the predetermined condition can be considered satisfied, and the testing process of the distributed database can be terminated.

[0061] Furthermore, in one embodiment, when most of the underlying logic blocks have already been invoked during the execution of previous test cases, compared to randomly modifying configuration files and obtaining test cases, for the remaining few uninvoked underlying logic blocks, specialized test cases are designed based on expert experience for testing. Based on this, when condition 2 or condition 3 is used as a predetermined condition, after the test of the distributed database is completed, the test of the distributed database can be completed more efficiently and comprehensively through this human-machine collaboration method.

[0062] Among the three specific conditions mentioned above, the quantitative relationship between the number of underlying logic blocks whose call status flag is set to the first state value and the total number of underlying logic blocks is used as the predetermined condition. This predetermined condition can be used to determine whether a sufficient number of underlying logic blocks from all the underlying logic blocks of the distributed database have been called during the execution of test cases. In other words, it can determine whether the executed test cases have covered enough underlying logic blocks, and whether the coverage of the distributed database test has reached the required level. When the number of underlying logic blocks called during the distributed database test fails to meet the predetermined condition—meaning the number of called underlying logic blocks is still relatively small and the distributed database test is not comprehensive enough—new test cases are obtained and executed until the predetermined condition is met, thereby ensuring the coverage of the distributed database test and more accurately detecting vulnerabilities in the distributed database.

[0063] In one embodiment, refer to Figure 6 Prior to step 301, the distributed data testing method also includes: Step 601: Divide the underlying logic source code of the distributed database into underlying logic blocks, generate call status mark change tasks for the underlying logic blocks, and associate the call status mark change tasks with the underlying logic blocks. Step 602: Compile the underlying logic block and the call status flag change task associated with the underlying logic block to obtain the compiled file, and deploy the compiled file to each database node so that each database node can parse the underlying logic block from the compiled file. At this point, in step 303, after the test case is executed, the call status flag of the underlying logic block called by the test case is set to the first status value, including: Step 603: After executing the test case by calling the underlying logic block, use the call status flag change task associated with the underlying logic block to set the call status flag of the underlying logic block to the first status value.

[0064] In step 601, the underlying logic source code is the source code used to create the distributed database. This source code contains all the code required to perform various operations on the distributed database. The call status flag statement is a statement used to determine the value of the call status flag corresponding to the underlying logic block. Specifically, it can be a statement used to assign a first status value to the variable corresponding to the call status flag of the underlying logic block. For example, if the variable name of the call status flag corresponding to a certain underlying logic block is a1, and the preset first status value is 1, then the corresponding call status flag change task is a1=1.

[0065] Specifically, after dividing the underlying source code of the distributed database into multiple underlying logic blocks, a corresponding call status flag change task can be generated for each underlying logic block. Then, the underlying logic blocks and their corresponding call status flag change tasks are associated. Thus, when a certain underlying logic block is called to execute a test case, the corresponding call status flag change task will also be executed, setting the call status flag of that underlying logic block to the first status value. In one possible implementation, the call status flag change task for each underlying logic block can be directly added to the code statements of that underlying logic block. For example, the call status flag change task can be added before the first line of code in the underlying logic block, or inserted between two lines of code contained in the underlying logic block. Thus, when the underlying logic block is called, the corresponding call status flag change task will be automatically executed when the code statements contained in the underlying logic block are executed. For example, the variable name of the call status flag corresponding to underlying logic block A is A_p, and the preset first status value is 1. The code of the underlying logic block is as follows: var p int p, err = strconv.Atoi(*port) terror.MustNil(err) cfg.Port = uint(p) At this point, the call status flag change task A_p=1 corresponding to the underlying logic block is generated and added to the first line of code of the underlying logic block, that is, before var p int, or added to a position between the statement var p int and cfg.Port = uint(p). In this way, when the underlying logic block A is called and the corresponding code is executed, the call status flag change task will also be executed, thereby setting the call status flag corresponding to the underlying logic block A to 1.

[0066] In step 602, the compiled file is an executable file, such as a CSV file, obtained by compiling the underlying logic source code of the distributed database. It is understood that a distributed database includes multiple database components for implementing different functions, and these different components are often deployed on different database nodes. Therefore, in this embodiment, the underlying logic source code can be modularly designed. During compilation, multiple underlying logic blocks required to implement the function of the same database component are compiled into a single compiled file, while underlying logic blocks required to implement different database components are compiled into different compiled files, resulting in multiple compiled files. These compiled files are then distributed to various database nodes, thereby deploying each component of the distributed database to its respective database node. For example, refer to... Figure 7 After adding a task to change the call status flag and compiling the underlying logic source code, compiled files A to C are generated, corresponding to components A, B and C respectively. Then, compiled file A is sent to database node 1 and database node 2, thereby deploying component A corresponding to compiled file A to these two database nodes, and so on.

[0067] In one possible implementation, the call status flag change task corresponding to each underlying logic block is directly added to that underlying logic block. When compiling the underlying logic source code composed of the underlying logic blocks, the corresponding call status flag change task and the underlying logic block are compiled together into the compiled file.

[0068] In step 603, since each underlying logic block is associated with a call status flag change task, when a certain underlying logic block is called during the execution of a test case, the call status flag change task associated with that underlying logic block can be executed to set the call status flag corresponding to the underlying logic block to the first status value. Then, refer to... Figure 7 After each test case is executed, each database node organizes the call status tags of its local underlying logic blocks into a corresponding call status tag table, and then sends it to the call status tag collector 140 for aggregation.

[0069] In the embodiments disclosed in steps 601 to 603, the underlying logic source code of the distributed database is divided into multiple underlying logic blocks. A call status flag change task is generated for each underlying logic block, and each underlying logic block and its corresponding call status flag statement are associated. This ensures that when each underlying logic block is called, the corresponding call status flag statement is also executed. Then, each underlying logic block and each call status flag change task are compiled into a directly executable compiled file and distributed to each database node. This deploys each component of the distributed database to different database nodes. In this way, when test cases are executed subsequently, the call status flag corresponding to the called underlying logic block can be accurately set to the first status value and the first count can be updated. This controls the subsequent testing process and ensures that the distributed database can be tested more comprehensively.

[0070] In one embodiment, refer to Figure 8 During the execution of test cases, the initial value of the call status flag corresponding to each underlying logic block is the second status value. After step 303, the method further includes: Step 801: If the call status flag of the underlying logic block changes from the second status value to the first status value, increment the first count by 1. The first count is used to indicate the number of underlying logic blocks that have been called. In step 801, the second state value is a preset value that is different from the first state value. In one embodiment, the first state value can be 1 and the second state value can be 0. In this way, the value of each call status flag only needs to be represented by one bit, thereby reducing the storage space required to store the call status flags corresponding to each underlying logic block and saving storage resources.

[0071] Understandably, once the call status flag corresponding to each underlying logic block is set to the first state value, it will maintain that value until the end of the distributed database test. In other words, during the entire test, each call status flag will only change from the second state value to the first state value the first time it is invoked. Based on this, the first count can represent the number of underlying logic blocks invoked during the execution of all previously executed test cases. The first count can be used to reflect the coverage when testing the distributed database, more accurately detecting vulnerabilities in the distributed database.

[0072] Specifically, when a test case is executed, after a certain underlying logic block is called, the corresponding call status flag is set to the first status value. By checking whether there are any newly added underlying logic blocks whose call status flags are set to the first status value when a test case is executed, the first count is incremented by 1 when a call status flag is detected to be set to the first status value.

[0073] In one embodiment, referring to the detailed description of step 303, the call status flags of all underlying logic blocks in each database node can be obtained by calling the status flag collector 140 after each execution of a test case, and the call status flag summary table in the call status flag collector 140 can be updated accordingly. Because in the call status flag summary table, when a call status flag is set to the first status value, the first status value will remain unchanged in the subsequent test process until the test process ends, the number of call status flags set to the first status value in the call status flag summary table in the call status flag collector 140 can be determined as the first count.

[0074] In another possible implementation, the first state value is 1 and the second state value is 0. In this case, the values ​​of all calling state flags can be summed to determine the first count.

[0075] Reference Figure 8 In step 304, determining that the number of underlying logic blocks set to the first state value meets a predetermined condition includes: Step 802: If the first count reaches a predetermined condition, determine that the number of underlying logic blocks whose call status flag is set to the first status value has reached a predetermined condition.

[0076] In step 802, the first count reflects the total number of underlying logic blocks invoked in the executed test cases. Based on this, the magnitude of the first count can be used to determine whether a predetermined condition is met. Specifically, the first count can be compared with a set threshold to determine whether the predetermined condition is met. The set threshold can be determined based on the total number of underlying logic blocks. For example, the threshold can be the total number of underlying logic blocks in the distributed database, the total number of underlying logic blocks minus a fixed value, or n% of the total number of underlying logic blocks. When the first count is not greater than the threshold, it can be considered that the test of the distributed database is not comprehensive enough and does not meet the predetermined condition, and the distributed database needs to continue testing. When the first count is greater than the threshold, it indicates that enough underlying logic blocks have been invoked during the test, and the distributed database has been tested relatively comprehensively, meeting the predetermined condition, and the test process can be terminated.

[0077] In the embodiments disclosed in steps 801 to 802, by incrementing the first count by 1 when each call status flag is set from the first state value to the second state value, the first count represents the number of underlying logic blocks that have been called during the test. Then, it is only necessary to compare the first count with a set threshold. If the first count is not greater than the set threshold, it is confirmed that the predetermined condition has not been met, and test cases are obtained and executed to test the distributed database until the first count is greater than the set threshold. This ensures that enough underlying logic blocks in the distributed database can be called during the test, thereby improving the coverage when testing the distributed database and more accurately testing the vulnerabilities in the distributed database.

[0078] The above provides an overall description of steps 310 to 340. Since steps 310 and 320 have already been described in detail above, the following will only describe the details of steps 330 and 340 and the method for generating test cases in this disclosure.

[0079] Detailed description of generating test cases In one embodiment, refer to Figure 9 Step 302 includes: Step 901: For each test case to be generated, determine the test case type and the corresponding test case template. The test case template is a database operation statement template determined based on the syntax of the distributed database. Step 902: For each test case to be generated, obtain the seed sequence to be mutated from the first seed pool, and perform mutation processing on the seed sequence to be mutated to obtain the mutated binary sequence corresponding to the test case to be generated, wherein the seed sequence to be mutated is a binary sequence. Step 903: Fill the mutated binary sequence corresponding to each test case to be generated into the test case template corresponding to the test case to be generated, and obtain the test case; Following step 303, the method further includes: Step 904: If the first count changes when the test case is executed, add the mutated binary sequence corresponding to the test case to the first seed pool.

[0080] In step 901, the test case type refers to the variety of test cases required to test different aspects of the performance of the distributed database. The test case type indicates the format and number of database operation statements included in the generated test cases. This test case type can be pre-defined based on the actual usage scenarios that the distributed database may face in real-world use. For example, in actual use of a distributed database, there may be scenarios where multiple users operate the database simultaneously. This requires the concurrent execution of multiple database operation statements. If the distributed database cannot handle these concurrent operations well, data consistency issues can easily arise. Therefore, it is necessary to test the concurrent performance of the distributed database. In this case, it is necessary to pre-define a test case type for testing the concurrent performance of the distributed database and construct corresponding test case templates. For example, this test case type should include multiple DDL and DML statements that need to be executed concurrently, and the corresponding test case template can be composed of multiple DDL and DML statement templates.

[0081] Test case templates are templates of database operation statements used to construct test cases. In essence, various database operation statements for distributed databases need to be written according to a specific statement format. These statements typically consist of operation instructions supported by the distributed database and populated variables. The format of these statements themselves is relatively fixed; the difference lies in the variables used to populate the statements. Based on this, database operation statement templates can be pre-constructed according to the statement format and operation instructions. For example, a SELECT statement is often written in the format SELECT column_name FROM table_name, where SELECT and FORM are fixed operation instructions, and column_name and table_name are fields used to populate table and column names. The corresponding test case template can be represented as "SELECT '___' FROM '____'".

[0082] It is understandable that different distributed databases support different syntaxes for their operations; that is, the syntax format of database operation statements that can be executed differs depending on the type of distributed database. Therefore, in this embodiment, the test case template can be constructed based on the syntax features supported by the distributed database itself. For example, TDSQL databases support querying the health of tables in the database. Therefore, when the distributed database to be tested is a TDSQL database, the constructed test case template should include a statement template for querying table health, i.e., `Show stats_healthy where table_name ='__'`.

[0083] Specifically, refer to Figure 1 The test case generator 130 can store test case templates corresponding to various test case types. After the controller 130 determines that test cases need to be generated based on parameters such as the first count, the second count, and the third count, it will issue corresponding instructions to the test case generator 130. The test controller 130 randomly selects one from a variety of preset candidate test case types as the test case type and determines the test case template corresponding to the test case type.

[0084] In step 902, the first seed pool is a collection for storing candidate seed sequences, which can be randomly generated binary sequences. Specifically, a seed sequence to be mutated for generating test cases can be randomly selected from the candidate seed sequences in the first seed pool. Referring to step 901 above, since some test cases are used to test the concurrency capabilities of the distributed database, a single test case needs to contain multiple DDL and DML statements. Accordingly, multiple seed sequences to be mutated need to be obtained from the first seed pool to generate multiple DDL and DML statements. That is, in this embodiment, the number of seed sequences to be mutated obtained from the first seed pool can be one or more. Specifically, the number of seed sequences to be mutated needs to be obtained can be determined according to the type of test case.

[0085] Understandably, if test cases are generated by directly filling the obtained seed sequences to be mutated into the test case template, the limited number of seed sequences in the first seed pool will only generate a limited number of non-repeating test cases. This results in low test case diversity, significantly reducing test coverage and making it difficult to accurately detect vulnerabilities in the distributed database. Furthermore, in actual use of a distributed database, the data written by users is unpredictable. If test cases are generated by directly filling the pre-defined seed sequences to be mutated into the test case template, the generated test cases will all operate on the pre-defined seed sequences. In other words, the data operated on by these test cases (i.e., the seed sequences to be mutated) is known, making it impossible to test whether the distributed database will err when processing unknown data. This further reduces test coverage and makes it difficult to accurately detect vulnerabilities in the distributed database.

[0086] Based on this, in this embodiment, each time a test case is generated, the obtained seed sequence to be mutated is mutated to obtain a mutated binary sequence. This mutated binary sequence is then filled into the test case template. This increases the diversity of data filled into the test case template and better simulates the process of operating on random user-input data when using a distributed database. This allows for a more comprehensive test of whether the distributed database will malfunction when processing various types of data. Specifically, refer to... Figure 10 A seed sequence to be mutated can be selected from the first seed pool using a seed selector, and then mutated using a sequence mutant. Specifically, the mutation process can involve randomly inverting a bit or byte in the seed sequence, inserting a new bit or byte into the seed sequence, or deleting a bit or byte from the seed sequence. For example, a seed sequence to be mutated is 0100110101111010, which contains 16 bits, or two bytes. During the mutation process, inverting the fifth bit of the seed sequence results in a mutated binary sequence of 0100110101101010. Alternatively, inserting a bit between the 8th and 9th bits of the seed sequence also results in a mutated binary sequence of 01001101101111010.

[0087] In step 903, since the database operation statement template that constitutes the test case template has reserved fields for filling various variables, after obtaining the mutated binary sequence, the mutated binary sequence is filled into the reserved fields in the database operation statement template corresponding to the test case type, so as to obtain the corresponding database operation statement and form the test case corresponding to the test case type.

[0088] like Figure 11 As shown, Figure 11This example illustrates test cases generated using the method described in this embodiment when test case templates are set according to the syntax format of the TDSQL database and the syntax format of the OceanBase database, respectively. The test case generated under the TDSQL database syntax format creates a table named t_io10 in the TDSQL database, defining multiple columns named c_d, cx7k7y, c_w2tec, c_a6hzr5zls, and c_vnxw6. These table and column names are obtained by mutating the seed sequence to be mutated. The test case also defines a composite primary key containing the c_d and cx7k7y columns, which is a clustered index. Furthermore, the test case template includes several statements for executing TDSQL database-specific syntax, such as the statement PRE_SPLIT_REGIONS = 5 for pre-segmenting the table; and the statement ALTER TABLE t_io10 SET TDSTORE REPLICA for setting the number of Tdstore replicas for the created table t_io10. 1. Based on this, this embodiment generates test cases by pre-setting a test case template and then randomly generating a mutated binary sequence and filling it into the test case template. This allows for flexible adjustment of the test case template according to the syntax characteristics of the distributed database, thereby enabling more comprehensive testing of the distributed database. In step 904, refer to Figure 10 If the first count changes after executing a test case, it indicates that during the execution of the test case generated based on the mutated binary sequence, an unused underlying logic block was invoked. Subsequent mutations based on this mutated binary sequence to generate test cases have a higher probability of invoking this unused underlying logic block, improving test coverage and more accurately detecting vulnerabilities in the distributed database. Therefore, in this embodiment, if the first count changes after executing a test case, the mutated binary sequence used to generate that test case should be added to the first seed pool as a seed sequence to be mutated in subsequent test case generation.

[0089] Specifically, the generated test cases are executed sequentially. After each test case is executed, the call status flag corresponding to each underlying logic block is obtained, and the first count is updated accordingly. When the first count changes after executing a test case, the mutated binary sequence corresponding to that test case is added to the first seed pool. This increases the diversity of seed sequences to be mutated, thus increasing the diversity of subsequently generated test cases, while also avoiding invalid candidate seed sequences in the seed pool, thereby improving testing efficiency.

[0090] In the embodiments disclosed in steps 901 to 904, multiple test case types are preset, and corresponding test case templates are set for each test case type according to the syntax characteristics of the distributed database. When test cases need to be generated, the corresponding test case template is determined by the test case type. Then, the seed sequence to be mutated in the given first seed pool is mutated, and the mutation result is filled into the test case template to form a test case. In this way, test cases that conform to the syntax characteristics of the distributed database can be automatically generated, while improving the diversity of the generated test cases, thereby enabling more comprehensive testing of the distributed database. In addition, in this embodiment, if the first count changes during the execution of test cases, it indicates that the underlying logic block called when executing the test case generated based on the mutated seed sequence is different from the underlying logic block called when executing the test case generated based on the existing sequence in the first seed pool. At this time, the mutated seed sequence is added to the first seed pool as the seed sequence to be mutated when generating subsequent test cases. In this way, more diverse test cases can be generated that can test different underlying logic blocks separately, improving the diversity of the generated test cases and enabling more comprehensive testing of the distributed database.

[0091] In one embodiment, refer to Figure 12 The first seed pool stores multiple candidate seed sequences, each with a first weight coefficient. Step 901 includes: Step 1201: In the first seed pool, the candidate seed sequences are sorted from largest to smallest according to the first weight coefficient, and the seed sequence to be mutated is determined from the candidate seed sequences based on the sorting result.

[0092] In step 1201, the candidate seed sequence is a binary sequence that can be used as a seed sequence to be mutated. The candidate seed sequence can be generated in advance and added to the first seed pool, or it can be added to the first seed pool based on certain rules during the testing of the distributed database. For example, as described in step 904, if the first count changes when executing a test case, the mutated binary sequence corresponding to the test case that changes the first count will be added to the first seed pool as a new candidate seed sequence.

[0093] It is understandable that the initial value of the first weight coefficient corresponding to each candidate seed sequence is equal, and the first weight coefficient corresponding to each candidate seed sequence will be updated in real time according to the number of times each candidate seed sequence is determined as a seed sequence to be mutated and mutated.

[0094] Specifically, the candidate seed sequences can be sorted in descending order according to the magnitude of their corresponding first weight coefficients. Then, the required number of candidate seed sequences are selected as the mutation seed sequences based on the sorting result. It is understandable that when multiple candidate seed sequences have the same first weight coefficient, the sorting among these sequences can be random. In one implementation, the more bits a candidate seed sequence contains, the more mutation methods there are, and the lower the probability of duplicate mutation results. Based on this, candidate seed sequences with equal first weight coefficients can also be sorted in descending order of the number of bits they contain.

[0095] After determining the seed sequence to be mutated, refer to Figure 12 The methods also include: Step 1202: Reduce the first weight coefficient corresponding to the seed sequence to be mutated.

[0096] In step 1202, it is understood that in order to improve test coverage during the testing process, the diversity of test cases should be increased. With the number of test cases remaining unchanged, the number of duplicate test cases should be reduced to ensure the diversity of test cases. For each candidate seed sequence, the more times it is used as a seed sequence to be mutated and generate test cases, the higher the probability that the test cases generated by mutating the candidate seed sequence will be duplicated with the test cases that have been executed before. For example, candidate seed sequence A has been used for 100 mutations, while candidate seed sequence B has only been used for 10 mutations. If candidate seed sequence A is used as the seed sequence to be mutated, there are 100 mutation methods that will result in the generated test cases being the same as previously executed test cases. However, if candidate seed sequence B is chosen as the seed sequence to be mutated, only 10 mutation methods will result in the generated test cases being the same as previously executed test cases. Therefore, choosing candidate seed sequence B as the seed sequence to be mutated better ensures that the generated test cases are not the same as previously executed test cases, increasing the diversity of generated test cases. This improves the coverage when testing distributed databases and more accurately detects vulnerabilities in distributed databases.

[0097] Based on this, in this embodiment, after each mutation of the seed sequence to be mutated, the first weight coefficient corresponding to the seed sequence to be mutated is reduced. In this way, the first weight coefficient corresponding to each candidate seed sequence in the first seed pool is negatively correlated with the number of times it has been used for mutation. When generating test cases each time, the candidate seed sequences in the first seed pool that have been used for mutation less often are preferentially identified as seed sequences to be mutated, thereby reducing the probability that the mutated binary sequence obtained after mutation will repeat the previous mutation result and improving the diversity of the generated test cases.

[0098] Specifically, the first weight coefficient of the seed sequence to be mutated can be reduced by subtracting a given value from the first weight coefficient corresponding to the seed sequence to be mutated, multiplying the first weight coefficient corresponding to the seed sequence to be mutated by a coefficient less than 1, or pre-setting a decreasing function relationship between the number of times it is used for mutation and the size of the first weight coefficient.

[0099] In the embodiments disclosed in steps 1201 and 1202, the seed sequences to be mutated are determined from the candidate seed sequences based on the first weight coefficients corresponding to each candidate seed sequence in descending order. Simultaneously, after mutating the seed sequences to be mutated, the first weight coefficient corresponding to the seed sequences to be mutated is reduced, thereby making the first weight coefficient of each seed sequence negatively correlated with the number of times it has been used for mutation. Thus, candidate seed sequences with fewer mutations are more likely to be used for subsequent mutation and test case generation. This reduces the probability of generated test cases overlapping with already executed test cases, increases the diversity of generated test cases, and thus improves test coverage, more accurately detecting vulnerabilities in the distributed database.

[0100] Detailed description of executing test cases in step 303 In one embodiment, refer to Figure 13 Step 303 includes: Step 1301: When the test case is a database query statement, create a single-node database based on the data storage status of the distributed database; Step 1302: Execute the test cases corresponding to the test case types in the distributed database and the single-node database respectively, and record the first execution result of the test cases executed in the distributed database and the second execution result of the test cases executed in the single-node database. Step 1303: Determine the test result based on the comparison between the first execution result and the second execution result.

[0101] In step 1301, a database query statement refers to a statement used to query data stored in a distributed database. Specifically, in a relational database, a database query statement can be a DQL statement. The number of database query statements included in a test case can be one or more. It should be noted that the test cases in this embodiment only include DQL statements, and do not include DML or DDL statements. The testing process using DML and DDL statements as test cases will be described in another embodiment.

[0102] Single-node databases and distributed databases are the same type of database. For example, both single-node and distributed databases are TDSQL databases, and the configuration state of the single-node database is determined based on the current configuration file of the distributed database. This ensures that single-node and distributed databases support the same syntax and are in the same current configuration state. Both can execute the database queries contained in the test cases, and after correctly executing the database queries in the test cases, they can return the same execution results. The only difference between single-node and distributed databases is that distributed databases deploy each database component across different database nodes and store data across multiple nodes, while single-node databases deploy all database components on a single node and use only that single node to store data.

[0103] Specifically, refer to Figure 14 Before executing test cases, first check the type of test case, i.e., check the type of statements contained in the test case. When it is detected that the test case consists of database query statements, that is, the test case only contains DQL statements, you can first create a single-node database with the same database type as the distributed database. Then, export all the data and database objects stored in the distributed database, and then import the exported content into the single-node database. In this way, you can obtain a single-node database with the same data storage state as the distributed database. For example, if the distributed database is a TDSQL database, first create a single-node TDSQL database as the single-node database, and use the Dumpling command or Backup & Restore command to export all the data stored in the distributed database, as well as database objects such as tables, views, and indexes, into a file. Then, you can use the MyLoader command or lighting command to import the data exported from the distributed database into the single-node database.

[0104] In step 1302, the first execution result and the second execution result are the execution results output by the database after executing the test cases in the distributed database and the single-node database, respectively.

[0105] As we can understand, database query statements are used to retrieve data stored in a database. After executing a database query statement, the corresponding query results will be output. For example, a database query statement is SELECT column1 FROM table1. This statement means to find all data in the column named column1 in the table named table1. After correctly executing this statement, all data in the column1 will be output as the result of the statement.

[0106] In this embodiment, test cases containing database query statements are executed in both a distributed database and a single-node database, and the first execution result and the second execution result are obtained after executing the test cases in the distributed database and the single-node database, respectively. The results are then used to determine whether the distributed database encountered an error during the execution of the test cases.

[0107] In step 1303, the comparison result is used to characterize the consistency between the first execution result and the second execution result, while the test result is a parameter used to characterize whether an error occurred when executing test cases in the distributed database.

[0108] It's understandable that single-node databases are built upon the data storage state of distributed databases. Single-node databases and distributed databases share the same data storage state; that is, they store identical data in the same format as the tables, indexes, and views in the distributed database. For example, in a distributed database, there's a table named `table_A` with a column named `column_A` containing two data entries: `data_1` and `data_2`. Similarly, in a single-node database, there's also a table named `table_A` with the same `column_A` column containing `data_1` and `data_2`. Because all data in a single-node database resides on a single node, the execution of test cases doesn't involve cross-node operations. Therefore, the probability of errors when executing database queries within test cases is low. Thus, the second execution result obtained in a single-node database can be considered the standard result for correctly executing the test cases. If the database queries in the test cases are executed correctly in a distributed database, then the corresponding first and second execution results should be identical. Therefore, in this embodiment, by comparing the first execution result and the second execution result, if the first execution result and the second execution result are exactly the same, it means that the database query statement contained in the test case was correctly executed in the distributed database, thus determining that the test result is error-free; conversely, if the first execution result and the second execution result are different, it indicates that an error occurred during the execution of the test case in the distributed database. In this case, a corresponding error report is generated based on the inconsistency between the first execution result and the second execution result, and this error report is the corresponding test result. This test result can then be output so that testers can optimize the underlying logic source code based on the test result.

[0109] In the embodiments disclosed in steps 1301 to 1303, when the test case only contains database query statements, a single-node database with the same data storage state as the distributed database is created, and the test case is executed in the distributed database and the single-node database respectively, and a first execution result and a second execution result are obtained respectively. By comparing whether the first execution result and the second execution result are consistent, it can be accurately determined whether there is an error when executing the database query statement in the distributed database, and the corresponding test result is determined, so that relevant technicians can optimize the underlying logic source code of the distributed database based on the test results.

[0110] In one embodiment, the concurrent performance of the distributed database needs to be tested during the testing process. In this case, refer to... Figure 15 Step 303 includes: Step 1501: When the test cases include multiple database modification test statements, generate a state snapshot based on the data storage state of the distributed database. Step 1502: Execute multiple database modification test statements concurrently in the distributed database to obtain the third execution result; Step 1503: Perform a full permutation of multiple database modification test statements to obtain a sorted list of multiple test statements; Step 1504: Sequentially sort each test statement to determine the order to be executed, and execute the first test process based on the order to be executed. The first test process includes: rolling back the distributed database based on the state snapshot, and executing multiple database modification test statements sequentially according to the order to be executed in the rolled-back distributed database to obtain the fourth execution result corresponding to the order to be executed. The fourth execution result is used to characterize the data storage state of the distributed database after executing multiple database modification test statements sequentially according to the order to be executed. If the fourth execution result is different from the third execution result, the next test statement sort is determined as the new order to be executed, and the first test process is executed based on the order to be executed until the fourth execution result corresponding to the order to be executed is consistent with the third execution result or the order to be executed is the order of the last test statement, and the test result is obtained.

[0111] In step 1501, a database modification test statement refers to a statement that, upon execution, causes a change in the data storage state of the distributed database. Specifically, the database modification test statement can be a DDL statement or a DML statement. Unlike the database modification statement in subsequent step 1701, the database modification test statement is part of the test case, and after execution, the second counter is not updated according to the number of executed database modification test statements. The state snapshot is a snapshot of the distributed database's data storage state before the execution of the test case. It is understood that when a test case contains multiple database modification test statements, the data storage state of the distributed database will change after execution. In the testing process of this embodiment, the test results are generated by comparing the results of concurrently executing multiple database modification test statements in the test case with the results of serially executing multiple database modification test statements in the test case. This requires executing multiple database modification test statements in the test case serially and concurrently under the same data storage state. Therefore, in this embodiment, a state snapshot needs to be generated based on the data storage state of the distributed database before executing the test cases. This allows the distributed database data storage state to be rolled back after multiple database modification test statements in the test cases are executed concurrently, and then the multiple database modification test statements in the test cases can be executed serially.

[0112] Specifically, refer to Figure 14 After obtaining the test cases, it checks whether the test cases contain multiple DDL and DML statements. If so, it creates a state snapshot according to the data backup method supported by the distributed database. For example, in a relational database, a corresponding state snapshot can be created using the Transact-SQL command in SQL Server before executing the test cases, thereby saving the data storage state of the distributed database before the execution of the test cases.

[0113] In step 1502, the third execution result is a result characterizing the data storage state of the distributed database after concurrently executing multiple database modification test statements. Specifically, multiple database modification test statements included in the test cases can be sent to the distributed database simultaneously, so that the distributed database executes these database modification test statements concurrently. After all database modification test statements have been executed, the data storage state of the database is recorded as the third execution result.

[0114] In step 1503, since the test cases in this embodiment contain multiple database modification test statements, the result of concurrently executing these database modification test statements will be consistent with the result of executing them sequentially in a certain order. Therefore, in this embodiment, the multiple database modification test statements contained in the test cases are fully permuted to obtain multiple test statement sorts. These test statement sorts indicate various execution orders when executing all database modification test statements in the test cases sequentially. Subsequently, the database modification test statements in the test cases are executed sequentially in the distributed database according to their respective sorts, thereby determining whether an error occurs when concurrently executing all database modification test statements in the test cases in the distributed database.

[0115] In one possible implementation, refer to Figure 14 Furthermore, multiple statements within a test case can be executed concurrently multiple times in the distributed database, and the third execution result obtained after each concurrent execution of the test case can be saved to construct a third execution result set. It should be noted that because each concurrent execution of multiple statements in a test case will change the data storage state of the distributed database, it is necessary to roll back the distributed database based on a state snapshot before starting the concurrent execution of the statements contained in the test case.

[0116] In step 1504, each test statement is sequentially designated as the execution order. After each execution order is determined, the data storage state of the distributed database is rolled back to the state before the concurrent execution of the test cases, based on a state snapshot. Then, multiple database modification test statements in the test cases are executed sequentially according to the order indicated by the execution order. After all database modification test statements in the test cases have been executed serially, the fourth execution result is obtained. This fourth execution result is then compared with the third execution result. If the fourth and third execution results are consistent, it indicates that the result of concurrent execution is the same as the result of executing multiple database modification test statements in the test cases serially according to the test statement order, and no errors occurred during concurrent execution, thus obtaining the test result. However, if the fourth and third execution results are inconsistent, the third execution result may be consistent with the result of executing other test statements serially. Therefore, the next test statement order is designated as the execution order, a new state snapshot is taken to roll back the data storage state of the distributed database, and all database modification test statements in the test cases are executed serially based on the new execution order, resulting in the fourth execution result. This process is repeated until the fourth execution result corresponding to a certain test statement sorting matches the third execution result, indicating that no errors occurred during concurrent execution. However, if the fourth execution result still does not match the third execution result after all test statement sortings have been processed and the first test procedure has been executed, it indicates that the result of concurrently executing multiple statements in the test case is different from the result of executing multiple statements in the test case sequentially in any order. This suggests that the result of concurrently executing multiple statements in the test case is incorrect, and at least some database modification test statements in the test case were not executed correctly. In this case, a corresponding error report is generated as the test result. Afterwards, this test result is output so that testers can optimize the underlying logic source code based on the test results.

[0117] In one possible implementation, test cases may include not only multiple database modification test statements but also several DQL statements. In this case, since DQL statements do not change the data storage state of the distributed database after execution, simply comparing the data storage state after concurrent execution of all statements in the test cases with the data storage state after serial execution of all statements in the test cases is insufficient to determine whether the DQL statements were executed correctly. However, after execution, the DQL statements output the corresponding query results. Therefore, when a test case contains multiple database modification test statements and several DQL statements, the corresponding third and fourth execution results should include the data storage state of the distributed database after executing the test cases and the query results output during the execution of the test cases.

[0118] In one possible implementation, if multiple database modification test statements in the test case are executed concurrently multiple times in step 1503, and the third execution result of each concurrent execution is constructed into a third result set, then in step 1504, after executing the first test process based on the order of each test statement and obtaining the fourth execution result corresponding to the order of each test statement, the obtained fourth execution result can be compared with all the third execution results in the third execution result set. Then, referring to... Figure 14 If a third execution result is identical to the fourth execution result, then that third execution result is removed from the third execution result set, until the third execution result set becomes empty or all test statement sorting has been treated as test sorting and the first test process has been executed. At this point, refer to... Figure 14 If all third execution results in the third execution result set are removed, meaning the third execution result set becomes empty, it indicates that the results of concurrently executing multiple statements in the test case in the distributed database are consistent with the results of sequentially executing multiple statements in the test case according to a specific test statement order, and no errors occurred during concurrent execution. Conversely, if, after sorting all test statements and executing the first test process, there are still third execution results in the set that have not been removed, it indicates that during concurrent execution of multiple statements in the test case, a third execution result different from the results of sequentially executing multiple statements in the test case according to each test statement order occurred. This third execution result is incorrect, and an error occurred during the concurrent execution of multiple statements in the distributed database.

[0119] In steps 1501 to 1504, when a test case contains multiple database modification test statements, a state snapshot is created to save the data storage state before the test case is executed. Then, the multiple statements contained in the test case are executed concurrently in the distributed database to obtain the third execution result during concurrent execution. At the same time, the multiple statements contained in the test case are fully permuted to obtain various test statement sortings. Then, based on the state snapshot, the data storage state of the distributed database is rolled back to the state before the test case is executed. Then, the multiple statements in the test case are executed serially according to each test statement sorting. In this way, by comparing whether the third execution result and each fourth execution result are consistent, it can be determined whether the distributed database has encountered errors during concurrent execution, thus realizing the testing of the concurrent performance of the distributed database.

[0120] A detailed description of the modification process for changing the configuration file of the distributed database in step 304. In one embodiment, refer to Figure 16 In step 304, the configuration parameters of the distributed database are adjusted, including: Step 1601: If the first count remains unchanged during the execution of a predetermined number of consecutive test cases in multiple test cases, then adjust the configuration parameters of the distributed database to update the current configuration state.

[0121] In step 1601, it is understood that modifying the distributed database configuration file allows the distributed database to run in a new current configuration state. This enables better access to previously unused underlying logic blocks during test case execution, improving test coverage and more accurately identifying vulnerabilities. However, modifying the configuration file before fully utilizing all available underlying logic blocks in the current configuration state can lead to insufficient testing of the distributed database. Furthermore, after modifying the configuration file, some previously inaccessible underlying logic blocks may become unusable, resulting in a decrease in the comprehensiveness of distributed database testing. For example, the distributed database is a TDSQL database. One configuration item is used to configure whether the Tdstore feature is enabled. Before modifying the configuration file, the Tdstore feature is enabled. If the configuration file is modified before all the underlying logic blocks used to implement the Tdstore feature are called and all logical branches related to Tdstore are executed, and the Tdstore feature is disabled during the modification, then when test cases are executed in the distributed database after the configuration file is modified, these underlying logic blocks that support the Tdstore feature can no longer be called, resulting in a decrease in the test coverage of the distributed database. Based on this, in this embodiment, after each test case execution, the first count is checked to see if it has changed, thereby determining whether any underlying logic blocks that were not called during the execution of previous test cases have been called. If the first count changes, it means that underlying logic blocks that were not called before were called during the execution of test cases. This indicates that in the current configuration state, some logical branches corresponding to the previously called new underlying logic blocks have not been executed, meaning that the testing of the distributed database in the current configuration state is still insufficient. At this point, instead of modifying the configuration file, we obtain more test cases to test the distributed database. If the first count does not change after a predetermined number of consecutively executed test cases, it indicates that the underlying logic blocks called in those test cases have all been called previously. This means that all the underlying logic blocks that can be called in the current configuration state have been invoked, and the logical branches relying on these blocks have generally been executed in previously run test cases. At this point, the distributed database in the current configuration state has been sufficiently tested, and the configuration file can be modified to update the current configuration state.

[0122] Specifically, refer to Figure 1The controller 150 can store a test case count, which represents the number of consecutively executed test cases that do not change the first count. Specifically, after each test case execution, the call status collector 140 retrieves each underlying logic block from each database node and updates the first count based on the retrieved call status flags. That is, when a test case is executed, if a previously uncalled underlying logic block is called, the first count is incremented by 1. If the first count does not change after executing a test case, it indicates that the underlying logic blocks called during the execution of that test case are all underlying logic blocks that have been called during the execution of previous test cases, and no previously uncalled underlying logic blocks are called. In this case, the test case count is incremented by 1. When a previously uncalled underlying logic block is called during the execution of a test case... If the test case count is not less than a predetermined number, it indicates that the underlying logic blocks called in the predetermined number of consecutively executed test cases have all been called during the execution of previous test cases. In other words, all the underlying logic blocks that can be called in the current configuration state have been called in the executed test cases, and the distributed database in the current configuration state has been sufficiently tested. Continuing to execute test cases in the current configuration state will likely result in the invocation of previously uncalled underlying logic blocks. At this point, the distributed database configuration file is modified to update the current configuration state, allowing testing of the distributed database under the new configuration state. Conversely, if consecutive execution of test cases does not occur in the current configuration state, the configuration file is not modified. Instead, more test cases are obtained and executed until the test case count is not less than the predetermined number, at which point the configuration file is modified.

[0123] In the embodiment disclosed in step 1601, the number of consecutively executed test cases that do not change the first count is detected during test case execution. When the first count changes during test case execution, it indicates that executing the test case in the current configuration state can still call previously uncalled underlying logic blocks. In this case, the configuration file is not modified, but test cases are continuously acquired and executed, thereby performing a more thorough test on the distributed database in the current configuration state. However, when the first count does not change during the execution of a predetermined number of consecutive test cases, it indicates that all callable underlying logic blocks in the current configuration state have been called, and it is difficult to call previously uncalled underlying logic blocks when executing test cases in the current configuration state. The distributed database in the current configuration state has been sufficiently tested. At this point, the configuration file is modified to update the current configuration state of the distributed database, and subsequent tests are performed. Based on this, this embodiment can ensure that the distributed database in the current configuration state is fully tested before modifying the configuration file and updating the current configuration state of the distributed database, improving the accuracy and coverage of the test, and more accurately detecting vulnerabilities in the distributed database.

[0124] In one embodiment, refer to Figure 17 In step S303, before executing multiple test cases in the distributed database under the current configuration state, the method further includes: Step 1701: Generate a first number of database modification statements and execute them in the distributed database so that the distributed database modifies the data storage state of the distributed database according to the database modification statements, wherein the first number is less than a first threshold. In step 1701, the first number is a preset value, the first threshold is a preset value greater than the first number, and the database modification statement refers to a statement that causes a change in the database state during execution. The data storage state of a distributed database refers to the state constituted by database objects such as tables, views, and indexes in the distributed database, as well as the data stored in the distributed database. When a database modification statement is executed, database objects are created or deleted in the distributed database, or data stored in the distributed database is added, deleted, or modified, thereby changing the data storage state of the distributed database. Specifically, these database modification statements can be DDL (Data Definition Language) statements used by users to create or maintain database objects such as tables, views, and indexes, as well as DML (Data Manipulation Language) statements used to add, delete, or modify data stored in the database. Understandably, in the initial testing phase, since the distributed database has just been deployed to each database node, no database objects have been created or data is stored in the distributed database. However, test cases may contain some query statements. Therefore, before executing the test cases, several database modification statements are generated and executed to create a certain number of tables, views, indexes, and other database objects in the distributed database, and to write a certain amount of data to the distributed database, thereby establishing the initial data storage state to facilitate the subsequent execution of test cases. Specifically, these database modification statements are themselves a type of database operation statement, as described above. Figure 1 These database modification statements can be generated by calling test cases (130), and then sent to the distributed database for execution.

[0125] Understandably, these database modification statements themselves also invoke some underlying logic blocks to perform corresponding operations on the distributed database, and these database modification statements can also serve as test cases. If an error occurs during the execution of these database modification statements, a corresponding error report can be generated as a test result and output. At the same time, when executing these database modification statements, some underlying logic blocks are also invoked, and the invocation status flag corresponding to these invoked underlying logic blocks can be set to the first status value.

[0126] Step 1702: Initialize the second counter to the first number; After executing the first number of generated database modification statements, the second count is set to the first count. Thus, the second count can be used to represent the number of database modification statements that have been obtained and executed. The testing process of the distributed database can then be controlled based on the second count.

[0127] When using a second counter to control the testing process of a distributed database, refer to Figure 17 Step 1601 includes: Step 1703: If, during the execution of a predetermined number of consecutive test cases in multiple test cases, the first count remains unchanged and the second count is less than the first threshold, then a database modification statement is added, sent to the distributed database for execution, and the second count is increased by increasing the number of database modification statements. Step 1704: If, during the execution of a predetermined number of consecutive test cases in multiple test cases, the first count remains unchanged and the second count is not less than the first threshold, then adjust the configuration parameters of the distributed database to update the current configuration state.

[0128] In step 1703, it is understood that before modifying the configuration file, the distributed database before modification needs to be thoroughly tested. The underlying logic blocks called during test case execution are affected not only by the configuration state but also by the data storage state of the distributed database. For example, different problems may occur under different storage loads. For instance, when executing DQL statements, if the storage node is under low load (i.e., storing less data), the distributed database can maintain good accuracy in executing statements. However, under high load on the storage node, the large amount of stored data may cause timeouts and errors when executing queries. Furthermore, referring to the relevant description in step 303, when executing the database operation statements contained in the test case, a corresponding syntax tree is generated for each database operation statement through the syntax parser. Then, multiple execution plans for implementing the database operation statement are generated based on the generated syntax tree. The optimal execution plan is then selected and executed. Different execution plans correspond to different code paths, and different code paths indicate that the underlying logic blocks called during the execution process will also be different. The data storage status of the database may cause the priority of these execution plans to change, which will change the underlying logic blocks called when executing the database operation statement, thereby calling some underlying logic blocks that have not been called before.

[0129] Therefore, in this embodiment, when the first count remains unchanged during the execution of a predetermined number of test cases, it is further checked whether the second count is not less than the first threshold. If the second count is less than the first threshold, it is considered that the testing of the distributed database in the current configuration state is still insufficient. In this case, the configuration file is not modified first. Instead, new database modification statements are obtained and executed in the distributed database to create more database objects, write more data, or delete some data, thereby changing the data storage state of the distributed database. Then, new test cases are obtained and executed to test the distributed database after the data storage state has been modified. This improves the coverage when testing the distributed database in a single configuration state and more accurately detects vulnerabilities in the distributed database.

[0130] In this embodiment, the second count is updated based on the number of database modification statements acquired and executed. By pre-setting the number of database modification statements added each time, the second count reflects the number of times the distributed database's data storage state is modified in a single configuration state. That is, it reflects how many different data storage states the distributed database has been tested for performance in a single configuration state. Specifically, the number of database modification statements added each time can be a first number. In this case, the ratio between the second count and the first number reflects the number of times the distributed database's data storage state is updated in a single configuration state. Furthermore, setting the first threshold to a multiple of the first number controls how many times the distributed database's data storage state needs to be changed and tested in a single configuration state. For example, if the first threshold is n times the first number, then in a single configuration state, the process of adding database modification statements to change the data storage state and then acquiring test cases for testing will loop n times, thereby testing the performance of the distributed database in n different data storage states under that configuration state. Based on this, the coverage of distributed database testing can be improved, and vulnerabilities in the distributed database can be detected more accurately.

[0131] Specifically, refer to Figure 1 The second counter can be stored in the controller 150. Whenever a database modification statement needs to be added, the controller 150 first determines the number of database modification statements to be generated and increments the number of database modification statements to be generated into the second counter. At the same time, the controller 150 sends a corresponding control command to the test case generator 130, so that the test case generator 130 generates the corresponding number of database modification statements and sends them to the distributed database.

[0132] It should be noted that test cases may also contain several DDL or DML statements. These DDL or DML statements will not be counted in the second count, to ensure that the second count can be used to determine the number of times the distributed database's data storage state is modified in a single configuration state during testing. Specifically, in cases such as Figure 1 In the distributed database testing system shown, the instructions for the test case generator 130 to generate test cases and database modification statements are issued by the controller 150, and the second count is also stored in the controller 150. At this time, when the controller 150 issues an instruction to the test case generator 130 to generate test cases, the second count is not modified.

[0133] In step 1704, if during the execution of a predetermined number of consecutive test cases in multiple test cases, the first count remains unchanged and the second count is not less than the first threshold, this indicates that the data storage state of the distributed database has been modified multiple times under the current configuration state, and the distributed database has been tested under various data storage states. In other words, the distributed database under the current configuration state has been fully tested. At this point, modifying the configuration file and updating the current configuration state of the distributed database ensures that the distributed database under each configuration state is sufficiently tested.

[0134] Understandably, the second count is a parameter used to determine whether the distributed database has been sufficiently tested in a single configuration state. After modifying the distributed database configuration file and updating the current configuration state, the second count needs to be initialized to 0. This allows the second count to be updated again in the updated configuration state based on the number of subsequently retrieved and executed database modification statements.

[0135] In the embodiments disclosed in steps 1701 to 1704, a second count is used to characterize the number of times the data storage state of the distributed database is changed using database modification statements in a single configuration state. The second count and the first count are combined to determine whether the distributed database in a single configuration state has been sufficiently tested. Only when both the first count and the second count meet the corresponding conditions is the configuration file modified to update the current configuration state of the distributed database. This ensures that when testing the distributed database, the distributed database in a single configuration state can also be sufficiently tested, improving test coverage and more accurately detecting vulnerabilities in the distributed database.

[0136] In one embodiment, the controller 150 also stores a third count, referencing Figure 18 Step 1704 includes: Step 1801: If the second count is not less than the first threshold and the third count is less than the second threshold, clear the distributed database, set the second count to 0, increment the third count by 1, update multiple test cases, and return to the steps of executing multiple test cases in the distributed database under the current configuration state. Step 1802: If the second count is not less than the first threshold and the third count is not less than the second threshold, modify the configuration file of the distributed database and set the second count and the third count to 0.

[0137] In step 1801, the third count represents the number of times the data stored in the distributed database is cleared under the current configuration state. The second count represents the number of database modification statements executed between two consecutive clears of the distributed database. The second threshold is the maximum number of times the data in the distributed database is cleared under a single configuration state. In this embodiment, clearing the distributed database means removing all data and all database objects stored in the distributed database.

[0138] Understandably, when testing distributed databases, it is desirable to test the performance of the distributed database under various data storage states in each configuration state. However, when the number of executed database modification statements is large, the data storage state of the distributed database becomes relatively complex. Generating and executing these statements alone is insufficient to significantly change the data storage state, hindering a more thorough test of the distributed database in the current configuration state. Therefore, in this embodiment, referring to... Figure 19 When the second count is detected to be greater than the first threshold, the third count is checked to see if it is less than the second threshold. If so, the distributed database is cleared, the third count is incremented by 1, the second count is reset to 0, and the database modification statement is obtained to establish a new data storage state for the distributed database. New test cases are then obtained to test the distributed database. This allows the distributed database to execute test cases in more different data storage states, thereby further improving the coverage when testing the distributed database in a single configuration state and more accurately testing for vulnerabilities in the distributed database.

[0139] In step 1802, when the third count increases to a value greater than the second threshold, it indicates that the number of times the data stored in the distributed database has been cleared has reached the set number. This means that under the current configuration state, sufficient testing has been conducted on the distributed database under various data storage conditions, and the distributed database under the current configuration state has been adequately tested. At this point, the configuration file is modified to update the current configuration state of the distributed database for subsequent testing. However, since the configuration file has been modified, the current configuration state has changed. Under the changed current configuration state, the number of times the data stored in the distributed database has been cleared and the number of database operation statements executed are both 0. Therefore, the second and third counts are set to 0.

[0140] In the embodiments disclosed in steps 1801 to 1802, a third count is set to characterize the number of times the distributed database is cleared in a single configuration state. When the second count is greater than the first threshold, but the third count is not greater than the second threshold, the configuration file is not modified first. Instead, the data stored in the distributed database is directly cleared, the second count is initialized to 0, the third count is incremented by 1, and then the database modification statement is retrieved and executed again, so that the distributed database is in a new data storage state. Test cases are executed in this data storage state until the third count increases to be greater than the second threshold. Thus, before modifying the configuration file, the distributed database in multiple different data storage states can be fully tested, thereby further improving the coverage when testing the distributed database in a single configuration state and more accurately testing the vulnerabilities in the distributed database.

[0141] A detailed description of how to modify the configuration file of the distributed database in step 304. In one embodiment, refer to Figure 20 Step 304 includes: Step 2001: Determine the seed configuration file from the configuration file seed pool; Step 2002: Determine the variant configuration items from the multiple configuration items in the seed configuration file. The variant configuration items are several configuration items among the multiple configuration items. Step 2003: Determine the parameter mutation method based on the configuration parameter type of the mutation configuration item, mutate the configuration parameters of the mutation configuration item based on the parameter mutation method, and update the configuration file of the distributed database based on the mutated configuration parameters.

[0142] Step 2001: The configuration file seed pool is a collection of multiple configuration files for a distributed database, or a collection of image files used to store multiple configuration files for a distributed database. The seed configuration file is one of the multiple configuration files in the configuration file seed pool. It's understandable that distributed databases often have multiple configuration files, each configured to configure different aspects of the distributed database's attributes. For example, some configuration files configure which database nodes the distributed database uses, the IP address of each database node, and the connectivity between database nodes, while other configuration files configure whether the distributed database uses certain component functionalities during operation, the data storage method of each storage node, the connection attributes of the database server, and the access permissions of each database node, etc.

[0143] Specifically, refer to Figure 21 A seed configuration file can be determined from the configuration file seed pool using a seed selector. The seed selector is configured with rules for selecting seed configuration files, such as random selection or selection according to a certain probability or weight.

[0144] In step 2002, it is understood that each configuration file contains multiple configuration items. When modifying a configuration file, only the configuration parameters of some of the configuration items can be modified, for example, only one configuration item in the seed mutation file can be modified. Specifically, several mutation configuration items can be randomly selected or determined according to preset rules from the multiple configuration items in the seed configuration file. This is not limited in this embodiment.

[0145] In step 2003, the configuration parameter type refers to the data type of the configuration parameter corresponding to the mutated configuration item, such as boolean value, string, number, list, etc.; the parameter mutation method is the mutation method used when mutating the configuration parameter of the mutated configuration item. It can be understood that the mutation method differs for different data types. For example, when the configuration parameter of the mutated configuration item is a boolean value, it can be mutated by logical negation; when the configuration parameter of the mutated configuration item is a number, it can be mutated by modifying the value. For example, refer to... Figure 21 The configuration parameters for the `index-limit` configuration item are numeric. Therefore, these parameters can be mutated using numerical values. Furthermore, some configuration items can only accept a limited number of specified parameters. For these items, specific parameter mutation methods need to be defined based on the acceptable parameters. For example, in... Figure 22In the configuration, the `engines` item under `[isolation-read]` can only accept one or more of the specific strings "tdstore", "tdsql", etc., as configuration parameters. Therefore, when modifying this configuration item, you can only either delete one or more of these strings or add one or more of these specific strings to the configuration parameters. For example, in... Figure 22 In this case, the mutation is achieved by deleting the "tdstore" parameter.

[0146] Based on this, in this embodiment, after determining the mutated configuration item, the data type corresponding to the configuration parameter of the mutated configuration item is detected, the parameter mutation method corresponding to the data type is determined according to the data type, and the configuration parameter of the mutated configuration item is mutated accordingly, thereby modifying the configuration parameter of the mutated configuration item and updating the current configuration state of the distributed database.

[0147] Specifically, refer to Figure 21 After determining the seed configuration file, it can be input into the configuration file mutant. The configuration file mutant is a module that integrates rules for selecting mutation configuration items from the seed configuration file, as well as rules for the parameter mutation methods corresponding to each configuration item. After the seed configuration file is mutated by the configuration file mutant, the mutated configuration file is obtained. The mutated configuration file is then used as the configuration file of the distributed database, thereby updating the current configuration state of the distributed database.

[0148] In the embodiments disclosed in steps 2001 to 2003, by adding the configuration file of the distributed database to a configuration file seed pool, when the configuration file needs to be modified, a single seed configuration file is first selected from the configuration file seed pool, and then several configuration items are determined from the seed configuration file as mutation configuration items and the corresponding parameter mutation method is determined, thereby modifying the configuration parameters of the mutation configuration items. In this way, each time the configuration file is mutated, only the configuration parameters of some configuration items in a configuration file are modified, and the modification step when modifying the configuration file each time is small, which is conducive to more comprehensive testing of the distributed database under different current configuration states.

[0149] In one embodiment, the configuration files for the distributed database include deployment configuration files and non-deployment configuration files. The deployment configuration files are used to add or delete database nodes and configure the topology of the database nodes. The other configuration files besides the deployment configuration files are non-deployment configuration files. (Refer to...) Figure 23 Before step 2001, the method further includes: Step 2301: Each time the configuration file is modified, the fourth count is incremented by 1, and the fourth count is set to 0 when the number of underlying logic blocks whose call status flag is set to the first status value changes. Step 2001 includes: Step 2302: When the fourth count is not greater than the third threshold, determine the number of mutations of each non-deployment configuration file in the configuration file seed pool, and determine the non-deployment configuration file with the fewest mutations as the seed configuration file, and increment the mutation count of the seed configuration file by 1. Step 2303: When the fourth count is greater than the third threshold, determine the number of mutations of each deployment configuration file, and determine the deployment configuration file with the fewest mutations as the seed configuration file, and set the fourth count to 0.

[0150] In step 2301, the fourth count is used to characterize the number of configuration states that failed to change the first count during the execution of test cases within a single topology. It is understood that if an unused underlying logic block is invoked during test case execution, it indicates that many logic branches within the current topology may not have been tested, and the distributed database under the current topology has not been sufficiently tested. Conversely, if multiple unused underlying logic blocks are not invoked even after several consecutive changes to the current configuration state and multiple test cases are executed in each current configuration state, it indicates that the distributed database under the current topology has been sufficiently tested.

[0151] In step 2302, the third threshold is a preset threshold. It is understood that the deployment configuration file is used to configure the topology of the entire distributed database. If the configuration items in the deployment configuration file are directly modified when modifying the configuration file, it is easy to lead to insufficient testing of the distributed database under a single topology. Based on this, in this embodiment, when the fourth count is not greater than the third threshold, that is, from the last call to an uncalled underlying logic block to the current time node, the number of times the configuration file has been modified is not greater than the third threshold, it can be considered that the testing of the distributed database under the current topology is still insufficient. At this time, a seed configuration file for modification is determined from the non-deployment configuration files, thereby updating the current configuration state of the distributed database and performing testing without changing the topology of the distributed database, until the fourth count is greater than the third threshold.

[0152] Distributed databases have multiple non-deployment configuration files. The fewer mutation counts a configuration file has, the fewer times its configuration items have been modified. Modifying configuration items in these low-mutation-count files is more likely to trigger unused underlying logic blocks during subsequent testing, making it easier to detect potential problems in the distributed database. Therefore, in this embodiment, when the fourth count is not greater than the third threshold, the non-deployment configuration file with the fewest mutation counts is determined as the seed configuration file.

[0153] In one embodiment, when there are multiple non-deployment configuration files with the fewest mutations, one can be randomly sampled from these non-deployment configuration files as the seed configuration file. Alternatively, the non-deployment configuration files can be categorized according to the attributes they configure and given priorities. Then, for non-deployment configuration files with the same mutation count, the one with the highest priority is determined as the seed configuration file. For example, non-deployment configuration files can be divided into server configuration files for configuring database server attributes and node configuration files for configuring storage node data storage attributes, with different priorities assigned to server and node configuration files. In this case, for server and node configuration files with the same mutation count, the seed configuration file is determined according to its priority. For example, the server configuration file may have a higher priority than the node configuration file. In this case, when the non-deployment configuration files with the fewest mutations include both server and node configuration files with the same mutation count, the server configuration file is preferentially determined as the seed configuration file.

[0154] In step 2303, referring to step 2301, during the test, if an unused underlying logic block is called, causing a change in the first count, the fourth count is reset to 0. If the fourth count increases to a value greater than the third threshold, it indicates that no unused underlying logic block was called when executing test cases under different configuration states of the current topology. At this point, updating the current configuration state by modifying the non-deployment configuration file is insufficient to call the unused underlying logic block, and it can be considered that a comprehensive test of the distributed database under the current topology has been performed. Based on this, when the fourth count exceeds the third threshold, the deployment configuration file is designated as the seed configuration file to mutate the configuration items in the deployment configuration file, modify the topology of the distributed database, and conduct subsequent tests. This ensures that the distributed database under various topologies is sufficiently tested during the testing process. After the deployment configuration file is designated as the seed configuration file and modified, the topology of the distributed database changes, at which point the fourth count can be set to 0. Specifically, there may be multiple deployment configuration files for a distributed database. Referring to step 2302, the deployment configuration file with the fewest mutations is determined as the seed configuration file to increase the probability of calling the underlying logic block that has not been called in subsequent testing processes, thereby increasing the test coverage and more accurately testing the vulnerabilities in the distributed database.

[0155] For example, Figure 24 An example of mutating a deployment configuration file is shown. Figure 24 In this example, the topology of the distributed database is changed by deleting a node with IP address -host:10.0.1.3 from the tdstore servers configuration file, changing the IP address of a node in tdstoreservers from 10.0.1.2 to 10.0.2.2, and deleting tdsqlflash servers.

[0156] In the embodiments disclosed in steps 2301 to 2303, a fourth count is used to characterize the number of current configuration states under a single topology where the first count fails to change during the execution of test cases. When the fourth count is not greater than the third threshold, it can be considered that the distributed database under the current topology has not been sufficiently tested. Therefore, a seed configuration file is determined from the non-deployment configuration files to perform more thorough testing on the distributed database under the current topology. When the fourth count keeps increasing to greater than the third threshold, it is considered that the distributed database under the current topology has been sufficiently tested. At this point, the deployment configuration file is determined as the seed configuration file, and the topology of the distributed database is modified to ensure that relatively comprehensive testing can be performed on various topologies of the distributed database during the testing process. Furthermore, when a seed configuration file is needed, the configuration file with the fewest mutations of the corresponding type is determined as the seed configuration file, thereby increasing the probability of calling previously uncalled underlying logic blocks in subsequent testing processes, thus improving test coverage and more accurately testing vulnerabilities in the distributed database.

[0157] In one embodiment, refer to Figure 25 Step 2002 includes: Step 2501: Based on the second weight coefficient corresponding to each configuration item, determine the mutation probability of each configuration item, and based on the mutation probability of each configuration item, determine the mutated configuration item from multiple configuration items in the seed configuration file. Following step 2003, the method further includes: Step 2502: Determine the current configuration state obtained after mutating the mutated configuration item as the first configuration state corresponding to the mutated configuration item; Step 2503: If the number of underlying logic blocks whose status flags are set to the first status value remains unchanged during the execution of test cases in the first configuration state, reduce the second weight coefficient corresponding to the mutation configuration item. Step 2504: If, during the execution of test cases in the first configuration state, the number of underlying logic blocks whose status flags are set to the first status value changes, the second weight coefficient corresponding to the mutation configuration item is increased.

[0158] In step 2501, each configuration item in the seed configuration file is set with a second weight coefficient. The initial value of the second weight coefficient can be preset, and the initial value of the second weight coefficient corresponding to each configuration item can be equal.

[0159] In one possible implementation, the initial value of the second weight coefficient can be set according to the data type of the configuration parameter corresponding to the configuration item. It can be understood that the data type of the configuration parameter determines the number of non-repeating configuration states that can be formed by mutating the configuration item. If the number of non-repeating configuration states that can be formed when mutating a certain configuration item is small, then after mutating the configuration item multiple times, there is a high probability that a configuration state that is the same as the configuration state that has been tested before will be formed. For example, some configuration items correspond to Boolean values ​​as their configuration parameters, meaning there are only two possible configuration states: true and false. This means that mutating these parameters can only produce two different configuration states. If two consecutive configuration file modifications only mutate this one item, the second mutation will result in the same configuration state as the first. Therefore, for configuration items with Boolean parameters, a smaller initial value can be set for the second weighting coefficient. Conversely, for configuration items with numeric parameters, where the valid parameter can be any value within a range, the number of unique configuration states that can be generated by mutation is greater, making it less likely for the states to repeat. Therefore, a larger initial value can be set for the second weighting coefficient for numeric parameters. Specifically, a mapping relationship between configuration parameters of various data types and the second weighting coefficient can be pre-established. Then, based on this mapping relationship, the initial value of the second weighting coefficient for each configuration item can be determined. Furthermore, the second weighting coefficient for each configuration item can be dynamically adjusted according to certain rules during distributed database testing.

[0160] After determining the second weight coefficient corresponding to each configuration item, the mutation probability corresponding to each configuration item can be determined by normalizing the second weight coefficients of all configuration items in the seed configuration file. Then, mutated configuration items can be determined from all configuration items in the seed configuration file based on the magnitude of the mutation probability. Specifically, in one embodiment, the configuration items in the seed configuration file can be sorted in descending order of mutation probability, and the top few configuration items in the sorted list can be determined as mutated configuration items; alternatively, random sampling can be performed from all configuration items in the seed configuration file according to the magnitude of the mutation probability, where the probability of each configuration item being sampled is the mutation probability corresponding to that configuration item, and the sampled configuration items can be used as mutated configuration items.

[0161] In step 2502, after mutating the configuration item, a mutated configuration file is obtained. The distributed database process is then restarted based on the mutated seed configuration file, or the distributed database is directly redeployed, thereby updating the current configuration state of the distributed database. This current configuration state is obtained by mutating the configuration parameters of the mutated configuration item. Based on this, the current configuration state can be determined as the first configuration state corresponding to the mutated configuration item.

[0162] In step 2503, after updating the current configuration state, the distributed database will restart acquiring test cases and execute them in the updated current configuration state until the configuration file needs to be modified again. If the first count remains unchanged when executing test cases in the first configuration state corresponding to the mutated configuration item, this indicates that the triggered logical branches have not increased before and after the mutation of the configuration parameters of the mutated configuration item. Modifying the configuration parameters of the mutated configuration item has only a low probability of calling the underlying logic block that has not been called before. Based on this, the probability of mutating the configuration parameters of the mutated configuration item again when modifying the configuration file in subsequent modifications should be reduced; that is, the second weight coefficient corresponding to the mutated configuration item should be reduced at this time.

[0163] Furthermore, since no unused underlying logic blocks are invoked when executing test cases in the first configuration state, meaning the testable logic branches in the first configuration state are identical to those in the previous current configuration states, it can be assumed that the mutated configuration file used to generate the first configuration state is homogeneous with the previous configuration file (i.e., the existing configuration files in the configuration file seed pool). To avoid wasting memory space in the configuration file seed pool by storing homogeneous configuration files, refer to... Figure 21 If the first count remains unchanged when executing test cases in the first configuration state, the mutated configuration file is discarded without being added to the configuration file seed pool.

[0164] In step 2504, if the first count changes when executing a test case in the new current configuration state, i.e., the first configuration state, meaning that the underlying logic block that could not be called in the previous current configuration state can be called in the first configuration state, a new logic branch will be triggered. At this time, it can be considered that mutating the configuration parameters of the mutated configuration item corresponding to the first configuration state has a higher probability of triggering a new logic branch, thereby calling the underlying logic block that would not be called in the previous current configuration state. Based on this, the second weight coefficient corresponding to the mutated configuration item should be increased so that there is a greater probability of mutating the mutated configuration item again when modifying the configuration file in the future.

[0165] Furthermore, since executing test cases in this first configuration state can invoke underlying logic blocks that have not been invoked before, this indicates that the logical branches that can be triggered in the first configuration state are different from the logical branches that can be tested in the various current configuration states before mutation. That is, there is a difference between the mutated configuration file used to generate this first configuration state and the existing configuration files in the configuration file seed pool. At this point, refer to... Figure 21 The mutated configuration file can be added to the configuration file seed pool, serving as a seed configuration file to be selected when modifying the configuration file later. This increases the diversity of configuration file mutations and thus improves the comprehensiveness of the test.

[0166] In steps 2501 to 2504, a corresponding second weight coefficient is set for each configuration item. During the testing process, the second weight coefficient of each configuration item is dynamically updated based on whether a new underlying logic block can be called after modifying the configuration parameters of the configuration item. This increases the second weight coefficient of configuration items that can call previously uncalled underlying logic blocks after mutation, and decreases the second weight coefficient of configuration items that do not call previously uncalled underlying logic blocks after mutation. In this way, when modifying the configuration file, configuration items with a higher probability of triggering new logical branches can be mutated first, increasing the probability of calling previously uncalled underlying logic blocks after each configuration file modification. This allows for more efficient testing of more underlying logic blocks, improving the efficiency and coverage of testing distributed databases, and more accurately detecting vulnerabilities in distributed databases.

[0167] In one embodiment, refer to Figure 26 In step 2003, after mutating the configuration parameters of the mutated configuration item based on the parameter mutation method, the method further includes: Step 2601: Obtain the configuration item associated model; Step 2602: Determine the associated configuration item corresponding to the mutated configuration item based on the configuration item association model, and if the configuration parameter of the mutated configuration item is consistent with the first configuration parameter in the conflicting configuration parameter pair, and the configuration parameter of the associated configuration item is consistent with the second configuration parameter in the conflicting configuration parameter pair, then mutate the configuration parameter of the mutated configuration item again based on the parameter mutation method.

[0168] In step 2601, the configuration item association model can be obtained by modeling based on prior knowledge. The configuration item association model is used to indicate the associated configuration items of each configuration item in the configuration file, as well as the conflicting configuration parameter pairs between each configuration item and its associated configuration item. The conflicting configuration parameter pairs include the first configuration parameter corresponding to the configuration item and the second configuration parameter corresponding to the associated configuration item, wherein the first configuration parameter and the second configuration parameter refer to the following: In this embodiment, the conflict between the configuration item and its corresponding associated configuration item refers to the situation where, when the configuration parameter of the configuration item and the configuration parameter of the corresponding associated configuration item take a certain specific value, it will cause the distributed database to malfunction or cause the configuration parameter of at least one of the configuration item and the associated configuration item to become invalid.

[0169] It's understandable that configuration items in a distributed database's configuration file can affect each other. Some configuration parameters are interrelated. If configuration parameter A is set to 'a', setting configuration parameter B to 'b' will cause the distributed database to malfunction or allow configuration parameter B to automatically revert to its default value. For example, in the TDSQL database, the configuration file for configuring database server properties contains an 'isolation-read' configuration item. Under this item, there is a configuration item named 'engine', which specifies the storage engine to use when reading data. If the deployment configuration file does not have a Tdstore node configured, meaning the Tdstore storage engine is not deployed when the distributed database is deployed, and the configuration parameter of the engine configuration item is changed from the default parameter to [tdsql, "tdstore"] when the configuration file is mutated (where tdsql represents the in-memory table area inside TDSQL; since users cannot actively use the in-memory table area inside TDSQL, this is equivalent to specifying that only Tdstore can be used for queries), when reading data, because the engine configuration item specifies that only the Tdstore storage engine can be used, and the Tdstore storage engine is not actually deployed in the distributed database, the query operation cannot be performed when the distributed database is running. Alternatively, the configuration parameter of the engine configuration item may be rolled back to the default parameter to use another storage engine to complete the query operation, thus rendering this mutation of the configuration item ineffective.

[0170] Based on this, in this embodiment, for each configuration item, associated configuration items are determined in advance, and parameter pairs that will cause conflicts between the configuration item and associated configuration items are determined. In this way, the configuration items of each configuration file are modeled in advance to form a configuration item association model. Subsequently, by obtaining the configuration item association model, after each modification of the configuration file, the database will not be able to run normally after the configuration parameters of the mutated configuration item are mutated based on the configuration item association model, and the validity of the mutation operation will be detected.

[0171] In step 2602, it is understood that when mutating the configuration parameters of a mutated configuration item, the original configuration parameters of the mutated configuration item are randomly modified to obtain the mutated configuration parameters. This process is uncontrollable, and the mutated configuration parameters may conflict with the configuration parameters of the associated configuration items. Therefore, in this embodiment, after mutating the configuration parameters of the mutated configuration item, the associated configuration items corresponding to the mutated configuration item are detected based on the configuration item association model, and it is detected whether the mutated configuration parameters of the mutated configuration item and the configuration parameters of the associated configuration item constitute a conflicting configuration parameter pair. That is, it is detected whether the configuration parameters of the mutated configuration item and the configuration parameters of the associated configuration item are respectively the first configuration parameter and the second configuration parameter. If the configuration parameters of the mutated configuration item are the first configuration parameter and the configuration parameters of the associated configuration item are the second configuration parameter, the configuration parameters of the mutated configuration item are mutated again. For example, if the mutated configuration item is configuration item A, the configuration item association model indicates that when configuration item A has an associated configuration item B, and the configuration parameter of configuration item A is a_1 and the configuration parameter of configuration item B is b_1, it will cause an error in the distributed database. In this case, if the configuration parameter of the mutated configuration item is a_1, and the configuration parameter of the associated configuration item B is b_1, then the configuration parameter of the mutated configuration item will be mutated again.

[0172] In the embodiments disclosed in steps 2601 to 2602, a pre-built configuration item association model is obtained. This configuration item association model indicates the conflicting configuration parameter pairs formed by the configuration parameters corresponding to conflicts between various configuration items in the configuration file. Thus, after the configuration parameters of the mutated configuration item are mutated, the associated configuration item corresponding to the mutated configuration item is determined based on the configuration item association model, and it is detected whether the configuration parameters of the mutated configuration item and the configuration parameters of the associated configuration item constitute the conflicting configuration parameter pairs indicated by the configuration item association model. If they constitute conflicting configuration parameter pairs, the configuration parameters of the mutated configuration item are mutated again. This avoids the distributed database from failing to run properly due to modification of the configuration file, and avoids the waste of resources in the subsequent testing process due to invalid modification of the configuration file (i.e., invalid mutated configuration parameters or mutated configuration parameters being rolled back to the default parameters of the mutated configuration item).

[0173] In one embodiment, refer to Figure 27 Before step 304, the method also includes: Step 2701: For each configuration item in the configuration file, set the set of available parameters for that configuration item; In step 2701, the available parameter set for a configuration item is a set of valid configuration parameters corresponding to that configuration item. It is understood that if an invalid configuration parameter is entered into a configuration item in the configuration file, the distributed database will malfunction. Therefore, in this embodiment, by pre-setting the available parameter set for each configuration item, the validity of the mutated configuration parameters can be detected by checking whether they fall within the available parameter set. Specifically, for each configuration item, an available parameter set can be constructed based on the valid configuration parameters supported by that item. For example, if a configuration item is used to configure the maximum memory usage of a single database node, and that database node supports a maximum memory usage of 10GB, then the valid parameters for that configuration item are any values ​​between 0GB and 10GB, and the corresponding available parameter set can be represented as [0GB, 10GB].

[0174] In step 2003, after mutating the configuration parameters of the mutated configuration item based on the parameter mutation method, the following steps are also included: Step 2702: If there are no configuration parameters for the mutated configuration item in the available parameter set corresponding to the mutated configuration item, the configuration parameters of the mutated configuration item are mutated again based on the parameter mutation method.

[0175] In step 2702, referring to the relevant description in step 2003, the process of mutating the configuration parameters of the mutated configuration item is relatively random. This makes the configuration parameters obtained after mutation unpredictable, and they may be invalid parameters. For example, in the configuration file of the TDSQL database, for the engine configuration item under the isolation-read configuration item, it is applicable to specifying the storage engine that can be used when reading data. The configuration parameters of this engine configuration item can only be written to one or more of the preset strings such as "tdsql" and "tdstore". In this case, if the engine configuration item is determined as a mutated configuration item, when mutating the configuration parameters of this configuration item, a string different from the preset strings such as "tdstore" and "tdsql" is obtained, such as "Tdstoed". If this string is used as the configuration parameter of the engine configuration item, it will cause the distributed database to malfunction. In this case, the configuration parameter obtained by mutation is an invalid parameter.

[0176] Based on this, in this embodiment, refer to Figure 28 After mutating the configuration parameters of the mutated configuration item, check whether the mutated configuration parameter exists in the set of available parameters of the corresponding configuration item. If it exists, it means that the mutated configuration parameter is valid and can be used. If it does not exist, it means that the mutated configuration parameter is invalid. At this time, discard the invalid parameter and mutate the configuration parameters of the mutated configuration item again until the mutated configuration parameter is in the set of available parameters of the corresponding configuration item.

[0177] In the embodiments disclosed in steps 2701 to 2702, by pre-setting a set of available parameters for each configuration item, the range of legal parameters for each configuration item is determined. After mutating the configuration parameters of the mutated configuration item, it is checked whether the mutated configuration parameters exist in the set of available parameters for the corresponding configuration item. If not, the configuration parameters of the mutated configuration item are mutated again until the mutated configuration parameters are in the set of available parameters for the corresponding configuration item. This ensures that the configuration file obtained after each modification of the configuration file is legal.

[0178] Description of the effects of the embodiments disclosed herein Reference Figure 29 , Figure 29 This is an error report when testing a TDSQL database using the method proposed in the embodiments of this disclosure. Figure 29 The image shows the query results when the following two statements are used to query data in the TDSQL database according to the same conditions.

[0179] select / * read_from_storage(tdstore[t2]) * / right(c, cast(-1 asunsigned)) from t2; The first time this statement is used to query data in the TDSQL database, the result is an empty set. However, the second time the statement is used with the same conditions, the string "abcd" is returned as the query result. Here, the field `right(c, cast(-1 as unsigned))` indicates that the string `c` should contain characters of length `cast(-1 as unsigned)`. When this statement is executed for the first time in the TDSQL database, the second parameter of `right` is recognized as a signed integer. However, after using the `cast` function to convert -1 to an unsigned integer, a value with all bits set to 1 is obtained. If this result is treated as a signed integer, the sign bit being 1 indicates a negative number. Therefore, even after converting -1 to an unsigned integer, the final query result will still be an empty string. But when the statement is executed for the second time, it correctly recognizes `cast(-1 as unsigned)` in the `right` function as an unsigned integer, thus returning the string `c` containing characters of length `cast(-1 as unsigned)` as the query result.

[0180] Example of the specific usage process of the distributed database testing method in this disclosure embodiment The following reference Figure 30 This document describes in detail a specific usage process of the database testing method according to an embodiment of the present disclosure. The process includes, but is not limited to, the following steps. In this process, the server will be described as independently undertaking all tasks in the distributed database testing. However, those skilled in the art should understand that the process can also be completed independently by the terminal, or by the terminal and the server respectively undertaking a portion of the tasks.

[0181] Step 3001. Divide the underlying logic source code of the distributed database into underlying logic blocks, generate call status mark change tasks for the underlying logic blocks, and associate the call status mark change tasks with the underlying logic blocks; Step 3002. Compile the underlying logic block and the call status flag change task associated with the underlying logic block to obtain the compiled file, and deploy the compiled file to each database node; Step 3003. Determine the initial configuration state of the distributed database as the current configuration state; Step 3004. For each test case to be generated, determine the test case type and the corresponding test case template; Step 3005. For each test case to be generated, obtain the seed sequence to be mutated from the first seed pool according to the first weight coefficient of each candidate seed sequence, and perform mutation processing on the seed sequence to be mutated to obtain the mutated binary sequence corresponding to the test case, and reduce the first weight coefficient of the seed sequence to be mutated. Step 3006. Fill the test case template corresponding to each test case to be generated into the mutated binary sequence corresponding to the test case to be generated, and obtain the test case; Step 3007. Generate a first number of database modification statements and execute them in the distributed database, incrementing the second count by the first number; Step 3008. Execute multiple test cases in the distributed database under the current configuration state, and after the test cases are executed, use the call status flag change task associated with the underlying logic block to set the call status flag of the underlying logic block to the first status value; Step 3009. If the call status flag of the underlying logic block changes from the second status value to the first status value, increment the first count by 1 and check whether the first count meets the predetermined conditions. If yes, end the test; otherwise, set the fourth count to 0, increase the second weight coefficient of the mutated configuration item when the configuration file was modified in the previous time, add the mutated configuration file when the configuration file was modified to the configuration file seed pool, and execute step 3010. Step 3010. If the first count remains unchanged during the execution of a predetermined number of consecutive test cases in multiple test cases, check whether the second count is less than the first threshold. If yes, return to step 3007; otherwise, execute step 3011. Step 3011. Check if the third count is less than the second threshold. If yes, set the second count to 0, increment the third count by 1, and return to step 3007; if no, proceed to step 3012. Step 3012. Set the third count to 0 and check whether the fourth count is greater than the third threshold. If yes, determine the deployment configuration file with the fewest mutations from the configuration file seed pool as the seed configuration file and execute step 3013; if no, determine the non-deployment configuration file with the fewest mutations from the configuration file seed pool as the seed configuration file and execute step 3013. Step 3013. Determine the mutation configuration items and the corresponding parameter mutation methods based on the second weight coefficient of each configuration item in the seed configuration file; Step 3014. Variate the configuration parameters of the variant configuration item based on the parameter mutation method; Step 3015. Obtain the configuration-related model, determine the associated configuration items of the mutated configuration items, and check whether the configuration parameters of the mutated configuration items conflict with the configuration parameters of the associated configuration items. If yes, return to step 3014; otherwise, proceed to step 3016. Step 3016. Obtain the set of available configuration parameters corresponding to the mutation configuration item, and determine whether the available configuration parameters of the mutation configuration item contain the configuration parameters of the mutation configuration item. If yes, proceed to step 3017; otherwise, return to step 3014. Step 3017. Update the current configuration state of the distributed database based on the mutated configuration parameters, and return to step 3004.

[0182] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0183] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0184] Description of apparatus and devices according to embodiments of this disclosure Reference Figure 31 , Figure 31 This is a schematic diagram of the structure of the distributed database testing device 3100 provided in this embodiment of the disclosure. The distributed database testing device 3100 includes: The state determination unit 3110 is used to determine the initial configuration state of the distributed database as the current configuration state; The test case acquisition unit 3120 is used to acquire multiple test cases, which are used to call at least a portion of the underlying logic blocks opened in the distributed database. The test case execution unit 3130 is used to execute multiple test cases in the distributed database under the current configuration state, and after the test cases are executed, the call status flag of the underlying logic block called by the test cases is set to the first status value; Configuration change unit 3140 is used to adjust the configuration parameters of the distributed database to update the current configuration status, update multiple test cases, and trigger the test case execution unit and configuration change unit to re-execute until the number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition.

[0185] Optionally, the distributed database testing apparatus 3100 further includes a tagging unit, which is used for: The underlying logic source code of the distributed database is divided into underlying logic blocks, a call status mark change task is generated for the underlying logic block, and the call status mark change task is associated with the underlying logic block. The underlying logic blocks and the call status flag change tasks associated with the underlying logic blocks are compiled to obtain the compiled files. The compiled files are then deployed to each database node so that each database node can parse the underlying logic blocks from the compiled files. After the test case is executed, the call status flag of the underlying logic block called by the test case is set to the first status value. This includes: after the underlying logic block is called to execute the test case, the call status flag of the underlying logic block is changed using the call status flag change task associated with the underlying logic block, and the call status flag of the underlying logic block is set to the first status value.

[0186] Optionally, the initial value of the call status flag of the underlying logic block is the second status value; The use case execution unit 3130 is also configured to: if the call status flag of the underlying logic block changes from the second status value to the first status value, increment the first count by 1, the first count being used to indicate the number of underlying logic blocks that have been called; The configuration change unit 3140 is specifically used to: determine the number of underlying logic blocks whose call status flag is set to the first status value if the first count reaches a predetermined condition.

[0187] Optionally, the configuration change unit 3140 is specifically used for: If the first count remains unchanged during the execution of a predetermined number of consecutive test cases across multiple test cases, then the configuration parameters of the distributed database are adjusted to update the current configuration state.

[0188] Optionally, the distributed database testing device 3100 also includes a statement generation unit, which is specifically used for: Generate a first number of database modification statements and send them to the distributed database for execution, so that the distributed database can modify the data storage state of the distributed database according to the database modification statements to satisfy multiple test cases. The first number is less than a first threshold. Initialize the second counter to the first count; Configuration change unit 3140 is specifically used for: If, during the execution of a predetermined number of consecutive test cases in multiple test cases, the first count remains unchanged and the second count is less than the first threshold, then a database modification statement is added, sent to the distributed database for execution, and the second count is increased by increasing the number of database modification statements. If, during the execution of a predetermined number of consecutive test cases across multiple test cases, the first count remains unchanged and the second count is not less than the first threshold, then the configuration parameters of the distributed database are adjusted to update the current configuration state.

[0189] Optionally, the configuration change unit 3140 is specifically used for: If the second count is not less than the first threshold and the third count is less than the second threshold, clear the distributed database, set the second count to 0, increment the third count by 1, update multiple test cases, and trigger the test case execution unit and configuration change unit to re-execute. If the second count is not less than the first threshold and the third count is not less than the second threshold, modify the configuration file of the distributed database and set the second count and the third count to 0.

[0190] Optionally, the use case acquisition unit 3120 is specifically used for: For each test case to be generated, determine the test case type and the corresponding test case template. The test case template is a database operation statement template corresponding to the test case type. For each test case to be generated, a seed sequence to be mutated is obtained from the first seed pool, and the seed sequence to be mutated is mutated to obtain the mutated binary sequence corresponding to the test case to be generated, wherein the seed sequence to be mutated is a binary sequence. The mutated binary sequence corresponding to each test case to be generated is filled into the test case template corresponding to the test case to be generated, thus obtaining the test case; The distributed database testing device 3100 also includes a seed sequence processing unit, which is specifically used for: If the first count changes while executing a test case, the mutated binary sequence corresponding to the test case is added to the first seed pool.

[0191] Optionally, the use case generation unit is specifically used for: In the first seed pool, the candidate seed sequences are sorted from largest to smallest according to the first weight coefficient, and the seed sequence to be mutated is determined from the candidate seed sequences based on the sorting result. Reduce the first weight coefficient corresponding to the seed sequence to be mutated.

[0192] Optionally, the use case execution unit 3130 is specifically used for: When the test case is a database query statement, a single-node database is created based on the data storage status of the distributed database. The data stored in the single-node database consists of the data in each storage node of the distributed database. Execute test cases corresponding to the test case types in both the distributed database and the single-node database, and record the first execution result of the test cases in the distributed database and the second execution result of the test cases in the single-node database. The test result is determined based on the comparison between the first execution result and the second execution result.

[0193] Optionally, the use case execution unit 3130 is specifically used for: When test cases include multiple database modification test statements, a state snapshot is generated based on the data storage state of the distributed database. The state snapshot is used to characterize the data storage state of the distributed database before executing multiple database modification test statements. Multiple database modification test statements are executed concurrently in a distributed database to obtain a third execution result. The third execution result is used to characterize the data storage status of the distributed database after the concurrent execution of multiple database modification test statements. The test statements modifying multiple databases are permuted to obtain a sorted list of test statements. Each test statement is sequentially sorted to determine the execution order, and the first test process is executed based on the execution order. The first test process includes: rolling back the distributed database based on a state snapshot, and executing multiple database modification test statements sequentially according to the execution order in the rolled-back distributed database to obtain the fourth execution result corresponding to the execution order. The fourth execution result is used to characterize the data storage state of the distributed database after executing multiple database modification test statements sequentially according to the execution order; if the fourth execution result is different from the third execution result, the next test statement is sorted to determine the new execution order, and the first test process is executed based on the execution order until the fourth execution result corresponding to the execution order is consistent with the third execution result or the execution order is the last test statement sorting, and the test result is obtained.

[0194] Optionally, the configuration change unit 3140 is specifically used for: The seed configuration file is determined from the configuration file seed pool, which includes multiple configuration files of the distributed database. The seed configuration file is one of these multiple configuration files and includes multiple configuration items. The mutated configuration items are determined from multiple configuration items in the seed configuration file. The mutated configuration items are several of the multiple configuration items. The parameter mutation method corresponding to the mutated configuration item is determined based on the configuration parameter type of the mutated configuration item, and the configuration parameters of the mutated configuration item are mutated based on the parameter mutation method. The configuration file of the distributed database is then updated based on the mutated configuration parameters.

[0195] Optionally, the configuration files for the distributed database include deployment configuration files and non-deployment configuration files. The deployment configuration files are used to add or delete database nodes in the distributed database and to set the topology of the database nodes. The configuration change unit 3140 is specifically used for: Each time the configuration file is modified, the fourth counter is incremented by 1, and the fourth counter is set to 0 when the number of underlying logic blocks whose call status flag is set to the first status value changes. When the fourth count is not greater than the third threshold, determine the number of mutations of each non-deployment configuration file in the configuration file seed pool, and determine the non-deployment configuration file with the fewest mutations as the seed configuration file, and increment the mutation count of the seed configuration file by 1; When the fourth count is greater than the third threshold, the number of mutations for each deployment configuration file is determined, and the deployment configuration file with the fewest mutations is identified as the seed configuration file, and the fourth count is set to 0.

[0196] Optionally, the configuration change unit 3140 is specifically used for: Based on the second weight coefficient corresponding to each configuration item, the mutation probability of each configuration item is determined, and based on the mutation probability of each configuration item, the mutated configuration item is determined from multiple configuration items in the seed configuration file. The current configuration state obtained after mutating the mutated configuration item is determined as the first configuration state corresponding to the mutated configuration item. If, during the execution of test cases in the first configuration state, the number of underlying logic blocks whose status flags are set to the first status value remains unchanged, the second weight coefficient corresponding to the mutation configuration item is reduced. If, during the execution of test cases in the first configuration state, the number of underlying logic blocks whose status flags are set to the first status value changes, the second weight coefficient corresponding to the mutation configuration item is increased.

[0197] Optionally, the configuration change unit 3140 is specifically used for: Obtain the configuration item association model, wherein the configuration item association model is used to indicate the associated configuration items of each configuration item in the configuration file, as well as the conflict configuration parameter pairs between each configuration item and the associated configuration items corresponding to the configuration items. The conflict configuration parameter pairs include the first configuration parameter corresponding to the configuration item and the second configuration parameter corresponding to the associated configuration item. Based on the configuration item association model, the associated configuration item corresponding to the mutated configuration item is determined. If the configuration parameter of the mutated configuration item is consistent with the first configuration parameter in the conflicting configuration parameter pair, and the configuration parameter of the associated configuration item is consistent with the second configuration parameter in the corresponding conflicting configuration parameter pair, the configuration parameter of the mutated configuration item is mutated again based on the parameter mutation method.

[0198] Optionally, the booking conditions include one of the following: The number of underlying logic blocks whose call status flag is set to the first status value is equal to the total number of underlying logic blocks in the distributed database; The number of underlying logic blocks whose call status flag is set to the first status value has reached a predetermined number, which is less than the total number of underlying logic blocks in the distributed database. The ratio of the number of underlying logic blocks whose call status flag is set to the first status value to the total number of underlying logic blocks in the distributed database reaches a predetermined ratio. Reference Figure 32 , Figure 32 To implement the distributed database testing method of this embodiment, the target terminal's structural block diagram includes: a radio frequency (RF) circuit 3210, a memory 3215, an input unit 3230, a display unit 3240, a sensor 3250, an audio circuit 3260, a wireless fidelity (WiFi) module 3270, a processor 3280, and a power supply 3290, etc. Those skilled in the art will understand that... Figure 32 The terminal structure shown does not constitute a limitation on mobile phones or computers, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0199] The RF circuit 3210 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 3280; in addition, it transmits uplink data to the base station.

[0200] The memory 3215 can be used to store software programs and modules, and the processor 3280 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 3215.

[0201] The input unit 3230 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the content terminal. Specifically, the input unit 3230 may include a touch panel 3231 and other input devices 3232.

[0202] Display unit 3240 can be used to display input or provided information, as well as various menus of the content terminal. Display unit 3240 may include display panel 3241.

[0203] Audio circuitry 3260, speaker 3261, and microphone 3262 provide an audio interface.

[0204] In this embodiment, the processor 3280 included in the object terminal can execute the distributed database testing method of the previous embodiment.

[0205] The target terminals of this disclosure include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to text-based image processing and molecular graph modeling.

[0206] Figure 33 This is a partial structural block diagram of a server for implementing the distributed database testing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include one or more Central Processing Units (CPUs) 3322 (e.g., one or more processors) and memory 3332, and one or more storage media 3330 (e.g., one or more mass storage devices) for storing application programs 3342 or data 3344. The memory 3332 and storage media 3330 can be temporary or persistent storage. The program stored in the storage media 3330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 3322 may be configured to communicate with the storage media 3330 and execute the series of instruction operations in the storage media 3330 on the server.

[0207] The server may also include one or more power supplies 3333, one or more wired or wireless network interfaces 3350, one or more input / output interfaces 3358, and / or one or more operating systems 3341, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0208] The central processing unit 3322 in the server can be used to execute the distributed database testing method of the present disclosure embodiments.

[0209] This disclosure also provides a computer-readable storage medium for storing program code for executing the distributed database testing methods of the foregoing embodiments.

[0210] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the distributed database testing method described above.

[0211] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar terms and are not necessarily used to describe a particular order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0212] It should be understood that in this disclosure, "at least one item" refers to one or more items, and "more than one item" refers to two or more items. "And / or" is used to describe the relationship between related content, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related content are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0213] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0214] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0215] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0216] In addition, in the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0217] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0218] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects. The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A distributed database testing method, characterized in that, The distributed database comprises multiple database nodes, each of which deploys multiple underlying logical blocks. Furthermore, the underlying logical blocks enabled in the distributed database are not entirely the same under different configuration states. The method includes: The initial configuration state of the distributed database is taken as the current configuration state; Obtain multiple test cases, which are used to invoke at least a portion of the underlying logic blocks opened in the distributed database; The multiple test cases are executed in the distributed database under the current configuration state, and after the test cases are executed, the call status flag of the underlying logic block called by the test cases is set to the first status value. Adjust the configuration parameters of the distributed database to update the current configuration state, update the multiple test cases, and return to the steps of executing the multiple test cases respectively in the distributed database under the current configuration state, until the number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition.

2. The method according to claim 1, characterized in that, Before determining the initial configuration state of the distributed database as the current configuration state, the method further includes: The underlying logic source code of the distributed database is divided into underlying logic blocks, a call status mark change task is generated for the underlying logic block, and the call status mark change task is associated with the underlying logic block; The underlying logic block and the call status flag change task associated with the underlying logic block are compiled to obtain a compiled file. The compiled file is then deployed to each database node so that each database node can parse the underlying logic block from the compiled file. The step of setting the call status flag of the underlying logic block called by the test case to a first status value after the test case is executed includes: after the test case is executed by calling the underlying logic block, using the call status flag change task associated with the underlying logic block, setting the call status flag of the underlying logic block to the first status value.

3. The method according to claim 1 or 2, characterized in that, The initial value of the call status flag of the underlying logic block is the second status value; After setting the call status flag of the underlying logic block invoked by the test case to a first status value, the method further includes: if the call status flag of the underlying logic block changes from the second status value to the first status value, incrementing a first count by 1, wherein the first count is used to indicate the number of underlying logic blocks invoked; The number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition, including: if the first count reaches the predetermined condition, determining that the number of underlying logic blocks whose call status flag is set to the first status value reaches the predetermined condition.

4. The method according to claim 3, characterized in that, The step of adjusting the configuration parameters of the distributed database to update the current configuration state includes: If the first count remains unchanged during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the configuration parameters of the distributed database are adjusted to update the current configuration state.

5. The method according to claim 3, characterized in that, Before executing the plurality of test cases in the distributed database under the current configuration state, the method further includes: A first number of database modification statements are generated and executed in the distributed database so that the distributed database modifies the data storage state of the distributed database according to the database modification statements, wherein the first number is less than a first threshold. Initialize the second counter to the first number; If, during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the first count remains unchanged, then the configuration parameters of the distributed database are adjusted to update the current configuration state, including: If, during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the first count remains unchanged and the second count is less than the first threshold, then a database modification statement is added, sent to the distributed database for execution, and the number of database modification statements is increased, thereby increasing the second count. If, during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the first count remains unchanged and the second count is not less than the first threshold, then the configuration parameters of the distributed database are adjusted to update the current configuration state.

6. The method according to claim 5, characterized in that, If, during the execution of a predetermined number of consecutive test cases among the plurality of test cases, the first count remains unchanged and the second count is not less than the first threshold, then adjusting the configuration parameters of the distributed database to update the current configuration state includes: If the second count is not less than the first threshold and the third count is less than the second threshold, clear the distributed database, set the second count to 0, increment the third count by 1, update the plurality of test cases, and return to the step of executing the plurality of test cases in the distributed database under the current configuration state. If the second count is not less than the first threshold and the third count is not less than the second threshold, adjust the configuration parameters of the distributed database and set the second count and the third count to 0.

7. The method according to claim 3, characterized in that, The acquisition of multiple test cases includes: For each test case to be generated, the test case type is determined, and the test case template corresponding to the test case type is determined. The test case template is a database operation statement template determined based on the syntax of the distributed database. For each test case to be generated, a seed sequence to be mutated is obtained from the first seed pool, and the seed sequence to be mutated is mutated to obtain the mutated binary sequence corresponding to the test case to be generated, wherein the seed sequence to be mutated is a binary sequence. The mutated binary sequence corresponding to each test case to be generated is filled into the test case template corresponding to the test case to be generated, thereby obtaining the test case; After obtaining multiple test cases, the method further includes: If the first count changes during the execution of the test case, the mutated binary sequence corresponding to the test case is added to the first seed pool.

8. The method according to claim 7, characterized in that, The first seed pool includes multiple candidate seed sequences, each of which is assigned a first weight coefficient. The step of obtaining the seed sequence to be mutated from the first seed pool includes: In the first seed pool, the candidate seed sequences are sorted from largest to smallest according to the first weight coefficient, and the seed sequence to be mutated is determined from the candidate seed sequences based on the sorting result; Reduce the first weight coefficient corresponding to the seed sequence to be mutated.

9. The method according to any one of claims 1-8, characterized in that, The execution of the multiple test cases in the distributed database under the current configuration state includes: When the test case is a database query statement, a single-node database is created based on the data storage status of the distributed database. The data stored in the single-node database consists of the data in each storage node of the distributed database. The test cases corresponding to the test case types are executed in the distributed database and the single-node database respectively, and the first execution result of the test cases executed in the distributed database and the second execution result of the test cases executed in the single-node database are recorded. The test result is determined based on the comparison between the first execution result and the second execution result.

10. The method according to any one of claims 1-9, characterized in that, The execution of the multiple test cases in the distributed database under the current configuration state includes: When the test case includes multiple database modification test statements, a state snapshot is generated based on the data storage state of the distributed database. The state snapshot is used to characterize the data storage state of the distributed database before the execution of the multiple database modification test statements. The multiple database modification test statements are executed concurrently in the distributed database to obtain a third execution result, which is used to characterize the data storage status of the distributed database after the concurrent execution of the multiple database modification test statements. The multiple database modification test statements are permuted to obtain a sorted list of test statements. Each test statement is sequentially sorted to determine the order to be executed, and a first test process is executed based on the order to be executed. The first test process includes: rolling back the distributed database based on the state snapshot, and sequentially executing the multiple database modification test statements according to the order to be executed in the rolled-back distributed database to obtain a fourth execution result corresponding to the order to be executed. The fourth execution result is used to characterize the data storage state of the distributed database after the multiple database modification test statements are executed sequentially according to the order to be executed; if the fourth execution result is different from the third execution result, the next test statement is sorted to determine a new order to be executed, and the first test process is executed based on the order to be executed until the fourth execution result corresponding to the order to be executed is consistent with the third execution result or the order to be executed is the last order of the test statements, to obtain a test result.

11. The method according to any one of claims 1-10, characterized in that, Adjusting the configuration parameters of the distributed database includes: A seed configuration file is determined from a configuration file seed pool, which includes multiple configuration files of the distributed database. The seed configuration file is one of the multiple configuration files and includes multiple configuration items. A mutation configuration item is determined from a plurality of configuration items in the seed configuration file, wherein the mutation configuration item is a plurality of configuration items; The parameter mutation method is determined based on the configuration parameter type of the mutation configuration item, and the configuration parameters of the mutation configuration item are mutated based on the parameter mutation method. The configuration file of the distributed database is then updated based on the mutated configuration parameters.

12. The method according to claim 11, characterized in that, The configuration files for the distributed database include deployment configuration files and non-deployment configuration files. The deployment configuration files are used to add or delete database nodes in the distributed database and to set the topology of the database nodes. Before determining the seed configuration file from the configuration file seed pool, the following steps are included: Each time the configuration file is modified, the fourth counter is incremented by 1, and the fourth counter is set to 0 when the number of underlying logic blocks whose call status flag is set to the first status value changes. The step of determining the seed configuration file from the configuration file seed pool includes: When the fourth count is not greater than the third threshold, the mutation count of each of the non-deployment configuration files in the configuration file seed pool is determined, and the non-deployment configuration file with the fewest mutation counts is determined as the seed configuration file, and the mutation count corresponding to the seed configuration file is incremented by 1; When the fourth count is greater than the third threshold, the number of mutations of each deployment configuration file is determined, and the deployment configuration file with the fewest mutations is determined as the seed configuration file, and the fourth count is set to 0.

13. The method according to claim 11, characterized in that, The step of determining the mutation configuration item from multiple configuration items in the seed configuration file includes: Based on the second weight coefficient corresponding to each configuration item, the mutation probability of each configuration item is determined, and based on the mutation probability of each configuration item, the mutated configuration item is determined from multiple configuration items in the seed configuration file. After mutating the configuration parameters of the mutated configuration item based on the parameter mutation method, and updating the configuration file of the distributed database based on the mutated configuration parameters, the method further includes: The current configuration state obtained after mutating the mutated configuration item is determined as the first configuration state corresponding to the mutated configuration item. If, during the execution of a test case in the first configuration state, the number of underlying logic blocks whose call status flag is set to the first status value remains unchanged, the second weight coefficient corresponding to the mutation configuration item is reduced. If, during the execution of a test case in the first configuration state, the number of underlying logic blocks whose call status flag is set to the first status value changes, the second weight coefficient corresponding to the mutation configuration item is increased.

14. The method according to claim 11, characterized in that, After mutating the configuration parameters of the mutated configuration item based on the parameter mutation method, the method further includes: Obtain a configuration item association model, wherein the configuration item association model is used to indicate the associated configuration items of each configuration item in the configuration file, and the conflict configuration parameter pairs between each configuration item and the associated configuration item of the configuration item, wherein the conflict configuration parameter pairs include a first configuration parameter corresponding to the configuration item and a second configuration parameter corresponding to the associated configuration item; Based on the configuration item association model, the associated configuration item corresponding to the mutated configuration item is determined. If the configuration parameter of the mutated configuration item is consistent with the first configuration parameter in the conflicting configuration parameter pair and the configuration parameter of the associated configuration item is consistent with the second configuration parameter in the conflicting configuration parameter pair, the configuration parameter of the mutated configuration item is mutated again based on the parameter mutation method.

15. The method according to claim 11, characterized in that, Before adjusting the configuration parameters of the distributed database to update the current configuration state, the method further includes: For each configuration item in the configuration file, set the set of available parameters for that configuration item; After mutating the configuration parameters of the mutated configuration item based on the parameter mutation method, the method further includes: If the configuration parameters of the mutated configuration item do not exist in the available parameter set corresponding to the mutated configuration item, the configuration parameters of the mutated configuration item are mutated again based on the parameter mutation method.

16. The method according to any one of claims 1-15, characterized in that, The number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition, determined by one of the following: The number of underlying logic blocks whose call status flag is set to the first status value is equal to the total number of underlying logic blocks in the distributed database; The number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined number, which is less than the total number of underlying logic blocks in the distributed database; The ratio of the number of underlying logic blocks whose call status flag is set to the first status value to the total number of underlying logic blocks in the distributed database reaches a predetermined ratio.

17. A distributed database testing device, characterized in that, The device includes: The state determination unit is used to determine the initial configuration state of the distributed database as the current configuration state. The test case acquisition unit is used to acquire multiple test cases, wherein the test cases are used to call at least a portion of the underlying logic blocks opened in the distributed database; The test case execution unit is used to execute the plurality of test cases respectively in the distributed database under the current configuration state, and after the test case is executed, to set the call status flag of the underlying logic block called by the test case to a first status value; The configuration change unit is used to adjust the configuration parameters of the distributed database to update the current configuration status, update the multiple test cases, and trigger the test case execution unit and the configuration change unit to re-execute until the number of underlying logic blocks whose call status flag is set to the first status value reaches a predetermined condition.

18. An electronic device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the distributed database testing method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the distributed database testing method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the distributed database testing method according to any one of claims 1 to 16.

Images