Over the years, countless testers have mentioned that getting started with Load Testing is a daunting task. That’s why it’s often left until the last minute before launch. At Tricentis Flood, it’s our mission to make Load Testing less daunting and accessible to everyone. We want to give developers and testers an easy way to ensure that whatever part of the system they’re responsible for meets expectations for both functionality and performance.
That is why we are excited to launch a new load generation tool that we’ve been building in-house for the past six months. It’s called Flood Chrome, and it helps you build maintainable and performant load tests which run in real browsers. This greatly reduces the amount of time and complexity involved in placing a realistic load on your application.
We call this approach Browser Level Users or BLUs. It can be thought of as a higher level abstraction on Protocol Level Users (PLUs) – Load Testing only the network layer, as is done with tools like JMeter and Gatling.
As with programming, generating load at a higher level of abstraction reduces the cost of implementation and maintenance – ideally with little tradeoff on performance. To achieve this, we’ve developed a Selenium JS-compatible scripting language which drives a high-performance implementation of Google Chrome to generate load by interacting with your application in the exact same way as a real user does.
This means you can easily turn your existing Selenium functional tests into load tests without learning a new mental model for how to test your application. You can also create new tests with an extremely-minimal learning curve – even if you’re not well-versed with scripting.
Since it works at the browser level, you no longer need to script each individual network call. This makes your tests more resilient to application architecture changes which affect the network characteristics.
One of the biggest mistakes we see in performance testing is failure to create a realistic load scenario of your target users. This can be attributed to not using adequate sleep time between requests or thrashing a single endpoint without considering the load characteristics of a real user.
Both of these mistakes are eliminated with Browser Level User load testing because the ratio of network requests is directly correlated to real user actions.
Load Testing Single Page Applications
As the web platform matures, one trend that’s becoming hard to ignore is the move to Single Page Applications and Server Rendered SPAs. These applications typically load a User Interface shell and then initiate hundreds of network requests to an API in response to user interactions.
Load testing these types of applications at the Protocol Level can be extremely difficult. You not only need to deal with authentication and session management; you also need to create realistic load scenarios which remain realistic as the front-end develops. This often leads teams to ditch the effort entirely or treat it as a “best effort” to load test (not surprisingly, this rarely gets taken seriously).
Browser Level User Load Testing solves a number of these problems because the browser takes responsibility for authentication and session management – as well as initiating network requests.
More to measure
With Protocol Level Testing, we’re usually only concerned with the top level measurements (Response Time, Concurrency, and Transaction Rate) because these are easily understood on the wire. BLUs opens up entirely new measurements which directly impact the customer experience, including Time To First Interactive (TTFI) and script evaluation and execution time, which can be greater than the time it takes to load over the wire. We’ll be making these measurements available once Flood Chrome transitions out of beta.
Flood Chrome is now in public beta and available to all Flood customers. To help you get started, we’ve put together a step-by-step guide and API documentation for you to explore. Stay tuned for more resources in the coming days.
Stay connected– subscribe