Recent Blogs

Using Gatling Load Testing to Take Performance Test

Introduction of Appium in Mobile Automation Test

What is Gatling Load Testing

Gatling Load Testing is a tool for performance testing based on Scala-Akka-Netty. That you can easily use by generating beautiful reports.

To download Gatling just access the link https://gatling.io/download/

Scripting

There are a few ways to script to run in Gatling. All of which is well documented on the tool’s website.

The script we will make as an example uses the Gatling Recorder through a HAR file, in our case, it is from the page “globo.com”.

  1. Open the recorder;
  2. Then, select “HAR Converter” mode;
  3. Select the HAR file that you want to generate the script;
  4. Select the name of the class;
  5. In the Recorder, there are still some other options to explore, in our case we do not want the script to contain static resources so clicking on the option “No static resources” already adds to the blacklist everything we do not want.

After clicking Start our simulation will be ready and the file in Scala has been generated and ready to be simulated.

Generated reports

Now with the script ready, we can do our report. Just run Gatling, select the number of your simulation, id you want saving and some description if you wish. Then the simulation begins.

In the end, it generates an HTML report to visualize the information in more detail.

The reports present a lot of information to explore, such as in the following images:

The main page displays a graph that shows the number of requests made in the script concerning time. By default Gatling considers that the time below 800ms is good. Between 800 and 1200 is worrying and above 1200 is bad, but this can be changed in the config file according to our needs.

You can also see the number of tests performed for a specific request with information on:-

how many of them were successful, how many failed, the number of requests per second, minimum time, maximum time, some percentiles, average, and standard deviation.

By clicking on a request, we have detail information about it that is the same information that was on the main page.

But with a specific graph for it and separating the information from the failed requests and those that were successful.

Returning to the main screen, at the bottom. We have the graph of the number of users who were used in the simulation with time.

The percentage of successful requests and that failed concerning the request time.

The percentiles of successful requests over the course of the simulation.

Number of requests over the course of the simulation.

Number of responses throughout the simulation.

Injecting Users

Now we can start improving our Script by opening the Scala file generated by the Recorder and changing what is necessary.

You can delete requests that we consider unnecessary, edit the name of the requisitions to improve their identification in the reports, and test with the number of different users.

By default, the file generated by the Recorder comes with a user, which can be found in the setUp at the end of the file, but there are a few options to put users in the simulation, are they:

Based on this description, we can now do any performance tests according to our needs.

Share this