Method and apparatus for testing a database

Abstract

The present disclosure discloses a method and apparatus for testing a database. The database includes a first data table, the first data table includes one or more first data groups associated with transactions, the first data group includes one or more rows of data, the data in the first data group satisfies a first data rule, and the method includes: performing one or more transaction operations to update the data in the first data table, wherein the transaction operations are transaction operations for the data within the first data group, and the transaction operations do not change the first data rule of the first data group; sending a query language to the updated first data table to obtain a query result; and verifying the query result according to the first data rule.

Description

Technical Field

[0001] The present disclosure relates to the technical field of database testing, and particularly to a method and device for testing a database Background Art

[0002] Testing a database is an important means to ensure the quality of the database. However, in the prior art, it is difficult to implement the correctness testing of the database. With the advent of the big data era, there is an urgent need for a method for testing the correctness of the database Summary of the Invention

[0003] In view of this, the present disclosure provides a method and device for testing a database to solve the problem that it is difficult to implement the correctness testing of the database in the prior art

[0004] In a first aspect, a method for testing a database is provided. The database includes a first data table, the first data table includes one or more first data groups associated with transactions, the first data group includes one or more rows of data, and the data in the first data group satisfies a first data rule. The method includes: performing one or more transaction operations to update the data in the first data table, where the transaction operation is a transaction operation for the data within the first data group, and the transaction operation does not change the first data rule of the first data group; sending a query language to the updated first data table to obtain a query result; and verifying the query result according to the first data rule

[0005] Optionally, the transaction operation includes parallel transaction operations for the same first data group

[0006] Optionally, one or more first data groups associated with transactions in the first data table form a second data group, the first data table includes one or more second data groups, and the data in the second data group satisfies a second data rule. The verifying the query result according to the first data rule includes

[0007] Verifying the query result according to the first data rule and / or the second data rule

[0008] Optionally, the first data rule is used to constrain one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data group

[0009] Optionally, the second data rule is used to constrain the number of first data groups in the second data group

[0010] Optionally, when performing the one or more transaction operations and / or sending the query language to the updated first data table, insert the first data group into the first data table

[0011] Optionally, sending a query language to the updated first data table to obtain a query result includes: sending a query language to the updated first data table according to a test case; validating the query result according to the first data rule includes: validating the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule.

[0012] Optionally, validating the query result according to the first data rule and / or the second data rule includes: validating the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule and / or the second data rule.

[0013] A second aspect provides an apparatus for testing a database. The database includes a first data table, the first data table includes one or more first data groups associated with transactions, each first data group includes one or more rows of data, and the data in the first data group satisfies a first data rule. The apparatus includes: an update unit configured to perform one or more transaction operations to update the data in the first data table, where the transaction operation is a transaction operation on the data within the first data group, and the transaction operation does not change the first data rule of the first data group; a query unit configured to send a query language to the updated first data table to obtain a query result; and a validation unit configured to validate the query result according to the first data rule.

[0014] Optionally, the transaction operation includes parallel transaction operations on the same first data group.

[0015] Optionally, one or more first data groups associated with transactions in the first data table form a second data group, the first data table includes one or more second data groups, the data in the second data group satisfies a second data rule, and when validating the query result according to the first data rule, the validation unit is further configured to validate the query result according to the first data rule and / or the second data rule.

[0016] Optionally, the first data rule is used to constrain one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data group.

[0017] Optionally, the second data rule is used to constrain the number of first data groups in the second data group.

[0018] Optionally, the apparatus further includes a data insertion unit configured to insert the first data group into the first data table when performing the one or more transaction operations and when sending a query language to the updated first data table.

[0019] Optionally, sending a query language to the updated first data table to obtain a query result includes: sending a query language to the updated first data table according to a test case; validating the query result according to the first data rule includes: validating the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule.

[0020] Optionally, validating the query result according to the first data rule and / or the second data rule includes: validating the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule and / or the second data rule.

[0021] A third aspect provides an apparatus for testing a database, including a memory and a processor, where the memory is used to store code, and the processor is used to call the code in the memory to execute the method as described in the first aspect.

[0022] A fourth aspect provides a computer-readable storage medium, on which executable code is stored, and when the executable code is executed, it can implement the method as described in the first aspect.

[0023] A fifth aspect provides a computer program product, including executable code, and when the executable code is executed, it can implement the method as described in the first aspect.

[0024] The method for testing a database provided by the embodiments of the present disclosure can perform transaction operations on a data group, the data in the data group satisfies a fixed data rule, and the transaction operation will not change the fixed data rule. Therefore, the result of the transaction operation is predictable. By validating the predictable result of the transaction operation, the correctness test of the database is realized. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is a schematic flowchart of a method for testing a database provided by the embodiments of the present disclosure.

[0026] Figure 2 It is a schematic diagram of a method for testing a database provided by the embodiments of the present disclosure.

[0027] Figure 3 It is a schematic structural diagram of an apparatus for testing a database provided by the embodiments of the present disclosure.

[0028] Figure 4 This is a structural schematic diagram of another device for testing a database provided by an embodiment of the present disclosure. Detailed implementation manners

[0029] The technical solutions in the embodiments of the present disclosure will be clearly and completely described below. Apparently, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments.

[0030] A transaction is also called a database transaction. A transaction can be an execution unit that accesses and may update various data items in a database. An operation sequence of reading or writing to the database can be included in a transaction. In some embodiments, a transaction can include one or more database query languages. For example, a transaction can include one or more structured query language (SQL) statements. To ensure the correct execution of a database transaction, the database transaction should have atomicity, consistency, isolation, and durability. Among them, the atomicity of a transaction can represent the indivisibility of the transaction. For example, the operations in the transaction are either all executed or all not executed; the consistency of the transaction can represent that the transaction must change the database from one consistent state to another consistent state; the isolation of the transaction can represent that the operations between transactions are isolated from each other and do not interfere with each other; the durability of the transaction can represent that the operations on the database by the transaction are permanent.

[0031] Ensuring the correctness of the database is an important issue to be considered during database design. The correctness of the database can include the correctness of transactions and the correctness of database query results. Among them, the correctness of a transaction can be, for example, the correctness of the database data after the transaction is executed. It is possible to check whether the transaction meets the atomicity, consistency, isolation, and durability mentioned above through testing the database to check the correctness of the transaction. The correctness test of the database can also include the verification of the transaction isolation level and the correctness verification of the database query results. That is to say, the isolation level of the transactions in the database and the correctness of the query results can also be verified through testing the database. The correctness of the database query results can be, for example, the correctness of the results of the query language. The query language can include, for example, complex SQL queries, large data volume queries, and different SQL function queries, etc.

[0032] Database correctness testing can be divided into white-box testing and black-box testing. White-box testing can verify the correctness of the database when the internal structure and working logic of the database are known. Black-box testing can verify the correctness of the database without caring about the internal structure of the database, by verifying the input and output of the database. When performing database correctness testing, preset test cases can be used for testing. The test cases can be constructed under the known database structure. The test cases can include, for example, test objectives, test statements, and expected results. The test statements can be, for example, SQL statements. In some embodiments, the correctness of the database can be determined by comparing the test results of the test cases with the preset results.

[0033] There may be multiple concurrently executing transactions in the database system at the same time. For example, in a distributed database, multiple users concurrently perform data read and write operations on the database. Multiple concurrent transactions can be, for example, multiple users writing data to the database at the same time, or multiple users performing read and write operations on the database. Concurrent transactions may cause data errors such as data loss, dirty reads, non-repeatable reads, and phantom reads in the database. The prior art provides various concurrent transaction control mechanisms to ensure the correctness of the database under concurrent transactions. In the database testing stage, it is necessary to perform database correctness testing under concurrent transactions to verify the correctness of the database design.

[0034] However, in the prior art, there is no test method for the correctness of databases. Especially in the case of concurrent transactions, the current database test tool software and test frameworks in the industry do not have the function of verifying the data correctness under concurrent read and write operations of databases. For example, the Jepsen test framework can perform performance tests on distributed systems, but it cannot test databases. Moreover, this test framework mainly verifies the correctness of distributed systems in the case of distributed device failures. And this test framework does not support the function of verifying the correctness of databases under concurrent transactions, nor does it have the correctness verification for the database query function. For example, this test framework does not support the correctness verification of databases and SQL functions under concurrent read and write operations. Another example is that the sysbench test tool can be used to test the performance of databases and has the function of concurrently reading and writing databases. For example, under concurrent conditions, it can test performance parameters such as the number of reads per second, the number of writes per second, the number of transaction operations, the time consumption, and the response time of the database. However, this test method does not have the function of testing the correctness of databases. Another example is the BenchmarkSQL open-source database test tool, which can have a method for verifying the transaction capabilities in TPCC. It can mainly simulate a business scenario of a warehousing and logistics operation, including five transaction operations: creating an order, making a payment, shipping, querying an order, and querying inventory. In this test method, the executed transactions are relatively simple, and it does not have the correctness test for database queries, nor is it convenient to add transactions and SQL scenarios.

[0035] This is because, in the prior art, the method of testing the correctness of databases usually involves comparing whether the execution results of database transactions are consistent with the expected results. In some implementations, the same transaction can be executed in multiple identical databases to verify the correctness of the databases. In some other embodiments, the correctness of databases can be tested through pre-constructed test cases, and the correctness of the test results is compared with the expected results to verify the correctness of the databases. However, in the prior art, the results of transaction operations are unpredictable. Especially in the case of concurrent transactions, the execution order and execution results of concurrent conflicting transactions in the database are unknown. At the same time, in order to achieve more comprehensive test coverage, a large number of test cases that meet different database types need to be constructed, which requires a large amount of manpower and material resources. In some other embodiments, a small number of concurrent transactions can be used to verify the correctness of databases. However, the test coverage is small, and it cannot simulate the real concurrent situation of databases.

[0036] To solve the above problems, the present disclosure provides a method and device for testing databases to solve the problem that it is difficult to implement the correctness test of databases in the prior art.

[0037] In the test database provided by the embodiments of the present disclosure, a first data table may be stored. The first data table may include one or more first data groups associated with a transaction. One or more rows of data may be included in the one or more first data groups, and the data in the first data group satisfies the first data rule.

[0038] The first data table may include multiple first data groups. The first data group may be associated with a transaction. One first data group may be associated with one or more transactions. That the transaction is associated with the first data group may be understood as that the transaction can perform transaction operations on the data in the first data group. One or more rows of data may be included in the first data group. When the transaction performs transaction operations on the transactions in the first data group, it can perform transaction operations on one or more rows of data in the first data group.

[0039] The data in the first data group satisfies the first data rule. The first data rule may be used to constrain one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data group. The first data rule may constrain the data type of each column of data in the first data group. The data type may be, for example, a number, or may also be a random string, or may also be a check value of a random string. The first data rule may constrain the data content of each column of data in the first data group. The data content may be, for example, a monotonically increasing number, or may also be a string with a random length and random content, or may also be a random number. The first data rule may constrain the data relationship between columns. The data relationship between columns may be, for example, the sum relationship between column and column data. For example, it may be constrained that the sum of two random columns in a group of first data groups is a fixed value. The first data rule may constrain the number of rows of data in a group of first data groups. For example, the number of rows of data in a group of first data groups may be 3 rows. The first data table provided by the embodiments of the present disclosure will be described in detail below with reference to Table 1.

[0040] Table 1

[0041] row_id trx_grp v1 v1_check r1 r2 0 0 Random string Check value of v1 10 11 1 0 Random string Check value of v1 12 13 2 0 Random string Check value of v1 14 -60 3 1 Random string Check value of v1 100 101 4 1 Random string Check value of v1 102 103 5 1 Random string Check value of v1 104 -510 6 2 Random string Check value of v1 20 21 7 2 Random string Check value of v1 22 23 8 2 Random string Check value of v1 24 -110 9 3 Random string Check value of v1 300 301 10 3 Random string Check value of v1 302 303 11 3 Random string Check value of v1 304 -1510 12 4 Random string Check value of v1 50 51 13 4 Random string Check value of v1 52 53 14 4 Random string Check value of v1 54 -260 15 5 Random string Check value of v1 30 31 16 5 Random string Check value of v1 32 33 17 5 Random string Check value of v1 34 -160 … … … … …

[0042] The first data table shown in Table 1 may include one or more first data groups, which are associated with transactions. As shown in Table 1, the first data group may be a transaction group (trx_grp), and the first data table may include 5 first data groups. The execution of a transaction is based on a first data group, and the data within a first data group can be operated on by one or more transactions. For example, Transaction 1 can operate on the data in the first data group with trx_grp = 0, Transaction 2 can operate on the data in the first data group with trx_grp = 3, and Transaction 1 and Transaction 2 can also operate on the data in the first data group with trx_grp = 0. A first data group may include 1 or more rows of data. As shown in Table 1, a first data group may include 3 rows of data.

[0043] The first data table shown in Table 1 may include 6 columns of data, which are row number (row-id), first data group number (trx_grp), v1 column, v1-check column, r1 column, and r2 column respectively. The row number can be a monotonically increasing number. As described in Table 1, the row number is a monotonically increasing number starting from 0. The first data group number can be a number, and the value of this number can be monotonically increasing. In some embodiments, the value of the first data group number is the row number divided by the number of rows in the first data group. The v1 column can be a string with random length and random content. The v1-check column is the check value of v1, that is, the check value of the string with random length and random content in v1. In some embodiments, this check value can be the checksum of the v1 string calculated by checksum. For each row in a first data group, v1 can be randomly generated and the check value of v1 is consistent. For example, in the first data group 4, the v1 in the 3 rows of data can all be randomly generated strings, and the v1-check of these 3 rows is the checksum of the v1 string calculated by checksum, and this checksum is the same. The r1 column is a random number, and the r2 column is a random number. And in a first data grouping, the sum of the random numbers in the r1 column and the random numbers in the r2 column is a fixed value. In some embodiments, this fixed value can be zero. As shown in Table 1, in the first data group 3, the sum of the numbers in the r1 column and the numbers in the r2 column is 300 + 301 + 302 + 303 + 304 + (-1510) = 0.

[0044] Figure 1 A method for testing a database provided by an embodiment of the present disclosure can be executed by a test program, and the test program can be stored in any type of electronic device.

[0045] In step S100, one or more transaction operations are executed to update the data in the first data table.

[0046] A transaction operation can be an execution unit that accesses the data in the database under test and updates various data items in the database. The database under test can be, for example, a distributed database, which includes a first data table. The first data table can be, for example, Table 1 shown above.

[0047] The transaction operation can update the data in the first data group in the first data table. For example, the transaction operation can update the data in the first data group in the first data table. A transaction can be executed to update the data in the first data group in the first data table, or multiple transactions can be executed to update the data in the first data group in the first data table. When multiple transactions are executed, the multiple transactions can update different first data groups or the same data group. The concurrent execution of multiple transaction operations can be simultaneous or executed at intervals. In some embodiments, concurrent transaction updates can be performed on a first data group simultaneously.

[0048] The transaction operation can be, for example, a hot row update, a primary key update, a large transaction update, etc. The transaction operation is executed on the first data group in the first data table. Specifically, the transaction operation can modify single-row data and multi-row data in the first data group. For example, a hot update can be performed on the first data group. Specifically, a single row of data in the first data group is modified. Continuing with Table 1 as an example, the transaction operation can perform a hot row update on the first data group where trx_grp = 3 in Table 1. Specifically, 1,000 update operations can be performed on the data with row_id = 10. The transaction operation can also be, for example, a single-row delete, insert, and update transaction on the first data group where trx_grp = 6 in Table 1. Specifically, the data in row_id = 19 can be deleted first, then inserted, and finally updated. The transaction operation can also be, for example, a multi-row update transaction operation on the data in the first data group where trx_grp = 3, updating all the row data in the first data group 3. Specifically, a new group of data R1 and R2 can be regenerated.

[0049] The transaction operation does not change the first data rule within the first data group. This data rule can be, for example, the data rule mentioned above for constraining the data type, data content, data relationship between columns, and the number of rows of data within the first data group. In other words, whether the transaction operation is successfully committed or rolled back due to failure, it will not break the set data rule of the first data group. For example, when the transaction operation updates one or more rows of data in a first data group, it will not change the data type, data content, data relationship between columns, and the number of rows of data within the first data group.

[0050] Transaction operations can be set and added in the test framework. Different transaction operations can be set according to the nature of the database. For example, based on the data distribution, different scenarios such as single-machine transactions or distributed transactions can be tested. Another example is that cross-machine transactions and distributed transactions can be created according to the database distribution. Transaction operations can be set according to the test needs. For example, an index column can be added to the first data table. Another example is that a new data rule column can be added to the first data table. Another example is that transaction coverage between the main table and the index table can also be performed.

[0051] Transaction operations can be executed randomly. In other words, transaction operations can randomly perform update operations with random transaction types on the first data group. Transaction operations can randomly operate on one or more rows of a first data group. For example, transaction operations can randomly operate on the first data group with trx_grp = 3 in Table 1, and the random transaction type is a single-row delete, insert, or update transaction, and randomly delete the data in the row with row_id = 19.

[0052] In step S110, a query language is sent to the updated first data table to obtain a query result.

[0053] When performing database correctness testing, a query language can be sent to the first data table in the database through a data interface, and the query result can be obtained through this data interface. The query language can be used to query the update result of the transaction operation. The query language can query in units of the first data group. For example, the query language can query the update result of a certain first data group. Another example is that the query language can query the update results of multiple first data groups. The query language can not only query the update result of the transaction operation, but also query the unupdated data in the first data table. The query language can be, for example, SQL language. This SQL language can be used to query the sum of R1 + R2 in a first data group and the number of rows of data in a first data group. This SQL language can also be, for example, the result of querying the inner join operator and the number of rows of data in the first data group.

[0054] In step S120, the query result is verified according to the first data rule.

[0055] As mentioned before, performing transaction operations on the first data table does not change the first data rule of the first data group. Therefore, the correctness of the query result can be verified according to the first data rule. The first data rule is a data rule used to constrain one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data group as mentioned before. That is to say, the correctness of the query result can be verified by verifying the data type, data content, data relationship between columns, and the number of rows of data in the first data group.

[0056] It can be seen that a method for testing a database provided by the present disclosure can perform transaction operations on a data group, and the data in the data group satisfies fixed data rules. The transaction operations will not change the fixed data rules. Therefore, the results of the transaction operations are predictable. By verifying the predictable results of the transaction operations, the correctness test of the database transaction is realized.

[0057] When performing a database correctness test, the execution language of the transaction operation can be sent to the database under test through a data interface. This transaction execution language can be, for example, structured query language (SQL). Several examples of the execution language of transaction operations are given below in conjunction with Table 1.

[0058] Transaction 1 randomly operates on the data with trx_grp = 3. The randomly executed is a hot row update transaction, randomly updating the row with row_id = 10 a thousand times, that is, updating the content of the v1 column in the row with row_id = 10 a thousand times, but not changing the value of the v1 check value in the v1_check column. Finally, the transaction needs to be committed. The execution language of the specific transaction operation is as follows:

[0059] set autocommit = 0;

[0060] update obright set v1 = random string 1, v1_check = v1's check value where row_id = 10;

[0061] update obright set v1 = random string 2, v1_check = v1's check value where row_id = 10;

[0062] update obright set v1 = random string 3, v1_check = v1's check value where row_id = 10;

[0063] ... Repeat a thousand times

[0064] commit

[0065] Transaction 2 randomly operates on the data with trx_grp = 6. The randomly executed is a single row delete, insert, and update transaction, randomly performing an operation of first deleting, then inserting, and finally updating the row with row_id = 19. Finally, the transaction needs to be rolled back.

[0066] The execution language of the specific transaction operation is as follows:

[0067] set autocommit = 0;

[0068] Delete from obright where row_id = 19; At

[0069] Insert into obright (row_id, trx_grp, v1, v1_check, r1, r2) values (3, 19, 6, Random string, Check value of v1, Calculated r1, Calculated r2)

[0070] Update obright set v1 = Random string 2, v1_check = Check value of v1 where row_id = 19;

[0071] Rollback

[0072] Transaction 3 operates on data with trx_grp = 3. It randomly executes a multi - row update transaction to update all data with trx_grp = 3. Specifically, it regenerates r1 and r2 data for a group, updates trx_grp = 3, and finally commits the transaction commit.

[0073] The specific transactions are as follows

[0074] Set autocommit = 0;

[0075] Update obright set r1 = 33, r2 = 34 where row_id = 9;

[0076] Update obright set r1 = 35, r2 = 36 where row_id = 10;

[0077] Update obright set r1 = 37, r2 = - 175 where row_id = 11;

[0078] Commit

[0079] As can be seen from the above transaction operations, the transaction operations perform data operations in units of the first data group, and the transaction operations do not change the first data rule of the first data group. For example, Transaction 1 performs data operations on the first data group with trx_grp = 3, Transaction 2 performs single-row addition and deletion operations on the first data group with trx_grp = 6, and Transaction 3 performs multi-row update operations on the first data group with trx_grp = 3. The above transaction operations are all performed in units of the first data group. At the same time, the above transaction operations do not change the first data rule of the first data group. Specifically, the above transaction operations do not change the data type, data content, relationship between columns and column data, and the number of rows of data in the data group in the first data group.

[0080] Transaction operations can be executed concurrently. Multiple transaction operations can be executed concurrently. These multiple transaction operations can operate on data in different first data groups, and these multiple transaction operations can perform concurrent operations on data in the same data group. For example, both Transaction 1 and Transaction 3 perform transaction operations on the row with row_id = 10 in the first data group with rx_grp = 6. These transaction operations can be performed simultaneously or at intervals of a certain time. In the case of concurrent transactions, the correctness of the database under concurrent transactions can be tested.

[0081] Because transaction operations perform data operations in units of the first data group and transaction operations do not change the first data rule of the first data group, the execution results of the transactions obtained by query can be verified according to the first data rule. For example, the data type of v1 and the verification value of v1_check in the first data group with trx_grp = 3 can be verified. For another example, the values of row_id, trx_grp, v1, v1_check, r1, and r2 in the first data group with trx_grp = 6, the sum of r1 and r2, and the number of rows of data in this first data group can also be verified. For another example, the sum of r1 and r2 in the first data group with trx_grp = 3 and the number of rows of data in the first data group can also be verified. Because the first data rule of the first data group is fixed and the operations of the transactions do not change the first data rule, the results of the transaction operations are predictable. Therefore, the predictable execution results can be compared with the query results of the transaction execution to verify the correctness of the transaction operations.

[0082] In some embodiments, a query language may be sent to the updated first data table according to a test case to obtain a query result, and the query result may be verified according to the test case. A test case may be a description of a test task. A test case may include four parts, and these four parts may be, for example, parameters, SQL query language, expected query result, and expected number of data rows to be queried. Among them, a parameter (Parameter) may be, for example, a parameter required to execute the SQL query language, and this parameter may be randomly generated according to a variable. The SQL query language may be used to verify the result of a transaction operation, and this query language may include SQL functions, etc. The expected query result may be an expected query result predefined according to the first data rule of the first data group. The expected query result may be, for example, the expected query result of the SQL query language in a test case. The expected number of data rows to be queried may be, for example, the expected value of the number of data rows in the first data group queried by a test case.

[0083] When sending the query language to the updated first data table according to the test case, the query language in the test case may be sent to the database to query the first data table. The query language in the test case may be, for example, SQL query language. The query result may be verified according to the expected query result in the test case, and this expected result may be an expected result that conforms to the first data rule. It is checked whether the query result is consistent with the expected query result. When the query result is inconsistent with the expected result, it indicates that an error has occurred in the database correctness. This database correctness error may be, for example, a transaction correctness error, or may also be an error in the query language correctness.

[0084] To increase the test coverage, the first data group may be grouped to obtain a second data group. The second data group may include one or more first data groups, and transaction operations and query operations may be performed based on the second data group to set more types of transaction operations and more types of query operations, increase the test coverage, and improve the test accuracy. Table 2 gives an example of grouping the first data group to obtain the second data group.

[0085] Table 2

[0086] row_id grp_id trx_grp v1 v1_check r1 r2 0 0 0 Random string Check value of v1 10 11 1 0 0 Random string Check value of v1 12 13 2 0 0 Random string Check value of v1 14 -60 3 0 1 Random string Check value of v1 100 101 4 0 1 Random string Check value of v1 102 103 5 0 1 Random string Check value of v1 104 -510 6 1 2 Random string Check value of v1 20 21 7 1 2 Random string Check value of v1 22 23 8 1 2 Random string Check value of v1 24 -110 9 1 3 Random string Check value of v1 300 301 10 1 3 Random string Check value of v1 302 303 11 1 3 Random string Check value of v1 304 -1510 12 2 4 Random string Check value of v1 50 51 13 2 4 Random string Check value of v1 52 53 14 2 4 Random string Check value of v1 54 -260 15 2 5 Random string Check value of v1 30 31 16 2 5 Random string Check value of v1 32 33 17 2 5 Random string Check value of v1 34 -160 … … … … … … …

[0087] As shown in Table 2, the first data groups can be grouped to obtain second data groups. The first data groups with trx_grp = 0 and trx_grp = 1 can be a second data group with grp_id = 0, and this second data group can include 2 first data groups. The data in the second data group satisfies the second data rule, which is used to constrain the number of first data groups in the second data group. For example, the second data rule can be that the number of first data groups in a second data group is 2. Then, when there are 3 rows of data in each first data group, i.e., TRX_ROW_NUM = 3, and there are 6 rows of data in each second data group, i.e., GROUP_ROW_NUM = 6. In some embodiments, the value of grp_id can be the number of rows / the number of rows of data in the second data group. As shown in Table 1, for the first second data group, grp_id = 0 / 6 = 0, and for the second second data group, grp_id = 6 / 6 = 1.

[0088] Performing secondary grouping on the first data groups in the first data table to obtain second data groups can increase the types of transaction operations and test cases, making the test coverage more comprehensive. In some embodiments, one or more transactions can be executed to update the data in the second data group. Taking Table 2 as an example, for instance, one transaction can be executed to randomly update the data in the first data groups of the second data group with grp_id = 0. When verifying the query results, the verification can be performed according to the first data rule and the second data rule. For example, the value of grp_id in the second data group with grp_id = 0, the number of rows of data in the second data group, the number of rows of the first data group, the v1_check value, etc. can be verified to increase the test coverage and adapt to different database scenarios. The first data table can be queried and verified according to the test cases, and the expected query results in the test cases satisfy the first data rule and the second data rule.

[0089] The following gives an example of a result test case. The test case can be text-based, which is convenient for adding test cases.

[0090] Test Case 1: Verify that the sum of R1 and R2 in a second data group is zero and the correctness of the number of rows of data in the second data group.

[0091] [Parameter]

[0092] GRP_ID

[0093] [SQL]

[0094] select sum(r1+r2)from OBRight where grp_id=?group by trx_grp

[0095] [Result] 0

[0097] [RowCount]

[0098] GROUP_ROW_NUM / TRX_ROW_NUM

[0099] In the test cases, parameters and result values can carry GRP_ID, TRX_GRP, ROW_ID, TRX_ROW_NUM, GRP_ROW_NUM, etc. During the execution of the test cases, they will be automatically replaced with the set values and randomly generated values. The test cases are introduced below in combination with Table 2. When executing Test Case 1, an SQL query statement is sent to a random data table. For example, if this test case randomly operates on the second data group with GRP_ID = 1, then the SQL query statement is select sum(r1+r2) from OBRight where grp_id = 1 group by trx_grp. After receiving the query result, it is verified according to the preset expected value in Test Case 1 and the query result, and it is verified according to the expected number of returned rows 2 in Test Case 1 and the number of the first data group in the second data group queried. During the process of executing the test cases to verify the correctness of the transaction operations, all the test cases can be executed sequentially. If any verification problem occurs, such as the incorrect expected number of rows or the incorrect expected result value, etc., the execution of the test cases can be stopped immediately, or any operation on the database can be stopped to preserve the environment for convenient problem troubleshooting.

[0100] Test Case 2 tests the correctness of the results and the number of rows of the inner join operator

[0101] [Parameter]

[0102] GRP_ID,P1*2,P1,P1*GROUP_ROW_NUM,

[0103] [SQL]

[0104] select t1.grp_id,t1.row_id,t2.v1 FROM(select grp_id,row_id from obright where grp_id =? and trx_grp =?) as t1 INNER JOIN(select grp_id,v1 from obright where grp_id =? and row_id =?) as t2 ON t1.grp_id = t2.grp_id ORDER BY 1,2,3

[0105] [Result]

[0106] GRP_ID

[0107] GRP_ID * GROUP_ROW_NUM + i

[0108] Random

[0109] [RowCount]

[0110] TRX_ROW_NUM

[0111] The following describes Test Case 2 in combination with Table 2. When executing Test Case 2, an SQL query language is sent to the first data table. For example, this test case randomly operates on the second data group with GRP_ID = 2. The SQL query language is select t1.grp_id, t1.row_id, t2.v1 FROM (select grp_id, row_id from obright where grp_id = 6 and trx_grp = 12) as t1 INNER JOIN (select grp_id, v1 from obright where grp_id = 6 and row_id = 36) as t2 ON t1.grp_id = t2.grp_id ORDER BY 1, 2, 3. The expected result of this test case is grp_id = 2, row_id = 12 (GRP_ID * GROUP_ROW_NUM + i = 2 * 6), v1 is a random string, and the number of rows in the first data group is 3.

[0112] The execution of test cases can be concurrent. For example, the execution of test cases is concurrent, that is, multiple test cases can be executed simultaneously. Another example is that the execution of test cases and the execution of transaction operations can be concurrent, that is, the transaction operations on the first data table in the database and the query operations on the first data table in the database according to the test cases are executed simultaneously.

[0113] A method for testing a database provided by an embodiment of the present disclosure can also insert test data into the first data table in the database. When inserting test data into the first data table in the database, the data can be inserted into the first data table group by group. The test data can be data that meets the first data rule.

[0114] In some embodiments, test data may be inserted into the first data table in units of the first data group. The test data may be produced by a test program, and the test data satisfies the first data rule of the first data group. After the test program generates a test data group that conforms to the first data rule, the test data group may be inserted into the first data table using an insert statement, such as an insert values statement.

[0115] When inserting test data into the first data table, it may be concurrent insertion, that is, multiple groups of test data groups may be inserted into the first data table simultaneously. In some embodiments, the test program may be configured with 4 production threads, which are responsible for continuously inserting test data that satisfies the first data rule into the first data table in the database. Taking the first data table as Table 1 as an example, Thread 1 may insert data with trx_grp = 0, Thread 2 may insert data with trx_grp = 1, Thread 3 may insert data with trx_grp = 2, and Thread 4 may insert data with trx_grp = 3. When Thread 2 finishes the insertion first, it may continue to insert data with trx_grp = 4. After that, when Thread 3 finishes the insertion, it may insert data with trx_grp = 5. When Thread 1 finishes the insertion, it may insert data with trx_grp = 6... and so on, continuously advancing trx_grp forward and continuously inserting data that satisfies the grouping rule construction into the data table. Each thread will globally advance the transaction group trx_grp, and the trx_grp value will continuously increase unidirectionally, continuously adding test data to the data table.

[0116] When inserting test data into the first data table, it may be executed concurrently with the execution of transaction operations and / or the operation of sending a query language to the first data table. That is, test data may be inserted into the first data table while executing transaction operations to update the data in the first data table, or test data may be inserted into the first data table while executing the operation of sending a query language to the first data table, or test data may be inserted into the first data table while executing transaction operations to update the data in the first data table and at the same time executing the operation of sending a query language to the first data table.

[0117] In some embodiments, the above operations may be performed by threads. The threads may include production threads, update threads, and verification threads. The production threads may be used to insert test data into the first data table. The update threads may be used to execute transaction operations to update the data in the first data table. The verification threads may be used to send a query language to the first data table and verify the correctness of the query result. Figure 2Schematic diagram of a method for testing a database provided by an embodiment of the present disclosure. As can be seen from the figure, multiple production threads, update threads, and verification threads can be configured to perform transaction operations, send query languages, and verify query results on the first data table. The production threads, update threads, and verification threads shown in the figure can be concurrent. In this way, in a concurrent scenario, the higher the test coverage rate, the pressure of concurrent reading and writing of the database can be controlled by controlling the number of concurrent threads.

[0118] The method for testing a database provided by an embodiment of the present disclosure performs transaction operations on a data group. The data within the data group satisfies fixed data rules, and the transaction operations do not change the fixed data rules. Therefore, the results of the transaction operations are predictable. By verifying the predictable results of the transaction operations, the correctness test of the database transactions is realized. At the same time, the method for testing a database provided by an embodiment of the present disclosure can flexibly increase transaction operations and test cases, and can customize the pressure of concurrent transactions as needed.

[0119] As described above in conjunction with Figures 1 to 2 ,the method embodiments of the present disclosure have been described in detail. Next, in conjunction with Figures 3 to 4 ,the device embodiments of the present disclosure will be described in detail. It should be understood that the descriptions of the method embodiments and the device embodiments correspond to each other. Therefore, the parts not described in detail can be referred to the previous method embodiments.

[0120] Figure 3 It is a schematic structural diagram of a device for testing a database provided by an embodiment of the present disclosure. The database provided by an embodiment of the present disclosure includes a first data table. The first data table includes one or more first data groups associated with transactions. The first data group includes one or more rows of data, and the data in the first data group satisfies the first data rule. Figure 3 The device 300 for testing a database shown may include:

[0121] An update unit 310, configured to perform one or more transaction operations to update the data in the first data table, where the transaction operation is a transaction operation for the data within the first data group, and the transaction operation does not change the first data rule of the first data group;

[0122] A query unit 320, configured to send a query language to the updated first data table to obtain a query result;

[0123] A verification unit 330, configured to verify the query result according to the first data rule.

[0124] Optionally, the transaction operation includes parallel transaction operations for the same first data group.

[0125] Optionally, one or more first data groups associated with a transaction in the first data table form a second data group. The first data table includes one or more second data groups, and the data in the second data group satisfies a second data rule. The query result is verified according to the first data rule, and the verification unit is further configured to verify the query result according to the first data rule and / or the second data rule.

[0126] Optionally, the first data rule is used to constrain one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data group.

[0127] Optionally, the second data rule is used to constrain the number of first data groups in the second data group.

[0128] Optionally, the device further includes a data insertion unit configured to insert the first data group into the first data table when performing the one or more transaction operations and / or sending a query language to the updated first data table.

[0129] Optionally, sending a query language to the updated first data table to obtain a query result includes: sending a query language to the updated first data table according to a test case; verifying the query result according to the first data rule includes: verifying the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule.

[0130] Optionally, verifying the query result according to the first data rule and / or the second data rule includes: verifying the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule and / or the second data rule.

[0131] Figure 4 It is a schematic structural diagram of another device for testing a database provided by an embodiment of the present disclosure. Figure 4 The illustrated device 400 may include a memory 410 and a processor 420. The memory 410 can be used to store executable code. The processor 420 can be used to execute the executable code stored in the memory 410 to implement the steps in the various methods described above. In some embodiments, the device 420 may further include a network interface 430, and the data exchange between the processor 420 and external devices can be achieved through this network interface 430.

[0132] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present disclosure are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a Digital Video Disc (DVD)), or a semiconductor medium (such as a Solid State Disk (SSD)), etc.

[0133] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments of the present disclosure can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present disclosure.

[0134] In several embodiments provided by the present disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in an electrical, mechanical, or other form.

[0135] The unit described as a separation component may or may not be physically separated. The component displayed as a unit may or may not be a physical unit, that is, it may be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0136] In addition, each functional unit in various embodiments of the present disclosure may be integrated in a processing unit, may exist separately as individual physical units, or two or more units may be integrated in one unit.

[0137] As mentioned above, the above are only specific implementation manners of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present disclosure can easily think of changes or substitutions, which should be covered by the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A method for testing a database, the database including a first data table, the first data table including one or more first data groups associated with transactions, the first data groups including one or more rows of data, the data in the first data groups satisfying a first data rule, one or more first data groups associated with transactions in the first data table constituting a second data group, the first data table including one or more second data groups, the data in the second data groups satisfying a second data rule, the first data rule being used to restrict one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data groups, and the second data rule being used to restrict the number of first data groups in the second data group, The method includes: Performing one or more transaction operations to update the data in the first data table, wherein the transaction operations are transaction operations on the data within the first data groups, and the transaction operations do not change the first data rule of the first data groups, and the transaction operations are carried out in units of the first data groups; Sending a query language to the updated first data table to obtain a query result; Verifying the query result according to the first data rule and the second data rule.

2. The method according to claim 1, wherein the transaction operations include parallel transaction operations for the same first data group.

3. The method according to claim 1, when performing the performing one or more transaction operations and performing the sending a query language to the updated first data table, inserting the first data groups into the first data table.

4. The method according to claim 1, wherein the sending a query language to the updated first data table to obtain a query result includes: Sending a query language to the updated first data table according to a test case.

5. The method according to claim 1, wherein the verifying the query result according to the first data rule and the second data rule includes: Verifying the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule and the second data rule.

6. A device for testing a database, the database including a first data table, the first data table including one or more first data groups associated with transactions, the first data groups including one or more rows of data, the data in the first data groups satisfying a first data rule, one or more first data groups associated with transactions in the first data table constituting a second data group, the first data table including one or more second data groups, the data in the second data groups satisfying a second data rule, the first data rule being used to restrict one or more of the data type, data content, data relationship between columns, and the number of rows of data in the first data groups, and the second data rule being used to restrict the number of first data groups in the second data group, The device includes: An update unit, configured to perform one or more transaction operations to update data in the first data table, wherein the transaction operations are transaction operations for data within the first data group, and the transaction operations do not change the first data rule of the first data group, and the transaction operations are carried out in units of the first data group; A query unit, configured to send a query language to the updated first data table to obtain a query result; A verification unit, configured to verify the query result according to the first data rule and the second data rule.

7. The apparatus according to claim 6, wherein the transaction operations include parallel transaction operations for the same first data group.

8. The apparatus according to claim 6, further comprising a data insertion unit, configured to insert the first data group into the first data table when performing the one or more transaction operations and performing the sending of the query language to the updated first data table.

9. The apparatus according to claim 6, wherein the sending of the query language to the updated first data table to obtain a query result includes: Sending a query language to the updated first data table according to a test case.

10. The apparatus according to claim 6, wherein the verifying the query result according to the first data rule and the second data rule includes: Verifying the query result according to the expected query result in the test case, and the expected query result of the test case conforms to the first data rule and the second data rule.

11. An apparatus for testing a database, comprising a memory and a processor, the memory is used for storing code, and the processor is used for calling the code in the memory to execute the method according to any one of claims 1-5.

Images