Welcome!

Continuous Integration, Continuous Delivery & Continuous Testing

Tim Hinds

Subscribe to Tim Hinds: eMailAlertsEmail Alerts
Get Tim Hinds via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Application Performance Management (APM), DevOps Journal

Article

How to Create the Most Realistic Load Tests | @DevOpsSummit #DevOps

The whole point of performance testing is to know that your app can handle whatever is thrown at it

You may have heard the phrase, "You've got to fake it till you make it."

Not with load testing.

Performance testing is one of the most important things you can do when building a web or mobile app, and it's only becoming more vital as the expectations of users are going up. People demand access to anything, anywhere, anytime, and they'll switch to a competitive solution if the app they're trying to use is slow or clunky.

Performance is critical to the success of your web and mobile apps - and will be for a long time in the future. It's not a matter of if you have to do it. It's about how to do it best.

So, how do you do it best? You make your test scenarios as real as possible. If you have ever listened to the performance testing horror stories from Brad Stoner, you've heard the importance of realistic testing scenarios

Why Is Realism So Important?
The whole point of performance testing is to know that your app can handle whatever is thrown at it. But application architecture, and in particular application delivery, is very complex. There are a lot of variables that impact the user's ultimate experience. Some are more obvious, like the specific device in use, or the task the user is trying to accomplish. Others are less apparent, hidden under abstraction layers or deep in the network layer.

You'll also want to consider the impact of other software running on the platform, the local environment, the ISP, and more. Not to mention the effect of 3rd-party services integrated with the app.

The list goes on. If your performance tests are overly simple, it means you aren't testing places that could impact the experience. It's like only testing a car on an empty highway and not taking the realities of street driving into account: potholes, traffic, other drivers, or suddenly-appearing pedestrians. Without realistic tests, you are not preparing for scenarios that are likely to happen and will be detrimental to your users (and your business). Plus you will be wasting a ton of time, effort, and money on useless tests.

So we've decided to put together a few ways that will show you how you can make your performance testing more realistic.

Don't Fake It - Realistic Load Test Scenarios Should Include...
Geography

Geographically speaking, where are your users? What are the predominant regions and how are people distributed between then? A user's geographic location plays a very important role in the experience they have and includes many factors that allow you to simulate load. The number of hops and the backbone speeds in the path between the website and the client system are just a couple of attributes involved in determining how fast packets will travel and how many packets are dropped.

Geographic diversity also shows you a range of user experience patterns, since people around the world may behave differently, especially when it comes to how people use desktops versus phones. Another important benefit of geographically dispersed load testing is the ability to distribute load across lots of places so your servers are handling traffic from a broader range of endpoints. Finally, using 3rd party locations forces you to execute your load tests outside of your data center, so they exercise the full data pathway from device to server.

Devices and Browsers
The web browser is the key blind spot for gaining true end-to-end visibility into application performance. Increased usage of client-side scripting means you must monitor the processing that takes place within the browser. It's the only way to get full visibility into performance. Browser test cases measure events that happen in the rendered page and are visible to the user. They can even measure things like: "After the user does A, how long does it take for button B to become enabled?"

Furthermore, you should monitor devices. Why? Because the variability in devices is growing rapidly. You need to look for software changes in each device and monitor their evolution and updates, which also impact performance. Here's the bottom line: With a little effort and maintenance, you can accurately find out if any clients are reacting poorly to your code, and work flexibly with your product to fix browser- or device-specific issues.

User Behavior
Accurately recreating the way users interact with your site is a key part of building realistic load tests. This usually starts with how you record scenarios in the first place. As users traverse through the app, you'll capture their clicks and form submissions and use this stream as the basis for future load tests. When you do this, you need to make sure the recording is parameterized in a way so that variables are randomized and represent what happens most often for people. All scenarios must be designed to be representative, replaying scenarios accurately with all the elements of users experience like popups or interruptions. So for example, if the user you are recording waits 10 seconds to click a button, you could turn this into a parameter that randomly waits between 5 and 20 seconds.

For even more realism, use Google Analytics to get a sense of the variability of parameters in actual users. While recording a scenario, you may need to specify some parameters that will be used for further test runs to help with repeatability. It is not a good practice to play back a test with the exact same recorded data for each user because it does not simulate real-life conditions. You should load test using special variables and store the desired data. Your requests can use this data during test runs.

User Paths
Sometimes, testers only test a limited set of paths through the application. This is often due to a limitation of the load testing software they are using. Take, for example, a chat window. This is small component on a typical web-based application, and as such, it's a part of the app that rarely gets tested. Other examples include infrastructure packages like Java Messaging Service or 3rd-party services like ad networks. If your load testing software doesn't help you incorporate these elements, you may have no idea how long those ads are making your users wait.

From the developer perspective, these experiences are somewhat separated from the application. But, this is not the case from the user's perspective. Think comprehensively about the way a user navigates through the app. Also talk to users. Ask about frustrations. This may lead to insights about how to build your performance tests with more realism.

Network Behavior
Knowledge about network latency and bandwidth is needed for any application that isn't local, because bumps and burps in the network can have a real adverse impact on your users. Monitoring network bandwidth and web application performance from multiple locations helps isolate problems in the network tier.

Bandwidth bottlenecks cause network queues to develop and data to be lost, impacting the performance of applications. This is especially true for mobile and cloud apps. High jitter, increased latency, and packet loss all work to degrade application performance. Use emulators and other monitoring functions to get a picture of the range of network characteristics. Then build that behavior directly into your load tests. Use your load testing platform to actually introduce network problems that users typically encounter, so you know what happens when they do.

Connection Parameters
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. Different devices and browsers maintain different policies about how many concurrent requests are allowed. For example, phones generally restrict more than desktops or laptops do. You'll need to simulate an appropriate number of parallel requests during your tests. For example, if you are running an emulated mobile test from a server-based load simulator, make sure to set up some connection limitations. Try to send requests exactly like your browser did when you recorded your scenario. This makes the simulation all the more closer to real-world conditions.

Welcome to the Real World
It all boils down to one thing: keeping it real is paramount to load testing. We've given you a list of attributes to consider so that you can represent what actually happens for most users. If you can simulate what a user is most likely to experience, you'll be a step ahead of the game. With the rising demand for perfection in web application performance, there's no replacement for realistic load testing.

Image Credit: Jean-Etienne Minh-Duy Poirrier

More Stories By Tim Hinds

Tim Hinds is the Product Marketing Manager for NeoLoad at Neotys. He has a background in Agile software development, Scrum, Kanban, Continuous Integration, Continuous Delivery, and Continuous Testing practices.

Previously, Tim was Product Marketing Manager at AccuRev, a company acquired by Micro Focus, where he worked with software configuration management, issue tracking, Agile project management, continuous integration, workflow automation, and distributed version control systems.