From time to time, on the Professional Services team, we come across customers who aren’t quite sure what to test on their website. They only know that they need to test their infrastructure, prior to an application launch, an upcoming busy season, or release of new code.
There are a few factors that need to be considered when coming up with the proper scenarios.
- What scenarios are critical to your business?
- What scenario do users run through the most?
- Would the scenario be considered simple or complex?
Typically, you will want to test your most critical and frequent scenarios, but you also need to take into account how complex it is for a user or a script to follow the flow. If the scenario is extremely complex, you may receive false positives of errors and it would most likely take longer to script. In my experience working with our customers, many initial load tests first uncover issues related to server configuration and infrastructure rather than strict code optimization issues.
Once you have decided which scenarios you will be utilizing, the next step is to figure out the distribution of load for each scenario. This can be very important since applying too much load to a specific section of the web application can skew the results. For example, if a database is typically only being requested 10% of the time, and you run a test where the database is being hit 25% of the time, the results won’t be as accurate as if you ran a test with only 10% of the load.
After the load distribution is figured out, the next step is to come up with realistic page think times. A script is able to run through a website much faster than any real user could. Many times, our customers will think it is OK to test their application with zero or extremely low page think times. The problem with this philosophy is the amount of page requests per second will be greatly higher than with real users, resulting in increased load on the web infrastructure. It is ideal to add in realistic think times for each page, as this will let you know approximately how many real users your site can handle.
The last pieces of advice I can provide is to start testing early in the development cycle as it is easier and more cost effective to fix bugs during the development process than after the product has been released. You will also want to make sure to test often. Rather small changes to the application’s code or server configurations can produce unfavorable results once the site is under load.
In conclusion, you need to figure out the proper scenarios based on how critical they are to your business, frequency, and complexity. Make sure to mimic the scenario frequency when performing the load test by defining how many users should run each scenario. You then want to ensure you have realistic page think times between each request to properly mimic real user interaction. Test early and test often! Learn more about Webmetrics Load Testing Services.
Comments are closed.