5 Essential Tips When Starting Load Testing

Developing a web or mobile application takes a lot of effort, but all that effort can go down the drain quickly if you improperly load test the application or completely skip testing. Load testing applications is important and a necessary step in the pre-production stage.

New applications, ones that have not yet made it to the production stage, likely don’t have a performance benchmark established. You don’t typically know what to expect with a new app, which is why before you do a larger load test on any application you first do some baseline testing. This will allow you to establish some benchmarks and pick out any performance issues before you place a larger load on the app. For example, if your app crashes with just five users, you have a problem. Look to the application architects to determine if any service level agreements have been set for the application during design.

Once you have done some baseline testing you are ready to load test your application to determine its performance levels under heavier load. Here are 5 essential tips for starting load testing on an application.

1. Calculate the number of users

When you load test you have to determine the number of virtual users you wish to simulate. There are a few ways to calculate the number of concurrent users needed to generate proper load on your application. The calculator we use for estimation takes into account three variables:

  • Number of pages viewed per hour (PPH) – this figure can be extracted from your Web server’s log file
  • Number of pages viewed per user (PPU) – that is to say the number of pages in a representative test case
  • User duration in minutes (UD)

That formula looks like this:

# of virtual users required = ((PPH / PPU) / 60) * UD

Keep in mind this basic calculation assumes a constant load over an hour meaning it does not take into account things like load ramping or traffic spikes, so you’ll need more virtual users when testing with these conditions.

Before you go ahead and throw on the max number of users to generate load on your application consider this: if the application performance is bad for a small number of users, then of course performance will be dismal for a large number of users. Run a small test first to find any bugs or bottlenecks that can be found at small volumes. Once the application performs well with a small number of users, add more.

2. Get others involved

When you are load testing, it’s important to collaborate and communicate across three departments: the testing side, development side and operations side. These three groups all have valuable information that needs to be shared among each other in order to complete a successful load test.

For example, testers may not know much about the application’s code, so someone from development needs to inform them of any changes to code when they test the application. If a person from operations isn’t involved from the beginning, then testers may not have the analytics of the application from the production environment. Involving all three of these groups will create a stronger team dynamic that will result in an accurate depiction of the application performance.

3. Determine your test cases

In order to know what test cases to implement, you need to understand the paths that users are taking through your application. Crack open your site analytics, your app analytics, and the log files from your web server. Study how users are traversing through the application – as well as how many there are, where they are coming from geographically, and the types of browsers and devices they use.

It’s important to put this data in the context of your application architecture, so that you can pinpoint bottlenecks and develop a comprehensive set of tests to exercise them. Once you assemble this information together, you can create a test plan that simulates observed behavior using virtual users on emulated and/or physical devices and across geographic regions, so you can see how your application performs under a somewhat realistic load.

4. You can’t make assumptions with an inexact testing environment

The most common questions we get from customers are: Can I extrapolate results based on smaller number of users? Can I extrapolate the results in the testing environment with a smaller proportional number of servers to the production environment? Can I assume the performance results from an inexact testing environment apply to my production environment?

The short answer is no. There is a nonlinear relationship between the testing environment and the production environment if the testing environment is not an exact mirror of production, but mirroring production exactly with the same infrastructure and configuration can be quite expensive.

So what’s the solution? The truth is that you want to make your tests as realistic as possible, but no test will ever be perfect. Remember that the goal of testing is to minimize risks. You can still find and fix performance issues in an inexact testing environment, and for those who can get permission to do so, testing in production on off hours may provide even more accurate results than a mirrored testing environment.

5. Take time to analyze your results

Load and performance testing is typically one of the last steps in most development cycles and is often rushed as a result. This means that testers may gather a heap of performance metrics that are often overlooked because of a looming deadline.

Results analysis is important to do properly because you are able to pinpoint smaller issues in your application or the infrastructure itself. Don’t cut out the analytics; take the time get to the root cause of issues from build to build before they snowball out of control.

Load test for the sake of your users

Load testing should be seen as a necessary step in the testing of your applications’ performance for your users, so take the time to find the best tool for you. If you have any questions, contact our performance experts; they’d be happy to help.

Leave a Reply

Your email address will not be published. Required fields are marked *