I have an application where user enter username and password.
Now i want to check the validation of user name and password using the database runtime record check.
when i test only for user name, its working great.
when i test for password, it fails..
Reason for this is... Password in the database is encripted.
and the password i type in the application is ********.
what is the procedure to test the password field against the database.
You will have to figure out a way to unencrypt the password to do that, but then I think you are making the test too hard......
Why do you need to test it against the database for many records? If you have an entry in the database where you have a known user, and a known password for that user, if you are able to log into the application you know the application is handling the encrypted password correctly.
If you have two known users and passwords, and you are able to design a test that will log in with the first, then confirm, log out and log back in with the second, then I would think you have confirmed the system is working in relation to the passwords being stored.
[ QUOTE ]
[ QUOTE ]
..using the database runtime record check.
[/ QUOTE ]
Do you mean using the Database Checkpoint? That isn't going to work, unless you include the encryption algorithm in the script so you can compare like to like.
[/ QUOTE ]You wouldn't need the encryption algorithm in the script - you would just need to use the encrypted password as the expected result in the database checkpoint.
As Tony said, however, what's the point? Taking it one step further, what's the point in data base checkpoints in general? I can see the need to pull data from the database for one reason or another, but I've never plugged in a database checkpoint. In general, the databse is transparent to the end user, and developers like to make schema changes. The only exception I can come up with is if the AUT is a database program.
Well - true - as long as you don't mind storing encrypted passwords somewhere.
You prompted me to say what I almost wrote before "I hate all checkpoints" (sorry, Bob). Well, not really "hate" - just find them more trouble than they are worth. I guess they are a sop to those who don't want to write code (and a means by which salesmen can say "see? It's all record/playback - no programming required!")