Making it Real: Emulate Real-Life Conditions in Your Load Tests

Whether it’s an elementary school math quiz, a college history exam, or a software development team’s load test, we always want our tests to emulate real-life conditions. Otherwise, what’s the point of testing?

In this blog, part three of my four-part series on load testing, I want to focus on ways you can ensure your load tests match reality. Part one broke down the all-important prep work, and part two was about recording scenarios—now it’s time to test.

Some of the best perks about our free load testing tool, LoadUIWeb, are the settings that aid the process of generating a realistic load test. Of course, like all load testing tools, you can specify the number of virtual users to be simulated, but you can also set certain conditions that easily create more powerful and reliable load tests. No matter which load testing tool you choose, make sure it allows you to set some version of these basic conditions.

• Ramping Up Virtual Users. When running performance tests, it’s not desirable to start all virtual users at the same time. Starting all virtual users at the same time can create artificial bottlenecks in certain parts of the application – such as the login process. In LoadUIWeb, you can elect to set a load profile whereby you start with a small number of virtual users, and increase that number over time. For example: you start with a single virtual user and add one virtual user every two seconds until you reach a certain number of simultaneous users, and then hold that number for the duration of the test.

• Setting Load Duration. In order for you to run a test with large numbers of virtual users, you will need to set duration for your test. By setting duration, each virtual user will execute its scenario and when it reaches the end it will start over – thereby maintaining the level of load. For example, if your scenario takes two minutes to be executed, but you run a test for 10 minutes, the scenario might be executed five times by each virtual user. This function can be found under the “continuous load” tab of the load profile in LoadUIWeb. Merely check the enable box, and set a time.

• Parameterizing Tests. While recording a scenario, you may need to specify some parameters that will be used for further test runs. For example, you can enter some search terms, user names and so on in the application’s fields. However, it is not a good practice to play back a test with the same recorded data for each user as it does not simulate the real-life conditions. To solve the problem, LoadUIWeb allows you to parameterize your load test using special variables. A variable can store desired data and your requests can use this data during test runs.

• Emulating browsers, network connection bandwidth and browsing speed. Real users visit a website using different browsers, the bandwidth of user’s Internet connections can vary significantly, and they spend different amounts of time on each page. You can configure all these parameters when creating load tests in LoadUIWeb. This means you can specify different browsers and connection bandwidth for different groups of virtual users. You can also specify think time for each tested page (we call this think time, as it simulates the time period when a user is viewing the page and thinking). You can easily randomize the think time for simulated scenarios to better emulate real user activity.

• Simulating concurrent requests. To download a Web page, modern Web browsers send requests to the server using several simultaneous connections. These parallel requests download images, scripts, CSS files and other resources located on the page. Unlike many other load testing tools, LoadUIWeb automatically detects and simulates parallel requests, that is, it sends requests exactly like your browser did when you recorded your scenario. This makes the simulation closer to real-world conditions.

Ok! That’s it. Be sure to come back next week for my final post of this series on analyzing data from load tests, and feel free to leave me questions and comments.

 See also:

• Improve Your Open Source Project Adoption by Catering to Integrators
• Twitter is Not a Production Manager – Monitor Your Own APIs for Free
• 9 Tips to Prepare Your App for Optimal Load Testing