Re: How do I test a database?

In article <5lshdr$kvr@cssun.mathcs.emory.edu>, ontop <ontop@worldnet.att.net> writes >John Jensen wrote: > >> Hey Guys. >> I am trying to develop a test plan for and informix data >> base. I am not >> trying to test informix itself but I need to see if our developers >> have set >> it up correctly. Does any body have any ideas on what I need to >> look at? > >1. Do your constraints make sense and are they working like you want >them to? >2. Check the definition of and data type of each column in each table >after installation? >3. Is this a custom, one time installation or something that is going >to be duplicated elsewhere? > If it's to be duplicated, test the install. >4. What is the purpose of the database? What's it to be used for? >Does it have a lot of custom user interface? Each user interface has to >be tested and the interaction of different interfaces tested against >each other? Do they put the data in correctly? Is it retrieved and >displayed correctly? >5. If this system has a specific purpose, for instance accounting, you >have to run the various accounting modules and verify that the output >matches expectations. >6. Check the purpose and use of each stored procedure. >7. Are the key fields defined in indexes correctly? >8. Are there batch level transactions being fed into the database? Does >the program to do this work? >9. Is the data being exported to anyone? Is it correct? >10. Can users access their data? Is critical data protected? >11. Can critical data be modified by incorrect users? >12. Does the archive and retrieval work correctly? >13. Can the system recover from a crash or a lockup? >14. Do you have the administration tools working? > >Frankly, this is such an open ended question I hardly know what to say. >I see testing as an integral part of requirement gathering and system >design. I like testers to be involved in each phase and I want them to >be enough of a developer to be able to envision those parts of a system >that will need particular attention. Interfaces of all kinds seem to be >particular bugaboos. With the testers involved in the design "bull >sessions" they see and hear first hand how things are going together and >can design tests to fit those situations. In this way the tests are in >place before the system is built since the test plan develops along with >the system design. All documents are living to me, so things can >change. > >Now if you are at the other end of the spectrum and have to test after >the fact. I don't happen to think anything is going to replace fairly >long hours of studying the schema and the applications for what it is >and what they do. Then you design tests to see if they do that. > >I have taken some fine courses on software testing design and >implementation. I like Boris Beizers' book on Software Testing >Techniques and a course by the Software Practices Research Center called >STEP. The center is in Jacksonville. While these courses don't address >databases only they provide a foundation for building a methodology. >Good Luck. :) > I agree! You need to check everything has been installed correctly and that the right versions of everything has been installed. Then run each program against the latest version of the specification. This can be very tedious (out product has > 200 programs) sooooooo.... Realistically (rather then spend > 1 year testing the new system) we generally a)_Use dbshema to Take the latest database schema from the development area and use it to create the database on-site. b) Take the latest code from SCCS (in checked in and tested (a bit) code) and install/compile on-site. c) Run through installation checklist and make sure any tables which need reference data in them have been loaded. d) Use checklist to setup anything outside the database E.g. scripts to allow users to access the live/demo environment, directories etc have been created/ have correct security settings. e) We run a couple of hours worth of testing i.e. run simple test cases, take a job through the system, run main reports. i.e. common things the users do which we know from experience are the most used parts of the system f) Let the users play with , I mean test it and fix whatever they find. Just put a programmer (i.e. me) on site for 2-3 days to fix any critical problems when they go live. At the end of the second day get a list of what's left to fix and prioritize it. Then have 2 programmers fix whatever was found until all critical /major things have been fixed. Minor/cosmetic things can go onto the normal queue of support calls. or is that too close to the truth.... -- David Williams