In this article, we will understand the concept of Load Testing for DevOps using Tricentis Flood Element Tool.
Load Testing is a very popular type of testing that all of us as testers have come across.
So, while thinking of load testing, you may be frustrated with the current solutions you are using and find it very difficult to write and maintain your tests.
You may even be thinking about doing load testing for the first time.
Either way, it’s a great first step to be thinking about load testing at all, which many companies don’t and suffer the consequences.
Table of Contents:
Load Testing Using Flood Element Tool
Overview
There’s an established link between app performance and other important business metrics, such as revenue, customer signups, and general customer satisfaction.
All companies that do business on the web need to ensure that their performance doesn’t negatively impact these key measures. Even when these measurements are improving, you might find that the app could run better to consume fewer resources, saving you and your user money along the way.
Whether you are brand new to load testing or if you have experience in the field, you might be likely aware of the dizzying array of tools and approaches that are available to get the job done.
Flood Element – An Excellent Load Testing Tool
Today I’d like to review a new favorite load testing tool – Tricentis Flood Element.
Many popular tools operate at the protocol level and they attempt to approximate the users’ behavior on your app by issuing network requests.
However, in today’s worldwide web, web apps are becoming more and more sophisticated and are as well as utilizing more of the browsers’ ever-growing list of features than ever before.
Even simple apps like an online shop use a plethora of browser features to make the experience of choosing items, ordering, and paying online as smooth as possible for a user.
Hence, in this era of the web, only protocol-level user (PLU) testing can give us the true picture of our app’s performance. In contrast, new tools like Flood Element, test by simulating user behavior using real web browsers.
We call this approach Browser Level Users (BLUs).
In Flood Element, simulated user behavior is defined using simple, natural actions such as clicking links & buttons, filling in web forms, and so on.
Once you have defined the behavior, it’s a snap to run at a huge scale at Flood – by huge scale, I mean thousands of users from all over the globe!
Load testing with Flood Elements can help you develop a holistic and intuitive view of your app’s performance as experienced by any user.
Considering ourselves as users, it’s also significantly easier to get started with an Element BLU test than with the traditional PLU tools.
BLUs help you to get a realistic view of your whole app’s performance, right from top to bottom. Whereas PLUs only test what’s under the waterline i.e. your network and server infrastructure.
A Holistic View
Using Flood Element to measure the performance of your whole app from the users’ perspective is a great way to develop a holistic view of your app’s performance and defend against the unexplained changes. There can be temporary anomalies or regressions in the code.
Flood Element BLU tests provide a view of the performance which is much closer to the user experience.
They consider each and every part of the performance that a user will experience: network performance, also on-page script performance as well as third-party scripts such as analytics or advertisement add-ins.
In fact, our tests are so realistic that you need to take steps not to create false data in Google Analytics.
If running a BLU load test with Element gives you a holistic view of your app’s performance at a point in time, then running tests regularly allows you to build up an intuition of whether your app is getting faster or slower, perhaps suddenly as in the signup widget scenario.
Getting Started with Flood Element: Writing a Test
Now let’s see how easy it is to get started with Flood Element.
Element scripts are written in TypeScript or modern JavaScript. For the best experience, we recommend using the awesome combination of TypeScript edited using VS Code.
It gives you a lot of useful assistance in developing your tests.
Install Flood Element
You can install Element using the getting started instructions here. Once installed, edit and test your script locally.
When you’re ready, upload it to Flood to perform a full-scale load test by signing up for a trial here.
The basic Element BLU test for the signup scenario above might look as shown below
If you’re familiar with testing at the protocol level, then you know that all timings are arranged around request-response transactions.
When learning to test at the browser level, there are a few additional subtleties to take into account when finessing your tests. In particular, there are no real built-in timing groupings, so we need to introduce our own timings in the structure of our test.
The simplest approach for grouping timings is to wait for the necessary elements to appear on the page just like a user would.
Based on the scenario given above, we’re interested in timing the user experience of signing up, but not as much as the loading of the page. So, in the first step, we simply visit the URL and wait for the page to reach a known state until the title is shown.
Next, we perform the action that we’re interested in keeping an eye on, which includes filling in and submitting the signup.
Now it’s time to save the script locally so that we can upload the script to Flood and run it with hundreds, or even thousands of concurrent users.
1) (If you haven’t already) sign up for the flood.
2) Create a Project
3) Click the “create flood” option in your new project
4) Create your test using the Flood Element Option
5) Name your test
6) Upload the .ts script that you have created
7) Set the number of browsers (users) as well as # of regions to get the total # of users (# of browsers * # of regions). Also, don’t forget to set your test duration.
8) Launch your test and wait for the results to come in.
9) Once results are in, view your graph and jump into any problem areas that they may highlight.
Conclusion
We hope by now, you are aware of why and how to test with Browser Level Users using Flood Elements.
With this new approach, we’ve eliminated the problem of creating load tests as well as made the results more realistic.
Tricentis Flood is a distributed load testing tool in the cloud that seamlessly integrates across the DevOps pipeline.
With this performance and Load testing tool, the entire team can now measure and improve the performance of an application.
It may seem daunting to get into testing with thousands of users, but it’s easy to take one step at a time:
- Download the element.
- Write a simple test locally, covering your key scenarios (i.e. checkout).
- Run the test locally with an “element run” to make sure that the test runs completely.
- Upload your test to Flood and run with 5-10% of your max load (i.e. if your max load is 5,000 users, start with 250-500 users).
- Assess the results and tweak your script and app as needed.
- Upload your test to Flood and run with 50-100% of your max load (i.e. if your max load is 5,000 users, then run with 2,500-5,000 users).
- Increase your test coverage to cover the additional scenarios required until you achieve the test coverage that you desire.
Depending on the complexity of your test scenario, you might be able to get up and running with thousands of users in under a day.
Get the Flood Element tool to start experimenting with load testing features.
Feel free to share your experience in the comments section below for our fellow testers. We would love to hear from you.
Sorry for asking question of another topic……am getting error “InternetExplorerDriver cannot be resolved to a type”……can anyone help whats wrong in the code
import org.openqa.selenium.WebDriver;
public class STH {
public static void main(String[] args)
{
System.setProperty(“webdriver.ie.driver”,”I:/TodaySeleniumSession_06-Jun-2018/iexploredriver.exe”);
WebDriver driver=new InternetExplorerDriver();
driver.get(“https://www.softwaretestinghelp.com/”);
driver.manage().window().maximize();
}
}
a nice share thank you worked..
System.setProperty is not declaring correct
This sounds interesting. Will give a try.