Checklist for Designing Better Performance Test Scripts
- 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.
- Usually it can be found by recording scripts two times and making comparisons between them.
- In presence of dynamic data, every simulated user exercises the exact same path but avoids responses from the cache and exercises database interactions properly.
- 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.
- 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.
- 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.
- Logging out every time, might clear http session information from the cache sooner than actual.
- 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
- Different environments can be test, stress, pre-production etc.
- It helps in easy troubleshooting and optimization
- Should not be too simple and too focused, until is it really required.
- Develop simple scripts to build more complex scripts and scenarios.
- All simple scripts should be atomic in nature.
- 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
Comments
Post a Comment