Transaction-oriented database has a large-scale test case reduction method for testing exceptions

Abstract

This invention discloses a method for simplifying large-scale test cases with test anomalies in transactional databases, comprising the following steps: Step 1: Extract test case information. For a given initial test case, based on the corresponding test database table structure and execution information, encode the operation information in the test case, organizing it into a matrix by transaction; Step 2: Aggregate related transactions based on the data access correlation and session correlation of each transaction. Combining the data access characteristics of each transaction and its associated session, use an inverted index to aggregate the transactions in the initial test case to obtain a transaction set; Step 3: Prune the test cases. Iteratively prune to gradually reduce the transaction set in the test cases to obtain simplified test cases. This invention also discloses the application of the above method in test case simplification during database test development.

Description

Technical Field

[0001] This invention belongs to the field of database technology and test case simplification, and in particular relates to a method for simplifying large-scale test cases with test anomalies in transactional databases. Background Technology

[0002] Database management systems (DBMS) are essential foundational software widely used in finance, IT, and telecommunications. With the booming development of the internet, new applications are constantly emerging, leading to increasing business demands. These new requirements and applications are driving the rapid development of the database industry. At the beginning of this century, because traditional relational databases could not meet the demands of the internet industry for large-scale, long-term online, and highly available business data, NewSQL databases characterized by distributed architecture and cloud services, such as Aurora, emerged. [1] Socrates [2] Spanner [3] These new databases are playing an increasingly important role in various industries. In this process, many domestic database development vendors have adapted to the times, focusing on developing core technologies and maintaining the open-source ecosystem, and have developed database products with leading technologies that are suitable for current needs, such as OceanBase. [4] GaussDB [5] TiDB [6] etc.

[0003] With the booming development of databases and the widespread application of distributed databases, database vendors urgently need to validate their database concurrency control mechanisms. Currently, the main method for validating database concurrency control mechanisms is to generate large amounts of test data and verify database execution through black-box testing, such as Cobra. [7] Elle [8] These tools typically generate test data based on certain constraints, import the generated data into a database for testing, determine whether the database execution results meet expectations, and verify the correctness of the execution by analyzing the transaction dependency graph.

[0004] In database testing, the aforementioned black-box testing tools have successfully discovered and reported numerous anomalies, and database developers have confirmed a significant portion of these error reports. However, because these tools are often used for large-scale testing, the generated test cases are large and difficult to submit to database developers. When the test cases are too large, their execution is affected by numerous factors, making it difficult for database developers to reproduce the corresponding cases and thus unable to confirm the existence of the problem. Anomaly discoverers often need to spend a significant amount of time and effort to streamline the test cases. This undoubtedly slows down the progress of database development and testing.

[0005] Effective reproduction of database anomalies can assist developers in fixing errors and drive rapid database iteration. Faced with a large-scale test case, developers often struggle to quickly locate and fix anomalies for the following reasons: First, developers often find it difficult to fix an anomaly that cannot be reproduced. This is because such anomalies typically occur in production environments rather than test environments, resulting in limited records of database and application execution states at the time of the anomaly, insufficient to deduce its cause. If the anomaly can be stably reproduced in the test environment, it allows database developers to purposefully obtain runtime state and execution information, aiding in anomaly inference. Second, even when an anomaly can be reproduced, a large and complex reproduction process and case can introduce a large amount of irrelevant runtime information, causing developers to be distracted by irrelevant information and making it difficult to find content helpful in fixing the anomaly. Simplifying the reproduction process and case as much as possible can help developers eliminate interference from useless information and speed up the anomaly location process.

[0006] Given this issue, streamlining large-scale test cases to obtain smaller, reproducible cases is of great significance. However, current test case streamlining still faces the following key challenges:

[0007] 1. The original test case contains a large number of transactions, and the exception involves the interaction of multiple transactions, making it difficult to determine which transactions are directly related to the exception.

[0008] 2. In the case of concurrent execution of multiple sessions, the order of operation execution cannot be determined, making it difficult to simulate the transaction execution order when an exception occurs.

[0009] 3. A large number of internal states are closely related to the operating system and hardware states and change rapidly. External programs cannot accurately control and simulate the internal states of the database during execution. Summary of the Invention

[0010] To address the shortcomings of existing technologies, the present invention proposes a method for simplifying large-scale test cases with test anomalies in transactional databases. By iteratively pruning the transaction set in the test cases, an effective solution for reducing the size of test cases is provided. Furthermore, by controlling the execution order to simulate the original execution state, the simplification efficiency is improved through the pruning iteration process.

[0011] The relevant definitions in this invention are as follows:

[0012] Definition 1: Test Case: A test case is a set of test input data for a specific database, specifically consisting of transactions. Executing a test case involves running the corresponding set of transactions and analyzing the correctness of the execution results. The expected correct results should meet the database's typical isolation level requirements. The initial test case is called the initial test case.

[0013] Definition 2: Valid test cases: Valid test cases are those that trigger the same exception when executed, while invalid test cases are those that cannot trigger the same exception.

[0014] Definition 3 Minimal valid case: The minimum valid case is the case with the fewest transactions among valid test cases.

[0015] The simplified method for case analysis described in this invention includes the following steps:

[0016] Step 1: Extract test case information. For a given initial test case, combine the corresponding database table structure and execution information to re-encode the operation information in the test case and organize it into a matrix in units of transactions.

[0017] In this invention, the test cases contain multiple concurrently executing sessions, each session contains multiple sequentially executed transactions, and each transaction consists of multiple operations. The operations within each session are unique, but their execution order is interleaved. Within the same session, the operations within each transaction are unique, and their execution order is also independent. The initial test cases record execution information on an operation-by-operation basis and arrange them according to the actual execution order. Based on the above input, the operations are organized into transactions according to the transactions to which the operations in the test cases belong. The resulting new transactions correspond one-to-one with the transactions in the test cases, ensuring that the operation order of the new transactions is the same as that in the test cases; the order of transactions within rows of the matrix is ​​the same as the order within each session in the test cases. The number of rows in the matrix represents the number of sessions in the initial test cases, and the number of columns in the matrix represents the maximum number of transactions contained in a single session in the initial test cases.

[0018] Step Two: Aggregate related transactions based on the data access correlation and session correlation of each transaction. Combining the data access characteristics of each transaction and its associated session, use an inverted index to aggregate the transactions in the initial test case to obtain a transaction set. In this invention, an inverted index refers to an index structure constructed using data items as index terms and the transactions accessing those data items as the indexed content. Aggregate all transactions identified by each index term in the index (i.e., all transactions accessing that index term) to obtain the transaction set. The transaction set obtained through inverted index aggregation must satisfy at least one of the following two conditions: transactions in the same set have all read or written the same data item; transactions in the same set are all executed by the same session. All aggregated transaction sets are collectively referred to as the anomaly-related transaction set. The anomaly-related transaction set is used to describe the correlation between transactions in the test case, thereby identifying transactions that may be related to the triggering of an anomaly.

[0019] Step 3: Prune test cases. This involves iteratively reducing the set of transactions within each test case. Pruning test cases involves removing a set of transactions associated with exceptions from the test case's transaction set, resulting in new test cases. For operations across different sessions, the execution order of the new test cases is the same as the execution order of the test cases that can trigger exceptions.

[0020] According to this method, the present invention reduces transactions unrelated to triggering exceptions, thereby reducing the number of transactions in test cases and solving the problem in the prior art where the original test cases contain a large number of transactions, and exceptions involve the interaction of multiple transactions. The execution order of operations is determined based on the transaction execution order in valid test cases, ensuring that the execution order is as similar as possible to the execution order when an exception occurs. This solves the problem in the prior art where the execution order of operations cannot be determined in the case of multiple sessions executing concurrently. The new test cases obtained from the pruning process simulate the execution order when an exception occurs, and further simulate the internal state of the database when an exception occurs, solving the problem that external programs cannot accurately control and simulate the internal state of the database during execution. The above steps are iterated to prune test cases, and the iteration process is optimized based on the pruning results and the ability to reproduce exceptions. If the current test case cannot trigger an exception or has already been iterated, then the test case is pruned, i.e., iteration of this case is stopped.

[0021] This invention also provides an application of the above method in the simplification of test cases during database test development.

[0022] The beneficial effects of this invention include: It provides a method for simplifying large-scale test cases with test anomalies in transactional databases. Through iterative iteration, it prunes the set of transactions within each test case, providing an effective solution for reducing test case size. Furthermore, it simulates the original execution state by controlling the execution order and improves simplification efficiency through the pruning iterative process. This invention can significantly reduce the size of test cases; no similar simplification work exists to date. For known error cases, this invention can reduce the number of transactions by an average of 70%. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the input data in the embodiment.

[0024] Figure 2 This is a schematic diagram illustrating the extraction of case information in the embodiments.

[0025] Figure 3 This is a schematic diagram of the inverted index in the embodiment.

[0026] Figure 4 This is a schematic diagram illustrating the AND operation between mask matrices in the embodiment.

[0027] Figure 5 This is a flowchart of the simplified method of the present invention. Detailed Implementation

[0028] The invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the invention are all common knowledge and general knowledge in the art, and the invention does not have any particular limitations.

[0029] This invention provides a method for simplifying large-scale test cases with test anomalies in transactional databases, comprising the following steps: extracting case information with anomalies; for a given test case, encoding the transaction information in the case in conjunction with the test database table structure, and representing it as a matrix; aggregating related transactions; combining the data access characteristics and the sessions to which each transaction belongs, aggregating related test case transactions, and constructing a set of anomaly-related transactions based on the aggregation results; and pruning cases; iteratively pruning test cases based on the set of related transactions, and optimizing based on the anomaly reproducibility of the pruning results.

[0030] Specifically, it includes the following steps:

[0031] 1. Extract test case information and organize the test case information based on the given initial test cases. The given test cases describe exceptions on an operation-by-operation basis and need to be merged back into transactions for simplification. During merging, operations belonging to the same transaction need to be merged in execution order. The data itself is not changed before and after merging; only the organizational structure of the operations is changed. Since operations within the same session are arranged in execution order, there is no overlap between operations from different transactions. Therefore, this method merges the operations within each session into transactions sequentially, so that the new transaction corresponds one-to-one with the transactions in the initial test cases and contains the same operations. The order of operations within the new transaction is the same as in the initial test cases. The resulting transaction can be represented as an n x m matrix, where n is the number of sessions in the initial test cases, and m is the maximum number of transactions contained in a session in the initial test cases. The elements in the matrix represent a transaction, the row of the element represents the session executing the transaction, and the column represents the order of the transaction within that session. The order of transactions is the same as the order of transactions within each session in the initial test cases.

[0032] 2. Aggregate related transactions. Since similar transactions have a similar impact on exception triggering, they can be retained or pruned simultaneously. Therefore, pruning similar transactions in test cases can accelerate the reduction of the test case set size. To obtain related transactions, transactions are aggregated based on the information extracted from the test cases. This method mainly focuses on the correlation between transactions in terms of data access and their respective sessions.

[0033] When aggregating based on data access, this method uses the data set of transaction accesses as the basis. For each extracted transaction, each operation contains the data set read or modified by that operation. The data sets read and written by all operations in the transaction are merged to obtain the data set of transaction accesses. Based on this set, an inverted index is constructed using the data items accessed by the transaction as indexes, so that transactions accessing the same data item can be indexed by the same index, thus obtaining the relationship between the data item and the transactions that have accessed it. Transactions that have accessed the same data item are aggregated into a transaction set. Since a transaction may access multiple data items, the same transaction may exist in multiple different transaction sets. This yields a set of all transactions that are related in terms of data access. When aggregating based on the session to which the transaction belongs, this method uses the session to which the transaction belongs as the basis. The set of transactions executed by the same session is grouped into a transaction set, and transactions executed by the same session are considered related transactions. This yields a set of all transactions that are related in terms of their respective sessions. The sets of transactions that are related in terms of data access and their respective sessions are merged to obtain an abnormally related transaction set. Each element in the abnormally related transaction set is a transaction set obtained based on the above method.

[0034] 3. Prune test cases: Perform pruning operations based on the abnormal related transaction set constructed by the aggregation to prune the corresponding transactions in the test cases, thereby reducing the size of the transaction set in the test cases and simplifying the test cases.

[0035] After aggregating the set of anomalously related transactions, a pruning operation can remove one set of transactions from the set of anomalously related transactions from a given test case. Based on the matrix representing the initial test case, the operation of pruning a test case can be represented as an n x m 0-1 matrix, called the mask matrix. This matrix corresponds element-wise to the set of transactions to be pruned. Each element describes whether a specific transaction needs to be pruned, and its position in the mask matrix is ​​the same as its position in the matrix corresponding to the initial test case. Through this correspondence, the elements in the mask matrix indicate whether the transaction at the corresponding position in the initial test case exists in the set of transactions to be pruned. If it exists, it is marked as 0, and the pruning operation will remove the transaction from the test case's transaction set; otherwise, it is marked as 1, and the pruning operation will retain the corresponding transaction. Pruning a test case can yield a new test case, which can be uniquely determined by the initial test case and a specific pruning operation. The set of transactions pruned by the pruning operation is the difference between the initial test case and the new test case's transaction set. The initial test case can directly yield the new test case through this pruning operation. Therefore, new test cases can be represented using the mask matrix corresponding to this clipping operation.

[0036] The pruning process iterates repeatedly to obtain the minimum number of valid test cases. The pruned test cases only need to execute the remaining transactions and are represented by a mask matrix for subsequent iterations. During iteration, a queue is used to store test cases waiting for iteration, facilitating the retrieval of test cases needed for subsequent iterations. Initially, the queue only contains the mask matrix corresponding to the initial test case. For each iteration, a test case is retrieved from the queue, and the set of exception-related transactions is traversed. For each transaction set in the exception-related transaction set, a test case for the pruned corresponding transaction is generated, the test case is executed, and its validity is confirmed; valid test cases are added to the queue. This ensures that all test cases in the queue are valid. The above steps are repeated until the queue is empty. Since this process tries all combinations of test cases and all transaction sets, all valid test cases can be obtained through iteration. Specifically, after pruning the transactions in the test cases using the mask matrix corresponding to the transaction set, the new test cases obtained after pruning are also represented by a mask matrix. Therefore, only the mask matrix needs to be stored during iteration; it is not necessary to store all transaction information for each test case during iteration, reducing the space overhead of storing specific transaction execution information during iteration.

[0037] The iteration process is optimized based on the pruning results and anomaly reproducibility, incorporating two optimization strategies. First, when new test cases are obtained through pruning, these test cases are matched against previously tested valid test cases. If the current test case completely contains all transactions of a given test case—that is, a subset of the current test case has already been obtained through iteration—then the test case is considered valid without needing to re-verify its validity. Second, invalid test cases are not added to the queue during the iteration process; that is, invalid test cases are not iterated over further.

[0038] Based on the definition of the test case simplification problem above, the input of this method includes the test table structure, initial test database data, and execution logs of the initial test cases. The implementation process of this method includes three steps: extracting test case information, aggregating relevant transactions, and trimming test cases. The output of this method contains the minimum number of valid test cases after simplification.

[0039] Example

[0040] Input Data: The initial test cases required by this invention contain several sessions, each session containing several operations O in execution order. Each operation records its associated transaction, operation type, specific SQL statement executed, and accessed data items. The operation type may be a read operation or a write operation, denoted as R(id) and W(id) respectively, where id represents the data item accessed by the operation. An operation may access multiple data items, such as... Figure 1 As shown. Figure 1The error case shown is a real error case from database X. The error comes from the fourth and fifth operations of the third session. Therefore, the second and third transactions of the third session constitute the minimum valid case.

[0041] Extracting Test Case Information: Based on the execution logs of the given initial test cases, first read the operation information and categorize it by session. Then, sort the operations in each session based on execution time, obtaining the operation sequence O1, O2, ... arranged in chronological order, such as... Figure 2 As shown in ①, operations belonging to the same transaction are merged in this order. This reorganizes the operations into transactions T1, T2…, as follows. Figure 2 As shown in ②. Then, the representation is organized by transaction as a matrix. Assuming there are n sessions, and each session contains at most m transactions, an n x m matrix M is constructed. The element in the i-th row and j-th column of matrix M represents the j-th transaction of the i-th session. If the i-th session contains fewer than j transactions, that element is set to empty, such as... Figure 2 As shown in ③.

[0042] Aggregate related transactions: First, aggregate based on the session to which they belong. Based on the matrix M constructed above, aggregate all transactions in each row to obtain a set of all transactions executed by the same session. For example... Figure 2 In the middle, {T 11 ,T 12 The first set of transactions executed by the first session is aggregated based on data access. Next, an access data set is constructed for each transaction, which is a set of read and write data items that combine all operations contained in the transaction. If the data items are denoted as d1,…d… j ..., through transactions T1,...,T i By constructing and accessing the data set, we can obtain the correspondence between transactions and data sets. <T i ,{d1,d2,…,d j Based on this correspondence, an inverted index is constructed to obtain the reverse correspondence, where the indexed item is the data and the indexed item is the transaction that accesses that data. <d j ,T1,T2,…,T i This inverted index aggregates transactions, grouping transactions indexed by the same index entry into a set, thus obtaining a set of all transactions accessing the same data. For example, Figure 2 In the test case shown, transaction T 11 Given a transaction containing read operation O1 and write operation O2, where O1 reads data item {1,2,3} and O2 modifies data item {3,4,5}, the data set accessed by the transaction is the union of {1,2,3} and {3,4,5}, which is {1,2,3,4,5}. Based on this, the correspondence between transactions and data sets can be established. <T 11The inverted index is constructed based on this correspondence, except for T. 11 In addition, data item 1 is only used by transaction T. 21 T 32 T 33 If accessed, the transaction corresponding to index item 1 is {T}. 11 ,T 21 ,T 32 ,T 33}, that is, {T 11 ,T 21 ,T 32 ,T 33} is a set of transactions that access the same data item 1. For example... Figure 3 As shown, each data item indexed by a transaction constitutes a set; that is, each row of transactions in the diagram constitutes a transaction set aggregated based on the accessed data item. Merging these two types of transaction sets, aggregated based on the session and the accessed data item, yields the abnormally related transaction set, i.e. Figure 3 The seven transaction sets shown are related to {{T} 11 ,T 12},{T 21 ,T 22 ,T 23},{T 31 ,T 32 ,T 33 The intersection of}}.

[0043] After aggregating the abnormal associated transaction set, a corresponding mask matrix is ​​constructed to represent the pruning operation on the transaction set. If the matrix M constructed based on the initial test load is an n x m matrix, then the mask matrix M' is a 0-1 matrix of the same size as M. The values ​​of the mask matrix elements indicate whether the element represented at the corresponding position in matrix M should be pruned during the pruning operation, as shown in Equation 1:

[0044]

[0045] In other words, if the value of an element in M' is 0, it means that the pruning operation will remove the transaction represented by the element at the corresponding position in M ​​from the transaction set. For example... Figure 1 In the test case shown, if data item 1 is only used by transaction T 11 ,T 21 ,T 32 ,T 33 If an access is made, then the set of transactions constructed based on accessing the same data item 1 is {T}. 11 ,T 21 ,T 32 ,T 33 The mask matrix for cropping this set of transactions is as follows: Figure 4 As shown in matrix B, this represents pruning T from the transaction set.11 ,T 21 ,T 32 ,T 33 Four transactions. Simultaneously, the mask matrix also represents the new test cases obtained after the test cases undergo a pruning operation, which are then used in the next iteration.

[0046] Test Case Pruning: To obtain the minimum number of valid test cases, the program iteratively prunes the test cases. A mask matrix represents the set of transactions corresponding to each test case, and the pruning is achieved based on the AND operation of the mask matrices. The AND operation is defined as follows: For two mask matrices of the same size, the AND operation yields a new mask matrix with the same size as the original matrix. For any element in the new matrix, the element is 1 if and only if the corresponding element in the original two mask matrices is 1; otherwise, the element is 0. Figure 4 As shown. The transaction set represented by the new mask matrix is ​​the intersection of the transaction sets represented by the original two mask matrices. For n x m mask matrices A and B, where A represents a test case and B represents the pruning operation corresponding to one of the transaction sets in the abnormal associated transaction set, the result of the AND operation between the two, C = A ∧ B, satisfies Formula 2:

[0047]

[0048] The transaction set represented by C is the intersection of the transaction sets represented by A and B. That is, the test cases corresponding to the transaction set represented by C can be obtained by trimming the test cases corresponding to A using the trimming operation corresponding to B. Figure 1 The test case shown, if Figure 4 Matrix B represents the set of abnormal associated transactions that access data item 1. The transaction set represented by C is obtained by pruning all transactions accessing data item 1 in the test case corresponding to A. That is, based on the transaction set corresponding to A, transactions {T} are pruned. 11 ,T 21 ,T 32 ,T 33 When executing the test case corresponding to C, the program only needs to execute transaction T. 12 T 23 T 31 Based on the definitions of AND and pruning operations above, the iterative algorithm is designed as follows:

[0049]

[0050] During the iteration process, a queue is used to store the mask matrices corresponding to the test cases waiting for iteration. Initially, the queue only contains the matrices corresponding to the test cases (lines 2-3). For each iteration, a test case is taken from the queue (line 5), and all transaction sets obtained in step two are traversed (lines 6-17). For each transaction set, a new test case is obtained by performing a bitwise AND operation on the mask matrix (line 7), and its validity is verified. The execution order of the test cases needs to be controlled; that is, for all operations to be executed, if any two operations have a clear sequential relationship in the execution time of a valid test case, then this sequential relationship should be satisfied when executing any test case. With the execution order controlled, if a test case is valid, it is added to the queue, and the corresponding mask matrix is ​​saved in the mask matrix set of valid test cases. The above steps are repeated, and the minimum number of valid cases in the transaction set is maintained (lines 13-14) until the queue is empty. The valid case saved at this time is the minimum valid case.

[0051] The program optimizes the iteration process during execution using two strategies: one based on the pruning results and the other based on the anomaly reproducibility. First, for the pruning-based optimization strategy, when a new test case C is obtained through pruning, the mask matrix corresponding to C is matched with the set of mask matrices for valid test cases. If a mask matrix C' exists in the set, the transaction set corresponding to C' is a subset of the transaction set corresponding to C, as shown in Formula 3.

[0052]

[0053] If the test case is deemed valid, it is not necessary to verify its validity again (lines 8-10). Secondly, for optimization strategies based on the ability to reproduce anomalies, invalid test cases will not be added to the queue during the iteration process (lines 11-12), thereby accelerating the iteration process.

[0054] Through the above steps of pruning error cases, the initial set of error cases, {T}, is pruned once. 11 ,T 12 ,T 21},{T 11 ,T 31},{T 12 ,T 22 ,T 23} to obtain the minimum effective case {T 32 ,T 33 The minimum number of valid cases reduces the number of transactions by 75% compared to the initial number of error cases, achieving effective error case reduction.

[0055] References

[0056] [1]Verbitski A,Gupta A,Saha D et al.Amazon Aurora:DesignConsiderations for High Throughput Cloud-Native Relational Databases[C].Proceedings of the 2017ACM International Conference on Management ofData.Chicago Illinois USA:ACM,2017:1041-1052.

[0057] [2]Antonopoulos P,Budovski A,Diaconu C et al.Socrates:The New SQLServer in the Cloud[C].2019ACM SIGMOD Conference.2019.

[0058] [3]Corbett J C,Dean J,Epstein M et al.Spanner:Google’s GloballyDistributed Database[J].ACM Transactions on Computer Systems,2013,31(3):1-22.

[0059] [4]Zhenkun Yang,Chuanhui Yang,Fusheng Han et al.2022.OceanBase:a707million tpmC distributed relational database system.Proc.VLDB Endow.15,12(August 2022),3385–3397.

[0060] [5]Zhu J,Cheng K,Liu J et al.Full encryption:an end to end encryptionmechanism in GaussDB[J].Proceedings of the VLDB Endowment,2021,14(12):2811-2814.

[0061] [6] Huang D, Liu Q, Cui Q et al. TiDB: a Raft-based HTAP database [J]. Proceedings of the VLDB Endowment, 2020, 13(12): 3072-3084.

[0062] [7]Tan C, Zhao C, Mu S et al. Cobra: Making Transactional Key-ValueStores Verifiably Serializable[J]. 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20), 2020, 60-80.

[0063] [8] Kingsbury K, Alvaro P. Elle: Inferring Isolation Anomalies from Experimental Observations[J].arXiv:2003.10554[cs], 2020.

[0064] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of the inventive concept are included in this invention and are protected by the appended claims.

Claims

1. A method for reducing large test cases with test exceptions for transactional databases, characterized in that, Includes the following steps: Step 1: Extract test case information. For a given initial test case, combine the corresponding test library table structure and execution information to encode the operation information in the test case, and organize it into a matrix in units of transactions. Step 2: Aggregate related transactions based on the data access correlation and the session correlation of each transaction. Combine the data access characteristics of each transaction with the session to which it belongs, and use an inverted index to aggregate the transactions in the initial test case to obtain a transaction set. In step two, the inverted index refers to an index structure constructed with data items as index items and transactions accessing those data items as the indexed content; all transactions determined by each index item in the index are aggregated to obtain a transaction set. The transaction set obtained by aggregation through inverted index must satisfy at least one of the following two conditions: all transactions in the same set have read or written the same data item; all transactions in the same set are executed by the same session. In step two, the aggregated set of all transactions is collectively referred to as the anomaly-related transaction set. The anomaly-related transaction set is used to describe the correlation between transactions in the test case, thereby identifying transactions that may be related to the triggering of the anomaly. Step 3: Trim test cases. By iteratively trimming, the set of transactions in the test cases is gradually reduced to obtain simplified test cases.

2. The transaction-oriented database with test exception large scale test case reduction method of claim 1, wherein, In step one, the test case contains multiple sessions that are executed simultaneously. Each session contains multiple transactions that are executed sequentially. Each transaction consists of multiple operations. The operations in each session are not repeated, but their execution order is interleaved. In the same session, the operations in each transaction are not repeated, and their execution order is not interleaved. The initial test case records execution information on an operation-by-operation basis and arranges them according to the actual execution order.

3. The transaction oriented database having test exception large scale test case reduction method as claimed in claim 1 wherein, In step one, the operations are organized into transactions based on the transactions to which the operations belong in the test case. The resulting new transactions correspond one-to-one with the transactions in the test case, and the operation order of the new transactions is guaranteed to be the same as that of the test case. The order of transactions within rows of the matrix is ​​the same as the order within each session in the test case; the number of rows in the matrix represents the number of sessions in the initial test case, and the number of columns in the matrix represents the maximum number of transactions that a session in the initial test case can contain.

4. The transaction oriented database with test exception large scale test case reduction method of claim 1, wherein, In step three, test cases are pruned based on the transaction set. New test cases are obtained by pruning the test cases to the set of transactions associated with the exception. If executing the new test case still triggers an exception, the process is iterated until no transaction in the pruned test case can trigger an exception. For operations in different sessions, the execution order is the same as the execution order of test cases that can trigger exceptions.

5. The transaction oriented database having test exception large scale test case reduction method of claim 1, wherein, In step three, the iteration process is optimized based on the test cases and the ability to trigger exceptions. If the current test case cannot trigger an exception or has already been iterated, the test case is pruned, that is, the iteration of this case is stopped.

6. The transaction oriented database having test exception large scale test case reduction method as claimed in claim 1 wherein, In step three, the operation of pruning test cases is represented by a mask matrix. The mask matrix is ​​an n-row m-column 0-1 matrix. The mask matrix corresponds element-wise to the set of transactions that need to be pruned. Each element describes whether a specific transaction needs to be pruned. Its position in the mask matrix is ​​the same as the position of the transaction in the matrix corresponding to the initial test case. The elements in the mask matrix are represented as follows: ， wherein, denotes a mask matrix, denotes a matrix constructed based on the initial test load that needs to be trimmed.

7. The transaction oriented database having test exception large scale test case reduction method as claimed in claim 1 wherein, In step three, when a new test case is obtained through pruning, the test case is matched with the previously tested valid test cases. If the current test case completely contains all the transactions of a certain test case, that is, a subset of the current test case has been obtained through iteration, the test case is directly considered valid and there is no need to verify its validity again. Invalid test cases will not be added to the queue during the iteration process, that is, invalid test cases will not be iterated.

8. The application of the method as described in any one of claims 1-7 in the process of simplifying test cases during database test development.

Images