| || |
Verifying database records inaccessible in AUT
Would like to ask your thoughts/opinions on the following items:
1. How would you verify inserted database records when your AUT only displays the records as read-only and no other options such as "copying to the Clipboard" is provided? The only way I know of is to use the DBTester functions. Any others?
2. When working with huge amount of data, hundreds or more, how do you go by verifying whether all the data you inserted or modified are correct? Do you verify all records or just select a few (for example, out of 100 inserted records, you just select and verify record #1, #50, #100)?
Please give example(s) if possible...
Thanks in advance!
Re: Verifying database records inaccessible in AUT
In answer to your first point, verifying through the dbtester functions is invaluable to us; our aut is almost completely built around the database tables, and so being able to verify these (independently of the aut) is essential to testing really.
Second point: tricky. Unless you have a small enough database that a single verification with the dbtester functions is very fast indeed (which seems unlikely, as you are talking about hundreds of records being added at a time), it is not practical to try and verify every value in every entry.
Shortcuts you might want to consider could be:
- Checking that the right number of records have been added (using the syntax "select count(*) from ..." before and after the records have been inserted).
- Using any kinds of data consistency checks built into your aut (we have plenty of these, due to many many data-corrupting bugs having been released in the past).
- Writing such data-consistency checks yourself, using the dbtester functions. For example in an accounting database where there will be a record in one table for an account, and that record has a balance field, then it is possible to confirm that this balance is equal to the sum of all the debits and credits in that account (these fund movements being stored in some different database table).
- Checking selected fields on every new record inserted; for example, if there is a sequence number field that should have a unique value for each record, then you could have a routine to read these in from the new records and confirm that they are all unique and consecutive.
- Checking (completely) a small but representative sample of the records inserted. This will depend on what the data is that is being inserted, but something like what you suggest (the first, the last, and one or a few inbetween) wouldn't be a bad way to start thinking about it.
Basically, you have to follow standard test-plan procedure; admit that you can't practically test exhaustively, and then plan a few tests that you can do, with the resources available to you, so as to try and catch all the big bugs that are likely to appear. A combination of a few different techniques such as those I suggested would probably do the job.