Quick Load Test
Not all load tests required the same setup, planning, execution or analysis time. A classic example of a 'quick' load test one that simply logs in as a user of that application. For example, a workflow application may still be under development, and may only exist in a low grade test environment, but the login functionality may be operational.
A quick load test may involve a few minutes to record a simple login script, with a few more minutes required to load it with a number of user ids. The test parameters could be something like the following:
This test would take approximately 30 minutes to run, would peak at 2 logins per second, and would have a good chance of identifying any serious performance issues with the login process in a fraction of a day. The alternative to running such a simple test early in the life of the project is to run a more comprehensive test much later in the project. However, if there was a serious problem with concurrent logins at that point, then the problems arising from slow login behavior would limit the effectiveness of the load test, as the expected login rate would not be achieved. This could have a ripple on effect for the project as the login problems would need to be fixed before the required load could be generated.
The philosophy behind running 'quick' load tests is to validate solution components as early as possible, with the least effort possible, as the cumulative effort of all such tests should be much less than the wasted effort that can be reasonably expected if problems exist and no early 'quick' load tests have been executed.
A quick load test may involve a few minutes to record a simple login script, with a few more minutes required to load it with a number of user ids. The test parameters could be something like the following:
- Gradually increase users from zero to 50, adding 1 user each 30 seconds and then run for 5 minutes
- Each user could be configured with random iteration pacing from 17 to 33 seconds. (average pacing of 25 seconds)
- Each user could be configured to start clear cache and start a new session on each iteration.
This test would take approximately 30 minutes to run, would peak at 2 logins per second, and would have a good chance of identifying any serious performance issues with the login process in a fraction of a day. The alternative to running such a simple test early in the life of the project is to run a more comprehensive test much later in the project. However, if there was a serious problem with concurrent logins at that point, then the problems arising from slow login behavior would limit the effectiveness of the load test, as the expected login rate would not be achieved. This could have a ripple on effect for the project as the login problems would need to be fixed before the required load could be generated.
The philosophy behind running 'quick' load tests is to validate solution components as early as possible, with the least effort possible, as the cumulative effort of all such tests should be much less than the wasted effort that can be reasonably expected if problems exist and no early 'quick' load tests have been executed.