Every quarter we release a new version of our application. Before we end the (often late) night of installing, we check our application out in production on all 80+ instances of our app to make sure it works. We used to use QTP for this, but because of QTPs serial nature it took a long time, so we're going parallel on our production checkout with Loadrunner. We'll check everything out all at once with 80+ vusers.
Problem is that because this is a production system, putting a production password into a script is not cool. To circumvent that, I can encrypt the password using Mercury's password encryption tool that comes with vugen (that's what I'm currently doing)... but I have some reservations about that.
If Mercury uses the same algorithm for QTP and LR, one could easily ... SNIP, SNIP, SNIP ... well, you know what ... I'm not even going to get into the details for obvious reasons, but I think you know what I'm getting at here.
1) What are your thoughts on the security of the password encoder?
2) Does anyone have any alternatives? In QTP there's an option to flash a password box at the beginning of a script, but that's not available in LR AFAIK.
Ultimately, I think it'll come down to the fact that whoever kicks the script off will have to manually input their password every time, but since I'm the only one that knows vugen, I think I'll be having late nights once a quarter from now on... Just figured I'd check to make sure there's something I'm not aware of here.
You need to create test user accounts on your production system. These accounts need to be special in that they can do only what they need to do, and are prohibited from accessing anything real. Your concern about passwords are very correct.
It might be possible to create (modify on subsequent runs) your production users by a database script, and have the usernames and passwords generated dynamically. Then query those users for username/password pairs and then use them as input. This will give you unique passwords each time you run your LR scripts.
Following execution, run a similar process to scramble the passwords on production so that the input file can not be used for nefarious purposes. As an extra layer of protection, you may be able to set the status of those users to some state other than active, provided your schema and application allow for this.
on a similar note I never really understood the utility of lr_decrypt.. if the script is being viewed in VuGen (and anyone can download / procure a copy of it) they can reset the encrypted value.. so what exactly is being protected there? just someone accessing the .c files in notepad?