Response times and other performance measurements will be greatly affected by what pages are requested, what forms are submitted, and what buttons are clicked during a load test. Thus, a key aspect of being a good load tester is the ability to create test scenarios well.

How should you develop test cases? Hopefully this post will give you some useful suggestions you can put into practice.

The primary purpose of load testing is usually to find bottlenecks that decrease performance, and then mitigate or eliminate those bottlenecks. CEOs, CTOs, Vice Presidents of Marketing, and Product Managers want to make sure customers are not impacted negatively when the site is very successful. As developers, we need to make the app fast and efficient. We need to make the customer happy which makes our boss happy. If we run load tests that produce results that have no correlation to what happens in production, then our tests are failures. The test metrics are useless. No value is gained by the process. We have wasted our time.

It is important to simulate realistic behavior by virtual users and in the appropriate proportions because the performance of your system will be affected by not only the increase in load, but also in the types of processing needed to deliver the responses. Each page can have significant differences in resources needed to satisfy the user's request. So if you run a load test that hits your home page 100,000 times per hour, you probably won't answer many performance questions about your e-commerce application. The home page might have some images and Flash videos, but I suspect it won't make any complex queries against your database. Realistic load testing needs to trigger the interaction between your various layers of architecture in order to find the bottlenecks that will decrease performance.