The functionality of the database is one of the most critical aspects of your application quality, problems with the database could cause data loss or safety, in May and put your company at legal risk, according the type of data you store.
Most multi-user applications today use a form of persistence, and most often, that the persistence is done using a system of relational databases (RDBMS) such as Oracle, SQL Server, MySQL or DB2. This article will discuss a fast and easy test that can begin to make "gray area" or "white box" against the bases of test data in their application, enabling them to more easily discover the problems with the basis of data.
Referential Integrity:
As its name suggests, relational databases store data as well as information on the relationships between different data. Data records frequently contain references to other data records in other tables. Maintaining the integrity of these relationships is essential, if the relationship between the data are disaggregated, the function of your application may be compromised.
Database developers use a number of tools for referential integrity, including the constraints (rules in the database that require updated references), triggers (procedures that are "triggered" by changes to data) and the application code (logic contained in the application that describes how to manipulate the data).
According to the methods of your database developers have used the database will be vulnerable to different types of referential integrity issues. The constraints are the most effective way to maintain integrity, since the database will prevent anyone from making changes that will break the integrity. Maintaining referential integrity by the application code is the most risky (but also more flexible), since you are relying on the developers to code each change correctly.
As a tester, the first thing to do is how referential integrity is maintained in your database. One of the best ways to achieve this is through a scheme, which is a visual diagram of all tables in the database. You can ask your database administrator (DBA) or the development team a scheme, or you can create one using tools like Visio.
Security:
There are a number of ways that the security of the database is maintained. The most common are the means by usernames and passwords, or via integration with LDAP, such as. Some key issues to consider are:
• Does each user request a password for the database, or with a shared database for all users of the application?
• What level of authorization of the account (s) used to access the database?
• What is the interface used to manage the accounts used to access the database? What other ways are there to access the database using the same information that the application?
The best resources for checking the security of your database are the developers / database administrators, and management tools provided by your RDBMS. Developers can tell you how the database is accessible, and the RDBMS can provide information about the privileges associated with your accounting application uses.
Interfaces
Given the complexity of applications, data must pass between one or more (usually more) interfaces. Some of the typical interface between the user to enter data or reading, and the database of May include, but are not limited to:
• Graphical user interfaces (GUI) on the web or desktop
• Java, COM or. Net classes
• Web Services
• Screen-scraping a legacy mainframe application
• Application programming interfaces (APIs) to access the database, such as ODBC, JDBC, OLE DB and
Bugs can be introduced to one of these interfaces, regardless of whether you are reading, writing, updating or deleting data.
Testing the interaction between all these interfaces can be very complex, but I would say that at least you have:
1. Include all the data interfaces that passes through, between the user and database.
2. Learn more about the technologies used to implement each interface, and any bugs are due to the interface.
Data Formats
Data in a database entry from May and be posted on a number of different types of systems, including Web applications, desktop applications and handheld devices. Each of these types of systems unique limitations, may dictate how data must be stored and / or formatting in your database.
Again, you can test data for each of the interfaces, but it requires programming in May. At a minimum, you should be able to identify all the formats used to transfer data between each interface, and understand some of the fundamental limitations of the technologies used. This will create better test cases, smarter and analyze data related to bugs that appear during testing or pop up in production.
Conclusion
Database testing is one of the most difficult tasks facing a team of software quality assurance. At a minimum, team members must understand the referential integrity and database security, and have a good knowledge about different technologies and data formats used to transfer data between the user and the base of data.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
