This is a checklist I created listing some common things to look out for when creating performance scripts in LoadRunner’s Virtual User Generator (VUGEN).
Although it is written for LoadRunner VUGEN, most of the principles should apply to any performance test tool. These are the top things I like to check for after a script is created:
- When debugging a new script, turn on all the logging and verify that no errors are occurring.
- Make sure all dynamic values that need to be correlated are.
- For a sanity check, verify with a developer that the info that you are sending is indeed being processed correctly by the application. Even if your script ran without obvious errors, don’t assume that everything is okay.
- Add some text checks, like web_reg_find, before all web_url and web_submit_data functions. (The web_reg_find function is used to search for a text string on an HTML page.)
- Run the script in VUGEN in a loop and verify that you can send the same request multiple times without errors or warnings.
- Check that any parameters that you’ve set up in the Parameter List are using the correct “select next row” and “update value on” settings.
- Make sure all the important requests that need to be measured have a transaction, and the correct request(s) are enclosed with start and end transactions.
- Also make sure that your level of transactions is appropriate. For example, if you have a one big transaction, like “purchase book,” that is made up of many steps, you should break it down into smaller transactions. If you have just one transaction that takes 50 seconds, it’s difficult to determine which step is eating up most of your time. It’s easier to create smaller transactions to be able to see, for instance, that your “verify billing info” transaction is taking up 40 seconds of the main “purchase book” transaction.
- Verify that all known error messages are being handled with a ContentCheck Rule
- Verify that you don’t have think times inside your transactions
- Verify in the Controller that you can run your script with more than one user at a time. It’s usually a good idea to try and run your script with a small set of concurrent users – say, 3 to 5, to ensure there are no funky concurrent execution issues.