Automated Testing Method and Device for SQL Statement Execution in Relational Databases

The automated testing method for SQL statements in relational databases addresses the inability to detect UPDATE and DELETE logical errors by generating and analyzing execution results, ensuring consistent execution strategies and predicate adherence, thus enhancing error detection across different databases.

CN115344500BActive Publication Date: 2025-07-15INST OF SOFTWARE - CHINESE ACAD OF SCI
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202211046253.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-08-30
Publication Date
2025-07-15
Estimated Expiration
2042-08-30

AI Technical Summary

Technical Problem

Existing methods cannot effectively detect logical errors in UPDATE and DELETE statements in relational databases, especially because different database systems adopt different execution strategies, which increases detection difficulty.

Method used

By randomly generating a SQL statement group containing the same predicate, the target database is executed and analyzed, and the database's execution strategy is used to judge logical errors, including generating data tables, filling data, generating SQL statement groups, obtaining execution results and analyzing whether the results are in compliance with the database policy.

Benefits of technology

It realizes logical error detection of all predicated SQL statements in relational databases, especially UPDATE and DELETE statements, improving the comprehensiveness and accuracy of detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115344500B_ABST
    Figure CN115344500B_ABST
Patent Text Reader

Abstract

The present invention discloses an automated testing method and apparatus for SQL statement execution in a relational database, relating to the field of software technology. The method includes: for a target relational database, constructing at least one data table based on SQL statements for creating data tables and populating data to obtain a target database; generating target data tables; generating a group of SQL statements for testing the target database; wherein the target data table is one data table or multiple data tables joined by JOIN or multiple data tables joined by commas; the group of SQL statements is composed of SELECT, UPDATE, and DELETE statements that contain the same predicate and operate on the same target data table; obtaining the execution result of each SQL statement in the group of SQL statements in the target relational database; and obtaining a test result by analyzing whether the execution result conforms to the SQL statement execution strategy of the target relational database. The present invention supports detecting logical errors in all SQL statements containing predicates.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of software, and particularly relates to an automated test method and device for SQL statement execution in a relational database. Background Art

[0002] Database Management System (DBMS) provides efficient and convenient data storage services for many fields where security is crucial, such as aviation, finance, and logistics. Currently, the mainstream database type is the relational database, such as MySQL, MariaDB, and SQLite. The relational database is based on the relational model and stores data in the form of tables, and queries and operates on data through Structured Query Language (SQL).

[0003] Relational databases face various problems, such as system crashes and logic bugs. Logic bugs occurring in different SQL statements can cause different serious consequences. When a query statement (such as a SELECT statement) has a logic bug, the database system will return incorrect query results. When a data modification statement (such as UPDATE and DELETE statements) has a logic bug, the database system will enter an incorrect database state.

[0004] There are some existing tools for detecting logical errors in database systems. RAGS (Donald R. Slutz, “Massive Stochastic Testing of SQL”. In Proceedings of International Conference on Very Large Data Bases (VLDB), 1998.) detects logical errors by inputting a SELECT statement into multiple database systems and then observing the differences in their outputs. Pivoted Query Synthesis (PQS) (Manuel Rigger and Zhendong Su, “Testing Database Engines via Pivoted Query Synthesis”. In Proceedings of USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2020.) detects logical errors in the target database system by synthesizing a SELECT statement that returns specified rows of data. Non-optimization Reference Engine Construction (NoREC) (Manuel Rigger and Zhendong Su, “Detecting Optimization Bugs in Database Engines via Non-Optimizing Reference Engine Construction”. In Proceedings of ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC / FSE), 2020.) rewrites a SELECT statement into an equivalent SELECT statement that the database cannot optimize, and the two SELECT statements should return the same result.Ternary Logic Partitioning (TLP) (Manuel Rigger and Zhendong Su. “Finding Bugs in Database Systems via Query Partitioning”. In Proceedings of ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA). 2020.) splits a SELECT statement into three SELECT statements according to the predicate results of the original SELECT statement, and the union of the return results of these three statements is the same as that of the original SELECT statement.

[0005] Although logical errors occurring in UPDATE and DELETE statements may cause more serious consequences, existing methods cannot detect such logical errors. Detecting statement errors in UPDATE and DELETE statements requires constructing an effective test oracle to determine whether the UPDATE and DELETE statements are executed correctly. SELECT, UPDATE, and DELETE statements all support predicate filtering operations on data. For the same predicate, the database needs to specify the same operation scope regardless of the type of statement (SELECT, UPDATE, or DELETE).

[0006] Different database systems adopt different SQL statement execution strategies. Especially when an exception occurs during execution, different SQL statements may exhibit different execution behaviors in different databases. Therefore, the execution of an SQL statement needs to consider both its execution result (the return result of a SELECT statement, the content of the data table after the execution of UPDATE and DELETE statements) and whether an exception occurs during the execution process.

[0007] In summary, existing methods cannot detect logical errors caused by UPDATE and DELETE statements. SELECT, UPDATE, and DELETE statements all support predicates. Predicates and SQL statement execution strategies can help detect logical errors in SELECT, UPDATE, and DELETE statements. Summary of the Invention

[0008] The object of the present invention is to solve the problem that the existing methods cannot solve the logical errors in the detection of UPDATE and DELETE statements, and to provide an automated testing method and device for the execution of SQL statements in a relational database, which randomly generates a set of SQL statements containing the same predicates, analyzes the execution results of the database, and then detects the logical errors of the SQL statements. This method is applicable to all SQL statements containing predicates, such as SELECT, UPDATE, and DELETE statements.

[0009] The technical solution of the present invention includes:

[0010] An automated testing method for the execution of SQL statements in a relational database, the steps of which include:

[0011] For a target relational database, at least one data table is constructed based on SQL statements for creating data tables and populating data, so as to obtain a target database; wherein, the columns of the data table include: a column rowId for identifying each row modification and a column updated for recording the modification of the UPDATE statement;

[0012] Generate a group of SQL statements for testing the target database; wherein, the group of SQL statements is composed of SELECT, UPDATE, and DELETE statements that contain the same predicates and operate on the same target;

[0013] Obtain the execution results of each SQL statement in the group of SQL statements in the target relational database; wherein, the execution results include: the rows affected by the SQL statement and the exceptions thrown by the SQL statement;

[0014] Obtain the test results by analyzing whether the execution results conform to the SQL statement execution strategy of the target relational database.

[0015] Further, the constructing at least one data table based on SQL statements for creating data tables and populating data to obtain a target database includes:

[0016] Randomly create at least one data table using the CREATE TABLE statement; wherein, each data table contains a random number of columns, and each column is assigned a random type and data constraint;

[0017] Use the INSERT statement to populate each data table with random data to obtain the data table;

[0018] Construct a target database based on at least one of the data tables

[0019] Further, after using the INSERT statement to populate each data table with random data to obtain the data table, it further includes:

[0020] Modify the data table using the ALTER TABLE and CREATE INDEX statements.

[0021] Furthermore, the generation of the SQL statement group for testing the target database includes:

[0022] Select at least one data table in the target database as the target data table τ; wherein, the target data table τ is a single data table or multiple data tables joined by JOIN or multiple data tables joined by commas;

[0023] Generate a predicate φ based on the target data table τ;

[0024] Generate keywords for the SQL statements; wherein, the keywords are supported by at least two of the SELECT statement, the UPDATE statement, and the DELETE statement;

[0025] Generate other content of the SQL statements; wherein, the other content includes: the query content of the SELECT statement, the modification content of the UPDATE statement, or the deletion content of the DELETE statement;

[0026] Based on the predicate The keywords and the other content, generate SQL statements.

[0027] Furthermore, the generation of the predicate φ based on the target data table τ includes:

[0028] Generate different types of operation trees according to the operations supported by the target data table τ and the number of parameters of the functions;

[0029] Obtain the parameters of the operation tree;

[0030] Generate an abstract syntax tree based on the operation tree; wherein, after the abstract syntax tree reaches a specified depth, generate leaf nodes;

[0031] Obtain the predicate according to the column index corresponding to the leaf node and the type of the operation tree

[0032] Furthermore, the obtaining of the execution result of each SQL statement in the target database includes:

[0033] When the SQL statement is a SELECT statement, add the column rowId after the query content of the SELECT statement, and execute the SELECT statement to obtain the rows row affected by the SELECT statement s ;

[0034] When the SQL statement is an UPDATE statement, add the column "updated" after the modified content of the UPDATE statement, execute the UPDATE statement, and obtain the rows modified by the UPDATE statement through a SELECT statement u ;

[0035] When the SQL statement is a DELETE statement, before executing the DELETE statement, query the value of the column "rowId" in the target data table, and after executing the DELETE statement, query the value of the column "rowId" in the target data table again to obtain the rows modified by the DELETE statement d ;

[0036] When an exception occurs during the execution of the SQL statement, record the exception data; wherein, the exception data includes: the level of the exception, the error code of the exception, and the error message of the exception, and the level of the exception includes: warning or error;

[0037] Based on the execution situation of each SQL statement in the SQL statement group, obtain the rows affected by the SQL statement and / or the exceptions thrown by the SQL statement

[0038] Further, obtaining the test result by analyzing whether the execution result conforms to the SQL statement execution strategy of the target relational database includes:

[0039] When the exception thrown by the SQL statement is a warning occurred in the SELECT statement, judge whether a logical error occurred in the execution of the SQL statement based on the first SQL statement execution strategy; wherein, the first SQL statement execution strategy includes:

[0040] When the target relational database is in strict mode, UPDATE statements and DELETE statements with the same predicates throw errors and the errors have the same error code and error message as the warning occurred in the SELECT statement, and UPDATE and DELETE statements with the same predicates do not modify any rows in the target database;

[0041] When the target relational database is in non-strict mode, UPDATE and DELETE statements with the same predicates throw the warning occurred in the SELECT statement and affect the same rows in the target database;

[0042] In the case where the exception thrown by the SQL statement is an error occurring in the SELECT statement, determine whether a logical error has occurred in the execution of the SQL statement based on the second SQL statement execution strategy; wherein, the second SQL statement execution strategy includes: the SELECT statement and UPDATE and DELETE statements with the same predicate do not affect any row in the target database, and UPDATE and DELETE statements with the same predicate throw the same error;

[0043] In the case where the exception thrown by the SQL statement does not include a warning or error occurring in the SELECT statement, determine whether a logical error has occurred in the execution of the SQL statement based on the third SQL statement execution strategy; wherein, the third SQL statement execution strategy includes: the SELECT statement and UPDATE and DELETE statements with the same predicate affect the same rows in the target database;

[0044] In the case where the exception thrown by the SQL statement does not include a specific exception occurring in the UPDATE and DELETE statements, determine whether a logical error has occurred when comparing the thrown exception based on the fourth SQL statement execution strategy, and determine whether a logical error has occurred when comparing the affected rows based on the fifth SQL statement execution strategy; wherein,

[0045] the specific exception includes an exception generated when the UPDATE and DELETE statements violate the constraints of the data table. For example, when the UPDATE statement updates the primary key to a value that exists in another data table, an exception violating the primary key will be thrown because the primary key does not allow duplicate values. For example, when the DELETE statement deletes a column referenced by other columns, an exception violating the foreign key will be thrown because the foreign key needs to ensure the existence of the referenced column.

[0046] The fourth SQL statement execution strategy includes:

[0047] In the case where the target relational database is in strict mode, if the SELECT statement throws a warning, UPDATE and DELETE statements with the same predicate throw an error and the error has the same error code and error message as the warning occurring in the SELECT statement;

[0048] In the case where the target relational database is in strict mode, if the SELECT statement throws an error, UPDATE and DELETE statements with the same predicate throw the error occurring in the SELECT statement;

[0049] In the case where the target relational database is in non - strict mode, the SELECT statement and the UPDATE and DELETE statements with the same predicates throw the same exception;

[0050] In the case where the target relational database is in strict mode or not, if the SELECT statement does not throw an exception, the UPDATE and DELETE statements with the same predicates do not throw an exception;

[0051] The fifth SQL statement execution strategy includes:

[0052] In the case where the target relational database is in strict mode, if the SELECT statement throws an exception, the columns row u and column row d are empty sets;

[0053] In the case where the target relational database is in strict mode, if the SELECT statement does not throw an exception, the column row s the column row u and the column row d are the same;

[0054] In the case where the target relational database is in non - strict mode, the column row s the column row u and the column row d are the same.

[0055] Furthermore, the attributes of the data in the columns of the target data table include: data type and data constraint.

[0056] A storage medium stores a computer program, wherein the computer program is configured to execute any of the above - mentioned methods when running.

[0057] An electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute any of the above - mentioned methods.

[0058] Compared with the prior art, the present invention has the following technical advantages:

[0059] 1. The present invention proposes a brand - new method to detect logical errors in SQL statements, solving the problem that the existing methods cannot detect logical errors in UPDATE and DELETE statements.

[0060] 2. The present invention proposes a general method for detecting logical errors in SQL statements, which supports the detection of all SQL statements that support predicates, including but not limited to SELECT, UPDATE, and DELETE statements. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 An example diagram of the overall process of the method of the present invention.

[0062] Figure 2 An example diagram of the SQL statement execution strategies in different database systems. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0063] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Apparently, the described embodiments are only specific embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0064] The technical solution of the present invention includes an automated testing method for SQL statement execution in a relational database. In this automated testing method, first, for the target relational database, test inputs are constructed, where the test inputs include: a set of SQL statements for creating data tables and a set of test SQL statements. The set of SQL statements for creating data tables creates at least one data table in the target relational database, and the set of test SQL statements is composed of SELECT, UPDATE, and DELETE statements that contain the same predicate and operate on the same target data table. Then, based on the execution results of the input set of SQL statements, analysis is performed according to the SQL statement execution strategy of the target relational database to determine whether a logical error has occurred in the database. The execution results of the SQL statements include: the return result of the SELECT statement, the database state (the modified data table) after the execution of the UPDATE and DELETE statements, and the exception information that occurs. Finally, if a logical error occurs, an error report is generated, and its content includes the test inputs (data tables and a set of SQL statements composed of SELECT, UPDATE, and DELETE) and the specific SQL statement execution strategy violated. The execution strategy of the target database SQL statement describes the execution behavior of the SQL statement, especially the statement execution behavior when an exception occurs.

[0065] Specifically, the automated testing method of the present invention is as Figure 1 shown and includes:

[0066] (1) Database generation. Generate a database instance containing multiple data tables in the target database system. This stage follows the following steps:

[0067] Step 1 Use the CREATE TABLE statement to randomly create multiple data tables, where each data table contains a random number of columns, and each column is assigned a random type (such as INT, CHAR) and data constraint (such as PRIMARY KEY, UNIQUE).

[0068] Step 2 Use the INSERT statement to fill each data table with random data.

[0069] Step 3 Use the ALTER TABLE and CREATE INDEX statements to modify the data tables, such as adding new columns or creating new indexes.

[0070] (2) SQL statement generation. Based on the generated data tables, randomly generate a set of SQL statements, which include SELECT, UPDATE, and DELETE statements that operate on the same data tables and have the same predicates. This stage follows the following steps:

[0071] Step 1 Select some data tables in the database as the target data tables τ to generate statements. The target data table is a single data table or multiple data tables joined by JOIN or multiple data tables joined by commas.

[0072] Step 2 After selecting the target data tables, generate predicates based on the Abstract Syntax Tree (AST) Among them, according to the operations supported by the database and the number of parameters of the functions, different types of operation trees are divided. For example, a unary operator tree accepts one operand, and a binary operator tree accepts two operands. During the generation process, a type of operation tree is randomly selected, and then an instance of the operation tree is generated. Then the parameters are generated. The parameters include other operation trees and constants, such as strings, numbers, and column indexes. Each time an instance of the operation tree is generated, the depth of the abstract syntax tree composed of the generated operation trees increases by one. When the abstract syntax tree reaches the specified depth, leaf nodes (constants) are generated. For example, to generate an abstract syntax tree with a depth of 1, first randomly select a type of operation tree. For example, a unary operation tree, the NOT operation is a unary operation tree and requires 1 parameter. Since the specified generation depth is 1, at this time, leaf nodes are generated. For example, it is the column index c1, then the finally generated predicate is NOT c1. For example, to generate an abstract syntax tree with a depth of 2, first randomly select a type of operation tree. For example, a unary operation tree NOT, which requires 1 parameter. At this time, the depth of the abstract syntax tree is 1 and has not reached the specified generation depth. The selected parameter type is a randomly selected type of operation tree. For example, the selected parameters are all binary operation trees greater than (>). Then generate the two parameters required by the greater than operation tree. Since the depth of the abstract syntax tree reaches the execution generation depth at this time, two leaf nodes are generated respectively. For example, the column index c1 and the number 10, then the finally generated predicate is NOT(c1>10).

[0073] Step 3 generates the keywords of the SQL statement. Among them, the generated keywords are supported by at least two types of statements. For example, only the SELECT statement supports DISTINCT, so DISTINCT will not be generated.

[0074] Step 4 generates the other parts of the SQL statement, that is, the query content of the SELECT statement and the modification content of the UPDATE statement. The query content of SELECT includes column names (such as c0), expressions related to columns (such as c0 + 1), but does not support aggregation operations (such as SUM(c0)). The modification content of the UPDATE statement is SET column = constant.

[0075] (3) Execute the generated SQL statement to obtain the execution result. It includes the rows returned by the SELECT statement, the rows modified by the UPDATE and DELETE statements, and the exceptions thrown by the SELECT, UPDATE, and DELETE statements. The present invention introduces two additional columns to respectively represent each row and record the modifications of the UPDATE statement. For example, the first row is identified by the value r1 of the column rowId. If it is modified by UPDATE, the updated column among them is modified to true. This stage follows the following steps:

[0076] Step 1: Obtain the rows returned by the SELECT statement. First, add the column rowId to the query content of the SELECT statement and then execute it. The execution result of the SELECT statement contains the identifiers of the affected rows. The rows affected by the SELECT statement are denoted as row s 。

[0077] Step 2: Obtain the rows modified by the UPDATE statement. First, add the column updated to the modification content of the UPDATE statement (SET updated = true) and then execute it. The execution result of the UPDATE statement will modify the updated column of the rows that meet the predicate to true. Finally, query all the rows with the updated column being true through the SELECT statement, which are the rows modified by the UPDATE statement and are denoted as row u 。

[0078] Step 3: Obtain the rows modified by the DELETE statement. Before executing the DELETE statement, query the values of the column rowId in the data table. After executing the DELETE statement, query the values of the column rowId in the data table again. The difference between the two sets is the rows modified by the DELETE statement and is denoted as row d 。

[0079] Note: When an exception occurs during the execution of the SQL statement, the present invention will also record the occurred exception, including the level of the exception, the error code of the exception, and the error message of the exception. The level of the exception is divided into warning or error.

[0080] (4) Analysis of the execution result. Analyze the received execution result (the rows affected by the SQL statement and the thrown exception) according to the SQL execution strategy of the target relational database.

[0081] Exceptions are divided into warnings and errors. When a warning occurs, the SQL statement will continue to execute, and the database system will perform approximate processing on the rows that cause the warning and recalculate whether they meet the predicate. When an error occurs, the SQL statement will stop and roll back. Specifically, the SELECT statement returns an empty set, and the UPDATE and DELETE statements will not modify the content of the data table.

[0082] Figure 2 Shows the SQL execution strategies in MySQL, MariaDB, and TiDB when an exception occurs. When a warning occurs in the SELECT statement, if the database system is in strict mode, the UPDATE and DELETE statements with the same predicate will throw an error, and the result has the same predicate The UPDATE and DELETE statements do not modify any rows. If the database system is in non-strict mode, the UPDATE and DELETE statements will throw the same warning. Eventually, the SELECT, UPDATE, and DELETE statements will affect the same rows, that is, the rows returned by the SELECT statement will be modified by the UPDATE and DELETE statements. When the SELECT statement throws an error, whether the database system is in strict mode or not, the UPDATE and DELETE statements will throw an error, and as a result, the SELECT, UPDATE, and DELETE statements will not affect any rows. Additionally, when no exception occurs, SELECT, UPDATE, and DELETE statements with the same predicate will affect the same rows.

[0083] Since SQL statements are randomly generated, when the UPDATE and DELETE statements violate the constraints of the table, specific exceptions for the UPDATE and DELETE statements will occur. For example, when the UPDATE modifies a column with a primary key constraint, if the modified value already exists in the data table, an exception for violating the primary key constraint will occur. If the DELETE deletes a referenced column, an exception for violating the foreign key constraint will occur. Because the SELECT statement does not throw the specific exceptions of the UPDATE and DELETE statements, when these specific exceptions occur, the exceptions occurring in the SELECT statement will not be compared.

[0084] When the specific exceptions of the UPDATE and DELETE statements do not occur, the following comparison rules will be applied. The exceptions thrown by this comparison are

[0085] · If the target database is in strict mode and the SELECT statement throws a warning, the UPDATE and DELETE statements should throw an error, and have the same error code and error message.

[0086] · If the target database is in strict mode and the SELECT statement throws an error, the UPDATE and DELETE statements should throw the same error.

[0087] · If the target database is in non-strict mode, the SELECT, UPDATE, and DELETE statements should throw the same exception, including the same error level, error code, and error message.

[0088] When comparing the affected rows

[0089] · If the target database is in strict mode and the SELECT statement throws an exception, row u and row dshould be an empty set. If the SELECT statement does not throw an exception, row s , row u and row d should be the same.

[0090] · The target database is in non-strict mode, row s , row u and row d should be the same.

[0091] If the execution result of the SQL statement does not conform to the execution policy described by the target database system, a logical error may occur in the target database system.

[0092] Although the specific implementation process and example drawings of the present invention are disclosed for illustrative purposes, and the purpose is to help understand the content of the present invention and implement it accordingly, those skilled in the art can understand that: without departing from the spirit and scope of the present invention and the appended claims, various substitutions, changes, and modifications are possible. Therefore, the present invention should not be limited to the content disclosed in the shown implementation process and example drawings.

Claims

1. An automated testing method for SQL statement execution in a relational database, the steps of which include: For a target relational database, at least one data table is constructed based on SQL statements for creating data tables and populating data to obtain a target database; wherein, the columns of the data table include: a column rowId for identifying each row modification and a column updated for recording UPDATE statement modifications; Generate a group of SQL statements for testing the target database; wherein, the group of SQL statements is composed of SELECT, UPDATE, and DELETE statements that contain the same predicate and operate on the same target data table; Obtain the execution result of each SQL statement in the group of SQL statements in the target relational database; wherein, the execution result includes: the rows affected by the SQL statement and the exceptions thrown by the SQL statement; Obtain a test result by analyzing whether the execution result conforms to the SQL statement execution strategy of the target relational database.

2. The method according to claim 1, characterized in that, The constructing at least one data table based on SQL statements for creating data tables and populating data to obtain a target database includes: Randomly create at least one data table using the CREATE TABLE statement; wherein, each data table contains a random number of columns, and each column is assigned a random type and data constraint; Use the INSERT statement to populate each data table with random data to obtain the data table; Construct a target database based on at least one of the data tables.

3. The method according to claim 2, characterized in that After using the INSERT statement to populate each data table with random data to obtain the data table, it further includes: Modify the data table using the ALTER TABLE and CREATE INDEX statements.

4. The method according to claim 1, characterized in that, The generating a group of SQL statements for testing the target database includes: Select at least one data table in the target database as a target data table τ; wherein, the target data table τ is a single data table or multiple data tables joined by JOIN or multiple data tables joined by commas; Generate a predicate φ based on the target data table τ; Generate keywords for SQL statements; wherein, the keywords are supported by at least two of the SELECT statement, the UPDATE statement, and the DELETE statement; Generate other content of SQL statements; wherein, the other content includes: the query content of the SELECT statement, the modification content of the UPDATE statement, or the deletion content of the DELETE statement; Based on the predicate Generate an SQL statement based on the keyword and the other content.

5. The method according to claim 4, wherein The generating a predicate φ based on the target data table τ includes: Generate different types of operation trees according to the operations supported by the target data table τ and the number of parameters of functions; Obtain the parameters of the operation tree; Generate an abstract syntax tree based on the operation tree; wherein, leaf nodes are generated after the abstract syntax tree reaches a specified depth; Obtain the predicate according to the constant corresponding to the leaf node and the type of the operation tree Wherein, the constants include: column index, string, and number.

6. The method according to claim 1, wherein The obtaining the execution result of each SQL statement in the target database includes: In the case where the SQL statement is a SELECT statement, add the column rowId after the query content of the SELECT statement, and then execute the SELECT statement to obtain the rows row affected by the SELECT statement s ; In the case where the SQL statement is an UPDATE statement, add the column updated after the modification content of the UPDATE statement, execute the UPDATE statement, and obtain the rows row modified by the UPDATE statement through a SELECT statement u ; In the case where the SQL statement is a DELETE statement, before executing the DELETE statement, query the value of the column rowId in the target data table, and after executing the DELETE statement, query the value of the column rowId in the target data table again to obtain the row row modified by the DELETE statement d ; When an exception occurs during the execution of the SQL statement, record the exception data; wherein, the exception data includes: the level of the exception, the error code of the exception, and the error message of the exception, and the level of the exception includes: warning or error; Based on the execution status of each SQL statement in the SQL statement group, obtain the rows affected by the SQL statement and / or the exceptions thrown by the SQL statement.

7. The method according to claim 6, characterized in that, The test result is obtained by analyzing whether the execution result conforms to the SQL statement execution strategy of the target relational database, including: When the exception thrown by the SQL statement is a warning generated by the SELECT statement, determine whether a logical error has occurred in the execution of the SQL statement based on the first SQL statement execution strategy; wherein, the first SQL statement execution strategy includes: The target relational database is in strict mode, and UPDATE and DELETE statements with the same predicates throw an error, and the error has the same error code and error message as the warning that occurs in the SELECT statement, and UPDATE and DELETE statements with the same predicates do not modify any row in the target database; The target relational database is in non-strict mode, and UPDATE and DELETE statements with the same predicate throw the warnings generated by the SELECT statement and affect the same rows in the target database; When the exception thrown by the SQL statement is an error in the SELECT statement, determine whether a logical error has occurred in the execution of the SQL statement based on the second SQL statement execution strategy; wherein, the second SQL statement execution strategy includes: the SELECT statement and the UPDATE and DELETE statements with the same predicates do not affect any row in the target database, and the UPDATE and DELETE statements with the same predicates throw the same error; When the exception thrown by the SQL statement does not include a warning or error occurring in the SELECT statement, determine whether a logical error has occurred in the execution of the SQL statement based on a third SQL statement execution policy; wherein, the third SQL statement execution policy includes: the SELECT statement and UPDATE and DELETE statements with the same predicates affect the same rows in the target database; When the exception thrown by the SQL statement does not include specific exceptions for UPDATE and DELETE statements, determine whether a logical error has occurred when comparing the thrown exception based on the fourth SQL statement execution strategy, and determine whether a logical error has occurred when comparing the affected rows based on the fifth SQL statement execution strategy; wherein, The specific exception includes an exception generated when the UPDATE and DELETE statements violate the constraints of the data table; The fourth SQL statement execution strategy includes: In the case where the target relational database is in strict mode, if a warning is thrown by a SELECT statement, UPDATE and DELETE statements with the same predicate throw an error and the error has the same error code and error message as the warning that occurred in the SELECT statement; In the case where the target relational database is in strict mode, if a SELECT statement throws an error, UPDATE and DELETE statements with the same predicate throw the error that occurred in the SELECT statement; When the target relational database is in non-strict mode, the SELECT statement and UPDATE and DELETE statements with the same predicates throw the same exception; In the case where the target relational database is in strict mode or not, if the SELECT statement does not throw an exception, UPDATE and DELETE statements with the same predicate will not throw an exception; The fifth SQL statement execution strategy includes: In the case where the target relational database is in strict mode, if an exception is thrown by the SELECT statement, the column row u and the column row d are empty sets; When the target relational database is in strict mode, if the SELECT statement does not throw an exception, the column row s 、the column row u and the column row d are the same; When the target relational database is in non-strict mode, the column row s is the same as the column row u and the column row d ​ 8. The method according to claim 1, wherein The attributes of the data in the columns of the target data table include: data type and data constraint.

9. A storage medium storing a computer program, wherein, The computer program is set to execute any one of the methods recited in claims 1-8 when running.

10. An electronic device, characterized in that, It includes a memory and a processor, a computer program is stored in the memory, and the processor is set to run the computer program to execute any one of the methods recited in claims 1-8.