TY - JOUR
T1 - DBSoft
T2 - A toolkit for testing database transactions
AU - Al-Khanjari, Zuhoor A.
AU - Baghdadi, Youcef
AU - Al-Hamdani, Abdullah
AU - Al-Kindi, Sara
PY - 2013/8
Y1 - 2013/8
N2 - Databases (DBs) are used in all enterprise transactions, which require attention not only to the consistency of DB, but also to existence, accuracy and correctness of data required by the transactions. While the Atomicity, Consistency, Isolation, and Durability (ACID) properties of a transaction ensure that DB is consistent after the execution of each transaction, it is not sure that the transactions retrieve the correct data. Indeed, the testing phase of the transactions, in the development process, is often ignored. Therefore, there is a need for testing techniques and tools. This paper proposes an architecture, a design, and an implementation of a tester, we refer to as DBSoft, to test transactions, in terms of required data they need to access. The architecture of DBSoft is a layered one. It is made of five components having separate concerns and serving each other: (C1) a parser to collect information, specifically for the metadata, (C2) an input generator to generate test cases, (C3) an output generator to implement the test cases, (C4) an output validator to validate test cases, and (C5) a report generator to generate test reports. DBSoft aims at avoiding cost effective transaction run-time errors.
AB - Databases (DBs) are used in all enterprise transactions, which require attention not only to the consistency of DB, but also to existence, accuracy and correctness of data required by the transactions. While the Atomicity, Consistency, Isolation, and Durability (ACID) properties of a transaction ensure that DB is consistent after the execution of each transaction, it is not sure that the transactions retrieve the correct data. Indeed, the testing phase of the transactions, in the development process, is often ignored. Therefore, there is a need for testing techniques and tools. This paper proposes an architecture, a design, and an implementation of a tester, we refer to as DBSoft, to test transactions, in terms of required data they need to access. The architecture of DBSoft is a layered one. It is made of five components having separate concerns and serving each other: (C1) a parser to collect information, specifically for the metadata, (C2) an input generator to generate test cases, (C3) an output generator to implement the test cases, (C4) an output validator to validate test cases, and (C5) a report generator to generate test reports. DBSoft aims at avoiding cost effective transaction run-time errors.
KW - Databases
KW - Metadata
KW - Testing Tools
KW - Transactions
KW - XML
UR - http://www.scopus.com/inward/record.url?scp=84883565079&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=84883565079&partnerID=8YFLogxK
U2 - 10.4304/jetwi.5.3.205-212
DO - 10.4304/jetwi.5.3.205-212
M3 - Article
AN - SCOPUS:84883565079
SN - 1798-0461
VL - 5
SP - 205
EP - 212
JO - Journal of Emerging Technologies in Web Intelligence
JF - Journal of Emerging Technologies in Web Intelligence
IS - 3
ER -