Gatling's terminologies

In this article, we shall discuss some important terminologies and concepts. Before we start, it is required to know about some terms like virtual users, scenarios, etc.

Virtual User :

A virtual user is a user created by Gatling's request generator to ping requests continuously as if the requests are created by the browser events.

The virtual users have their own data and own browsing path. It is able to create more than a thousand concurrent requests with the help of virtual users. Some other tools use virtual users as threads.

Scenario :

Of course, a script input has to be made into the Gatling to start simulating the process, but that script must be generated under some web protocol's condition, which is called a scenario. A scenario describes a typical behavior of the user, in this case, it's virtual users.

To create a scenario, the virtual user must follow a definite workflow. For example, while we visit an educational website, we may follow the below process as a normal user:

  • Go to the Home Page
  • Go to the sign in option
  • Enter the credentials and then click to Sign in
  • Open our topic list
  • Scroll them
  • Go back
  • Select a different topic
  • Go back
  • Sign out

It may be noted that scenarios may be represented in scripts in addition to a Domain Specific Language, which is a better way of writing and maintaining a scenario.

Let us look at this sample scenario script:

scenario("Any standard User")
.exec(http("Access Cherchertech").get("https://chercher.tech"))
.pause(2, 3).exec(http("Search for 'gatling'").get("https://chercher.tech/search?q=gatling"))
.pause(2)


In the above scenario, it can be easily seen that the scenario contains: the scenario name, 2 http requests, and 2 pauses. As we know that pauses are used to simulate user think time. This is like, that when a real user clicks on a website link and waits for the page to load, and after that they decide what to do.

On the other hand, http requests are made to trigger into the web application when an event occurs or any button is clicked. It is seen that the individual HTTP Request is easy to grasp, but not the page resources.

Example:
The GET request, Access Cherchertech is pointing at http://chercher.tech.

And when gatling is searched, a GET request points at http://chercher.tech/search?q=gatling.

Simulations :

Basically, the simulations say all about the load test. The complete procedure, such as how the different virtual users will run, and how new virtual users will be injected, all such things are described by the simulation.

Let us take the below example of a simulation:

val stdUser = scenario("Standard User")
val admUser = scenario("Admin User")
val advUser = scenario("Advanced User")
setUp(
stdUser.inject(atOnceUsers(2000)),
admUser.inject(nothingFor(60 seconds), rampUsers(5) over (400 seconds)),
advUser.inject(rampUsers(500) over (200 seconds))
)

Sessions:

Each virtual user will have their own session. It may be noted that the sessions are the main messages which will go down the scenario workflow. A session is nothing but a placeholder, where data can be captured, tested, or injected.

Feeders:

When the applications are tested and gain authentication, then in the test itself, some credentials data also must be generated and passed inside the virtual user's session to see whether all the security functions are working properly.

However, in the Gatling software, we do not have the facility for the creation of this test data and so there is a need for a different API, which allows us to inject data, from an external source into the virtual user's session. This kind of external supporting API is called Feeders.

Checks:

When any request is made to the server, a response is always sent back by the server to the Gatling. Gatling analyzes this response with Checks.

Therefore, it is seen that Gatling is a response processor that snapshots some parts of the response and verifies that it meets the given conditions. For example, when sending an HTTP request, we may expect that there may be an HTTP redirection also. So, Gatling will use Check to see whether the status of that redirected response is also a 30x code.

Assertions:

This is a procedure that will define acceptance criteria based on the Gatling Statistics. It will return an error status if a Gatling failure is sensed.

Reports:

Gatling Reports are generally, automatically created after the simulation is completed. It consists of HTML files, as therefore can be view directly as a web page anywhere.

Bundle of Gatling

  • bin : It contains the launch scripts for Gatling and it's the recorder.
  • conf : It contains the configuration files for Gatling, Akka, and Logback.
  • lib : It contains the binaries used by the software.
  • user-files : It contains the simulations folder, data folder, and bodies.
  • simulations : It contains our Simulations Scala files. Please respect the package folder hierarchy.
  • Data : It contains the feeder files.
  • bodies : It contains templates.
  • results : It contains the filesimulation.log and reports generated in a sub-directory.

Putting it all together

  • We have seen how to get started with the Software, after installing it, with JDK8 or later versions.
  • We have seen how to create scenarios using the Gatling Recorder.
  • We have also seen how to generate our scenario using the HAR file, from the browser itself.
  • We have seen that, to use the simulations to create the tests report.
  • We have also seen how all the detailed report is formed inside the HTML file.
  • We have discussed the official plugins of Gatling and saw how to use them.
  • We have learned different terminologies related to the entire Gatling Process.
About Author :

I am Pavankumar, Having 8.5 years of experience currently working in Video/Live Analytics project.

Comment / Suggestion Section
Point our Mistakes and Post Your Suggestions