Checklist for Designing Better Performance Test Scripts

Make sure the script doesn’t contain incorrect or extraneous URLs. The urls specified should be in correct sequence.

• It might be possible while recording, script writer would have gone to his / her popular website.
• It can be validated by using test tool’s “playback” feature to confirm what the script actually does.

Identify all dynamic data (as the response from server) present in a script and correlate it.

• Usually it can be found by recording scripts two times and making comparisons between them.

Parameterize scripts to support dynamic data set.

• In presence of dynamic data, every simulated user exercises the exact same path but avoids responses from the cache and exercises database interactions properly.

Use proper checkpoint(s) / assertion(s) for all steps involved in the transaction.

• Absence of checkpoint might result in better response time when a page is not getting downloaded completely / correctly.
• Text used for assertion should be either static or should be consistent accross all runs / environments. If this is not done properly, scripts maintainence becomes an overhead. For example, if name of top selling car used as assertion, the script might start failing after few days once top selling car name changes.

Confirm if your performance test tool handles cookies automatically.

• If the website under test set cookies, these cookies might appear in the recorded scripts and it needs to be handled explicitly by script designer by using variable. The variable allows the script to receive a different cookie value during the test, rather than using the recorded value.
• Cookie substitution is must if the site uses HTTP session cookies from an application server.

Check the think time and pacing time in the script.

• It is not recommended to use the constant think time value for every step or for each user.
• Check if your tool supports distributing think time values in a range instead.
• The think time value & pacing time value should be planned and finalized during performance requirement gathering phase.

Users rarely log out of web site, so don’t assume the same and design scripts accordingly.

• Logging out every time, might clear http session information from the cache sooner than actual.

Verify the scripts during design time

• Validate it with one iteration and one user
• Validate it with multiple iterations and one user
• Validate it with multiple iterations with multiple concurrent users

Scripts should be written in a way so that it can be executed against multiple environments without any significant changes

• Different environments can be test, stress, pre-production etc.

Consider building scripts for the primitive paths first

• It helps in easy troubleshooting and optimization

Final scripts should be representative of actual user activities.

• Should not be too simple and too focused, until is it really required.

Look out for re-usability while designing the scripts.

• Develop simple scripts to build more complex scripts and scenarios.
• All simple scripts should be atomic in nature.

Follow standard naming conventions and folder structures.

• Resist temptation of using default values (e.g dir path, log file location) provided by tool(s). Understand the consequence of each setting and then apply it
• Helps in readability and reviewing of scripts