|
链接请见:
http://www.logigear.com/newslett ... abase_testing-1.asp
Jesse Watkins-Gibbs, Project Manager, LogiGear Corporation
Most multi-user applications today use some form of persistence, and more often than not, that persistence is done using a relational database management system (RDBMS), such as Oracle, SQL Server, MySQL, or DB2. This article will discuss some quick and easy ways that a tester can start to perform 'grey box' or 'white box' testing against the databases in their application, which will allow them to more easily uncover problems with the database.
Functionality of the database is one of the most critical aspects of your application's quality; problems with the database could lead to data loss or security breaches, and may put your company at legal risk depending on the type of data you are storing.
Considering how important the database is to the success of applications, it is surprising how little attention is focused on database testing. In my experience, the biggest barrier is that most testers simply don't have time to directly test the database, so they end up focusing their testing efforts on testing via the GUI.
Part 1 of this article will introduce the concepts of referential integrity and security, and discuss some tools and techniques for testing them. Part 2 of the article will address additional topics.
Referential Integrity:
As the name implies, relational databases store data as well as information about the relationships between various data. Data records will often contain references to other data records in other tables. Maintaining integrity of these relationships is critical; if relationships between data become broken, the function of your application could be compromised.
Database developers use a number of different tools to provide referential integrity including constraints (rules within the database which require references to be maintained), triggers (processes which are 'triggered' by changes to specific data) and application code (logic contained in the application which describes how to manipulate the data).
Depending on which methods your database developers have used, the database will be vulnerable to different sorts of referential integrity issues. Constraints are the most effective way to maintain integrity, since the RDBMS will prevent anyone from making changes that will break integrity. Maintaining referential integrity via application code is the most risky (but also most flexible) approach, since you are relying on the programmers' code to make every modification correctly.
As a tester, the first thing to do is find out how referential integrity is being maintained in your database. One of the best ways to do this is via a schema, which is a visual diagram of all the tables in the database. You can ask your database administrator (DBA) or the development team for a schema, or you can create one yourself via tools like Visio.
The tools used by the developers and/or DBA to create the database will also show you any constraints and triggers used in the database, and are usually pretty easy to set up.
Once you know how integrity is being maintained, you can then begin to analyze how it could be broken, and what the risks are in your application. For instance, if your application relies on the application code to maintain integrity, then you will want to make sure that every piece of code that modifies the data is thoroughly tested and doesn't introduce data integrity issues. If the application relies on triggers, then you will want to have tests which cause every trigger to be fired, and make sure that the data is being modified correctly by the triggers.
Security:
There are a number of ways that security of the database is maintained. The most common ways are via usernames and passwords, or via integration with a directory such as LDAP. Some of the key questions to consider are:
1、Does each user of the application have a separate password to the database, or is their a shared database account for all users of the application?
2、How much permission do the database accounts used by the users have within the database (read-only, read/write, administrative privileges)?
3、What interface is used to manage the accounts used to access the database? What other ways are there to access the database using the same login information as the application?
In practice, many applications require that each user has a different account at the application-level, but there is a single account shared by all users to access the database. As a tester, it's important to understand how the database is being accessed, with what level of permission, and to make sure that all stakeholders are aware of the risks being introduced via the chosen methods.
In practice, many applications require that each user has a different account at the application-level, but there is a single account shared by all users to access the database. As a tester, it's important to understand how the database is being accessed, with what level of permission, and to make sure that all stakeholders are aware of the risks being introduced via the chosen methods. |
|