Automatic database logic error detection method and system based on multiple execution plans

Abstract

The invention discloses an automatic database logic error detection method and system based on multiple execution plans. According to the method and system, a multi-execution-plan database for executing multiple execution plans on input DQL statements is constructed by performing certain adjustment on source codes of a relational database. And inputting a test case containing the DQL statement into the multi-execution plan database to obtain execution results of the DQL statement in the test case under multiple execution plans. And if the execution results of different execution plans are inconsistent, the logic errors exist in some execution plans, namely the logic errors exist in the database. A database issuer can find out the root cause of the program logic error by analyzing the execution plan and the specific execution process of the execution plan, and then the logic error is repaired. The method can be applied to all relational databases and can cover a large number of optimization strategy combinations in the relational databases.

Description

Technical Field

[0001] The present invention relates to a Test Oracle in the field of software testing, and more particularly to an automated database logic error detection method and system based on multiple execution plans. Background Art

[0002] A Test Oracle is a method for determining whether a test case is executed correctly and is an important link in the software testing process. In the field of software automated testing, test tools test a target program by randomly generating a large number of test cases, and it is difficult to generate an expected result for each generated test case to determine whether the test case is executed correctly. Therefore, a Test Oracle is needed to determine whether the generated test cases are executed correctly.

[0003] Existing database logic error Test Oracles are divided into two categories: Differential Testing and Metamorphic Testing. The core idea of Differential Testing is to find or construct multiple systems to be tested with similar functions for comparison. Input the test cases into these systems with similar functions and then observe the consistency of the results returned by the multiple systems. If there is an inconsistency, it indicates that one or more of the systems have a logic error. The core idea of Metamorphic Testing is to find a metamorphic relationship between a certain input change and an output change. Thus, predict the output result of the changed input based on the output result of an existing input. If the changed input fails to obtain the expected output result, it indicates that there is a logic error in the system.

[0004] The solutions for differential testing can be divided into two categories. One category of solutions is to use multiple different databases as the systems under test for comparison. By comparing that the execution results of the same input in different databases are consistent, logical errors can be detected. Since there are often significant functional differences among different databases, only a very small number of features that are completely consistent in multiple databases can be covered by this testing method. Another category of solutions is to use the same database with different optimization feature settings as the systems under test for comparison. Each optimization feature setting controls whether to allow a corresponding optimization of the SQL statement. Due to different optimization feature settings, the input statements will be affected by different optimization features and generate different execution plans. This solution detects logical errors by comparing the execution results of the same input in the same database with different optimization feature settings. However, this category of solutions has the following limitations. First, the optimization feature configurations provided by the database only include a part of all the optimization features, so some optimization features cannot be tested in this way. Second, the optimization feature settings are global configurations that act on the entire input statement, so it is impossible to enable optimization for a part of the statement while disabling optimization for another part. In other words, this solution cannot test some optimization combinations.

[0005] In the solutions based on metamorphic testing, a metamorphic relation only applies to a specific input model, so the covered features are limited by its limited input model. Summary of the Invention

[0006] Aiming at the deficiencies of the prior art, the present invention proposes an automated database logical error detection method and system based on multiple execution plans, which can cover all optimization features and their optimization combinations in relational databases.

[0007] The object of the present invention is achieved by the following technical solutions:

[0008] An automated database logical error detection system based on multiple execution plans, comprising a multiple execution plan database module and an output result comparison module;

[0009] The multiple execution plan database module is used to modify the original database, execute all possible execution plans for the DQL statements in the input test cases, and output the execution results of each execution plan; the specific modifications are as follows:

[0010] Modification 1: Insert a statement type judgment process between "parsing the input statement to generate a query tree" and "analyzing the query tree and generating an execution plan tree": If the statement type of the current execution statement is a DQL statement, enable multiple execution plans, otherwise disable multiple execution plans; and initialize the number of execution plans N = 1, and the current loop count n = 0;

[0011] Modification 2: Before calling the pruning function during the execution of "analyzing the query tree and generating the execution plan tree", add a conditional selection judgment: if the multi-execution plan is closed, maintain the original database execution process, that is, call the original pruning function; if the multi-execution plan is enabled, call the multi-execution plan pruning function; the multi-execution plan pruning function is: do not perform pruning and retain all subtrees to be pruned.

[0012] Modification 3: Add a conditional selection judgment between "generating all execution plan trees" and "selecting the optimal execution plan tree": if the multi-execution plan is closed, maintain the original database execution process, that is, call the original execution plan selection function; if the multi-execution plan is enabled, call the multi-execution plan selection function.

[0013] Modification 4: Add a new execution plan selection function based on the original execution plan selection function; the new execution plan selection function is specifically: First, count and update the total number of execution plans N; Second, select different execution plans according to the current loop count n.

[0014] Modification 5: Add a judgment loop between the start and end positions of the input statement processing function: that is, at the end position, first increment the loop count by 1, and then judge the relationship between the current loop count n and the total number of execution plans N. If n < N, it means that there are still unexecuted execution plans, and return to the front of the statement processing entry function to re-execute the statement processing process; if n >= N, it means that all execution plans have been executed or the multi-execution plan is not enabled, and exit the loop.

[0015] The output result comparison module is used to obtain and compare the execution results of all execution plans of the current test statement to judge whether there are logical errors in the program; if there are inconsistent execution results, it means that there are logical errors in the database.

[0016] Further, when the output result comparison module judges whether the execution results are consistent, it specifically includes the following sub-steps:

[0017] S201: For the current test statement, obtain the output results and the number of rows of all execution plans, and count the number of execution plans of the current test statement.

[0018] S202: Judge whether the number of execution plans is one. If the number of execution plans is one, it means that the statement is a non-DQL statement, or the statement is a DQL statement but there is only one execution plan, and the test passes; otherwise, execute S203.

[0019] S203: Compare whether the number of output rows of all execution plans is the same. If the number of output results of all execution plans is the same, execute S204; otherwise, it means that the test fails and the current statement triggers a logical error in the database.

[0020] S204: Sort the output results of each execution plan by row unit, and determine the sorting size according to the size relationship of the values of the data items under the corresponding original encoding type;

[0021] S205: Compare the sorted output results of each execution plan with the sorted data results of the first execution plan. If there is any sorted output result of an execution plan that is inconsistent with the sorted output result of the first execution plan, it indicates that the test fails and the current statement triggers a logical error in the database; otherwise, the test passes.

[0022] An automated database logical error detection method based on multiple execution plans, which is implemented by an automated database logical error detection system based on multiple execution plans, and specifically includes the following steps:

[0023] Step 1: Make the following modifications to the original database:

[0024] Modification 1: Insert a statement type judgment process between "the original database parses the input statement to generate a query tree" and "analyze the query tree and generate an execution plan tree": If the statement type of the current execution statement is a DQL statement, enable multiple execution plans, otherwise disable multiple execution plans; and initialize the execution plan quantity N = 1, and the current loop count n = 0;

[0025] Modification 2: Before calling the pruning function during the execution of "analyze the query tree and generate an execution plan tree", add a conditional selection judgment: If multiple execution plans are disabled, maintain the original database execution process, that is, call the original pruning function; if multiple execution plans are enabled, call the multiple execution plan pruning function; the multiple execution plan pruning function is: do not perform pruning and retain all subtrees to be pruned;

[0026] Modification 3: Add a conditional selection judgment between "generate all execution plan trees" and "select the optimal execution plan tree": If multiple execution plans are disabled, maintain the original database execution process, that is, call the original execution plan selection function; if multiple execution plans are enabled, call the multiple execution plan selection function;

[0027] Modification 4: Add a new execution plan selection function on the basis of the original execution plan selection function; the new execution plan selection function is specifically: First, count and update the total number of execution plans N; Second, select different execution plans according to the current loop count n;

[0028] Modification 5: Add a judgment loop between the start and end positions of the input statement processing function. That is, at the end position, first increment the loop count by 1, and then determine the relationship between the current loop count n and the total number of execution plans N. If n < N, it means there are still unexecuted execution plans, and go back to the entrance function of statement processing to re-execute the statement processing flow; if n >= N, it means all execution plans have been executed or multiple execution plans are not enabled, and exit the loop.

[0029] Step 2: Input the test cases containing DQL statements into the multiple execution plan database and execute them one by one. Determine whether it is necessary to perform multiple execution plans for the statement according to the type of the currently executed statement. Among them, non-DQL statements are executed according to the original logic of the database, that is, only executed once; DQL statements are executed with multiple execution plans, that is, generate and retain all possible execution plans, and then execute each execution plan one by one. After the test cases are executed, call the output result comparison module to obtain the output results of all execution plans of the test cases and compare the execution results. If there are inconsistent execution results, it means there are logical errors in the database and the test fails.

[0030] The beneficial effects of the present invention are as follows:

[0031] 1. The method of the present invention constructs a multiple execution plan database, which has little modification to the original database and does not generate illegal execution plans.

[0032] 2. The method of the present invention has no restrictions on the input, so this method can cover more database features.

[0033] 3. Compared with other test oracles, the method of the present invention can cover more types of optimizations and optimization combinations in the database. Description of the Drawings

[0034] Figure 1 is the overall test process schematic diagram of the automated logical error detection method for the database based on multiple execution plans in the embodiment of the present invention.

[0035] Figure 2 is the overall flowchart of the automated logical error detection method for the database based on multiple execution plans in the embodiment of the present invention.

[0036] Figure 3 is the schematic diagram of the process for the output result comparison module in the embodiment of the present invention to compare the execution results. Detailed Embodiments

[0037] The present invention will be described in detail below according to the drawings and preferred embodiments. The purpose and effects of the present invention will become more clear. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0038] The automated database logic error detection system based on multiple execution plans of the present invention constructs a multi-execution plan database that executes multiple execution plans for the input DQL (Data Query Language) statements by making certain adjustments to the relational database source code. By inputting test cases into this multi-execution plan database, the execution results of the DQL statements in the test cases under different execution plans are obtained. If the final execution results of different execution plans are inconsistent, it indicates that there are logical errors in some of the execution plans, that is, there are logical errors in the database. Database developers can find the root cause of the program logic error by analyzing the execution plan and its execution process, and then fix the logical error. The present invention can be applied to all relational databases and can cover a large number of optimization strategy combinations in relational databases.

[0039] It includes a multi-execution plan database module and an output result comparison module. Among them,

[0040] The multi-execution plan database module is used to modify the original database, including introducing four additional input statement processing processes in the test target database: statement type judgment process, multi-execution plan pruning process, multi-execution plan selection process, and multi-execution plan traversal process, and executing all possible execution plans for the DQL statements in the input test cases, and outputting the execution results of each execution plan.

[0041] The output result comparison module is used to obtain and compare the execution results of all execution plans of the current test statement to determine whether there are logical errors in the program; if there are inconsistent execution results, it indicates that there are logical errors in the database.

[0042] As Figure 1 shown, it shows the working process of the automated logic error detection method for a database based on multiple execution plans. First, the test cases will be executed one by one. According to the type of the currently executed statement, it is judged whether the statement needs to be executed with multiple execution plans; among them, non-DQL statements will be executed according to the original logic of the database, that is, only executed once; DQL statements will be executed with multiple execution plans, that is, all possible execution plans will be generated and retained, and then each execution plan will be executed. After the test cases are executed, the output result comparison module obtains the execution results of each statement. If there are output results of multiple execution plans for a statement, these output results are compared. If there are inconsistent results, it indicates that the statement has triggered a logical bug in the database.

[0043] As Figure 2As shown, it demonstrates how to modify the original database to construct a multi-execution plan database. In the figure, the process with a solid border and no color filling is the original query statement processing process of the database. The process filled with light red color is the newly added process of the multi-execution plan database. The process with a dashed border and no color filling is the process of the database before modification hijacked by the newly added process of the multi-execution plan database. As Figure 2 shown, the following five modifications are made to the original database, specifically:

[0044] Modification 1: Insert a statement type judgment process between "the original database parses the input statement to generate a query tree" and "analyze the query tree and generate an execution plan tree": If the statement type of the current execution statement is a DQL statement, enable multi-execution plans, otherwise disable multi-execution plans; and initialize the execution plan quantity N = 1, and the current loop count n = 0.

[0045] Modification 2: Before calling the pruning function during the execution of "analyze the query tree and generate an execution plan tree", add a conditional selection judgment: If multi-execution plans are disabled, maintain the original database execution process, that is, call the original pruning function; if multi-execution plans are enabled, call the multi-execution plan pruning function; the multi-execution plan pruning function is: do not perform pruning and retain all subtrees to be pruned.

[0046] That is, the original execution plan pruning process: The database decomposes the statement into a combination of smaller clauses, and then iteratively starts from the smallest clause to find the optimal execution sub-plan of the clause in certain evaluation dimensions and discards other execution sub-plans. Then it extends to the optimal execution sub-plan of the larger clause containing the clause, and finally finds the locally optimal execution plan of the entire statement. During this process of constructing the execution plan, the pruning function determines whether each execution sub-plan is retained or discarded.

[0047] The newly added execution plan pruning process: By hijacking the pruning function to retain every execution plan that determines whether pruning is required, all execution plans are retained.

[0048] Modification 3: Add a conditional selection judgment between "generate all execution plan trees" and "select the optimal execution plan tree": If multi-execution plans are disabled, maintain the original database execution process, that is, call the original execution plan selection function; if multi-execution plans are enabled, call the multi-execution plan selection function.

[0049] Modification 4: Add a new execution plan selection function based on the original execution plan selection function; the new execution plan selection function is specifically: First, count and update the total number of execution plans N; Second, select different execution plans according to the current loop count n.

[0050] That is: the original execution plan selection process: the execution plan generator will ultimately generate multiple optimal execution plan trees in different evaluation dimensions, and finally select one of them as the ultimately executed execution plan according to the rules. This selection is usually implemented by an execution plan selection function. When a sub-DQL statement is nested in a DQL statement, the optimal execution plan of the current DQL statement is selected once in each DQL statement. Finally, they are combined into the execution plan of the entire DQL statement.

[0051] The newly added plan selection process: Modify the execution plan selection function. When the DQL is executed for the first time, the number of execution plans of the current DQL will be recorded each time it is called. If the DQL statement nests m sub-DQL statements, the number of execution plans of the current DQL clause will be recorded each time the execution plan selection function is called for the first time in each clause. Denote the number of execution plans of each sub-DQL statement as N 1 , N 2 , …N m , and finally the total number of execution plans of the DQL statement is N = N 1 *N 2 *…*N m . The multi-execution plan database will ultimately execute the DQL statement N times to traverse and execute N different execution plans.

[0052] Modification 5: Add a judgment loop between the start and end positions of the input statement processing function. That is, at the end position, first increment the loop count by 1, and then judge the relationship between the current loop count n and the total number of execution plans N. If n < N, it means there are still unexecuted execution plans, and go back to the entry function of the statement processing to re-execute the statement processing flow; if n >= N, it means all execution plans have been executed or multi-execution plans are not enabled, and exit the loop.

[0053] As Figure 3 shown, it is the flowchart for comparing output results, and the specific steps are as follows:

[0054] S201: For the current test statement, obtain the output results and the number of rows of all execution plans, and count the number of execution plans of the current test statement;

[0055] S202: Judge whether the number of execution plans is one. If the number of execution plans is one, it means that the statement is a non-DQL statement, or the statement is a DQL statement but there is only one execution plan, and the test passes; otherwise, execute S203;

[0056] S203: Compare whether the number of output rows of all execution plans is the same. If the number of output results of all execution plans is the same, execute S204; otherwise, it means the test fails and the current statement triggers a logical error in the database;

[0057] S204: Sort the output results of each execution plan by row unit. The sorting order is determined by the magnitude relationship of the values of the data items under the corresponding original encoding type. Since the query statement does not necessarily follow the specified output result order, it is reasonable that the result orders returned by different execution plans are inconsistent. Sorting can facilitate result matching.

[0058] For example, assume the program outputs two rows of data, each row containing three data items. The encoding types of the first two data items in each row are both ASCII, and the encoding type of the third item is floating point. The sorting rule is from smallest to largest. The specific contents of the two rows of data are ("001", "Andy", "85.5") and ("001", "Jim", "90.5"). Since the first data item in both rows is "001", indicating that the two data are equal, the comparison proceeds to the next data item. Since the encoding of the second data item "Andy" is smaller than "Jim", the order of the two rows of data remains the same after sorting.

[0059] S205: Compare the sorted output result of each execution plan with the sorted output result of the first execution plan. If there is any sorted output result of an execution plan that is inconsistent with the sorted output result of the first execution plan, it indicates that the test fails and the current statement triggers a logical error in the database; otherwise, the test passes.

[0060] The following shows an example in a real - world scenario where a logical error in the SQLite database is successfully detected through multi - execution plan prediction in a test case. This test case contains six SQL statements, and only the last statement belongs to the DQL statement, which has four different execution plans. The result of execution plan four of the DQL statement is different from the previous three, indicating that there is at least one logical error among these execution plans. The content of this test case is:

[0061] CREATE TABLE t0(c0 INT);

[0062] CREATE TABLE t1(c1 INT,c2 INT);

[0063] INSERT INTO t0 VALUES(0);

[0064] INSERT INTO t1 VALUES(0,1);

[0065] CREATE INDEX t1_c1 ON t1(c1);

[0066] SELECT*FROM t0 JOIN t1 ON c1=c0 AND c2=c0;

[0067] The following details the specific process of detecting logical errors by inputting this use case into a multi-execution plan database.

[0068] The test case input into the multi-execution plan database contains six SQL statements. The first two statements respectively create tables t0 and t1 in the database. The former has only one column of data c0, and the latter has two columns of data c1 and c2. The third and fourth statements respectively insert data into tables t0 and t1. The fifth statement constructs an index t1_c1 on column c1 of table t1. The last statement is a DQL statement, so the multi-execution plan database will execute all execution plans of this statement.

[0069] This DQL statement has four different execution plans in the SQLite database. Among them, execution plan one is the optimal execution plan of the original database, that is, the execution plan finally selected by the original database for execution. The other three execution plans are non-optimal execution plans and will also be executed in the multi-execution plan database. After the multi-execution plan database finishes executing the four execution plans, the output result comparison module will successively collect the output results of the four execution plans. The output results of the first three execution plans are empty, that is, no data meets the conditions of the query statement. The last execution plan is "(0,0,1)". While obtaining the output results of all execution plans, the output result comparison module will count the number of rows in the output result of each execution plan and the number of execution plans of the DQL statement. Since the number of execution plans of this DQL is greater than 1, it is necessary to perform consistency detection on the results of multiple execution plans of this DQL statement. First, it will compare the number of rows in the output results of the execution plans. Since the number of output rows of execution plan four is 1 while the number of output rows of the first three execution plans is 0, there is an inconsistency. The output result comparison module determines that this statement triggers a logical bug in the database and will save the content of this test case and its execution results and feedback them to the database developer.

[0070] The database developer can reproduce and analyze this logical error through the saved use case. For this use case, the database developer can quickly locate the cause of the program error and fix it by manually analyzing the execution logic of the execution plan that is inconsistent with the other three execution plans. The specific execution logic of the fourth execution plan containing the logical error is as follows:

[0071] 1. Fetch each piece of data in column c0 of table t0. Here, assume the value of the current piece of data is x.

[0072] 2. Query all index IDs with the value of x in the index t1_c1 on table t1, that is, query the index IDs of the data entries in table t1 that satisfy c1 = c0. Then output the values of columns c1 and c2 of the data entries corresponding to the index IDs on table t1.

[0073] 3. Then determine whether the value of c1 in the data entries output in step 2 is equal to x. If they are equal, add this data entry to the output result; otherwise, discard this data entry. Then go back to step 1 to traverse the next data entry in column c0 of table t0.

[0074] The reason for the logical error here is that steps 2 and 3 had optimization errors, resulting in the same judgment and omission of the judgment condition c2 = c0 in the original DQL statement. Specifically, step 2 filtered out the data entries in table t1 that satisfy c1 = c0, and then the same condition filtering of c1 = c0 was performed in step 3. This led to the omission of the condition c2 = c0 in the original DQL statement, ultimately resulting in an incorrect execution result.

[0075] Those of ordinary skill in the art can understand that the above are only preferred examples of the invention and are not used to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, for those skilled in the art, they can still modify the technical solutions described in the foregoing examples or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, etc. made within the spirit and principle of the invention shall be included within the protection scope of the invention.

Claims

1. An automatic database logic error detection system based on multiple execution plans, characterized in that: It includes a multi-execution plan database module and an output result comparison module; The multi-execution plan database module is used to modify the original database, execute all possible execution plans for the DQL statements in the input test cases, and output the execution results of each execution plan; the specific modifications are as follows: Modification 1: Insert a statement type judgment process between "parsing the input statement to generate a query tree" and "analyzing the query tree and generating an execution plan tree": If the statement type of the current execution statement is a DQL statement, enable the multi-execution plan, otherwise disable the multi-execution plan; And initialize the number of execution plans N = 1, and the current loop count n = 0; Modification 2: Before calling the pruning function during the execution of "analyzing the query tree and generating an execution plan tree", add a conditional selection judgment: If the multi-execution plan is disabled, maintain the execution process of the original database, that is, call the original pruning function; If the multi-execution plan is enabled, call the multi-execution plan pruning function; the multi-execution plan pruning function is: do not perform pruning and retain all subtrees to be pruned; Modification 3: Add a conditional selection judgment between "generating all execution plan trees" and "selecting the optimal execution plan tree": If the multi-execution plan is disabled, maintain the original database execution process, that is, call the original execution plan selection function; If the multi-execution plan is enabled, call the multi-execution plan selection function; Modification 4: Add a new execution plan selection function based on the original execution plan selection function; the new execution plan selection function is specifically: First, count and update the total number of execution plans N; Second, select different execution plans according to the current loop count n; Modification 5: Add a judgment loop between the start and end positions of the input statement processing function: That is, at the end position, first increment the loop count by 1, and then judge the relationship between the current loop count n and the total number of execution plans N. If n < N, it means that there are still unexecuted execution plans, and return to the entrance function of statement processing to re-execute the statement processing process; If n >= N, it means that all execution plans have been executed or the multi-execution plan is not enabled, and exit the loop; The output result comparison module is used to obtain and compare the execution results of all execution plans of the current test statement to judge whether there are logical errors in the program; If there are inconsistent execution results, it means that there are logical errors in the database.

2. The automatic database logic error detection system based on multiple execution plans according to claim 1, characterized in that: When the output result comparison module judges whether the execution results are consistent, it specifically includes the following sub-steps: S201: For the current test statement, obtain the output results and the number of rows of all execution plans, and count the number of execution plans of the current test statement; S202: Judge whether the number of execution plans is one. If the number of execution plans is one, it means that the statement is a non-DQL statement, or the statement is a DQL statement but there is only one execution plan, and the test passes; Otherwise, execute S203; S203: Compare whether the number of output rows of all execution plans is the same. If the number of output results of all execution plans is the same, execute S204; Otherwise, it means that the test fails, and the current statement triggers a logical error in the database; S204: Sort the output results of each execution plan by row unit. The sorting order is determined by the magnitude relationship of the values of the data items under the corresponding original encoding type. S205: Compare the sorted output results of each execution plan with the sorted data results of the first execution plan. If there is any inconsistency between the sorted output results of any execution plan and the sorted output results of the first execution plan, it indicates that the test has failed and the current statement has triggered a logical error in the database. Otherwise, the test passes.

3. An automated database logic error detection method based on multiple execution plans, characterized in that: This method is implemented based on the automated database logical error detection system with multiple execution plans described in claim 1, and specifically includes the following steps: Step 1: Make the following modifications to the original database: Modification 1: Insert a statement type judgment process between "parsing the input statement in the original database to generate a query tree" and "analyzing the query tree and generating an execution plan tree": If the statement type of the current execution statement is a DQL statement, enable multiple execution plans; otherwise, disable multiple execution plans. And initialize the number of execution plans N = 1 and the current loop count n = 0. Modification 2: Before calling the pruning function during the execution of "analyzing the query tree and generating an execution plan tree", add a conditional selection judgment: If multiple execution plans are disabled, maintain the original database execution process, that is, call the original pruning function. If multiple execution plans are enabled, call the multiple execution plan pruning function; the multiple execution plan pruning function is: Do not perform pruning and retain all subtrees to be pruned. Modification 3: Add a conditional selection judgment between "generating all execution plan trees" and "selecting the optimal execution plan tree": If multiple execution plans are disabled, maintain the original database execution process, that is, call the original execution plan selection function. If multiple execution plans are enabled, call the multiple execution plan selection function. Modification 4: Add a new execution plan selection function based on the original execution plan selection function; the new execution plan selection function is specifically: First, count and update the total number of execution plans N; second, select different execution plans according to the current loop count n. Modification 5: Add a judgment loop between the start and end positions of the input statement processing function, that is, at the end position, first increment the loop count by 1, and then judge the relationship between the current loop count n and the total number of execution plans N. If n < N, it indicates that there are still unexecuted execution plans, and return to the entrance function of statement processing to re-execute the statement processing flow; if n >= N, it indicates that all execution plans have been executed or multiple execution plans are not enabled, and exit the loop. Step 2: Input the test cases containing DQL statements into the multiple execution plan database and execute them one by one. Determine whether multiple execution plans need to be executed for the current statement according to the type of the statement being executed; among them, non-DQL statements are executed according to the original logic of the database, that is, only executed once; DQL statements are executed with multiple execution plans, that is, generate and retain all possible execution plans, and then execute each execution plan one by one. After the test case is executed, the output result comparison module is called to obtain the output results of all execution plans of the test case and compare the execution results. If there is inconsistency in the execution results, it means that there is a logical error in the database and the test fails.

Images