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.
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.
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:
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.
The GET request, Access Cherchertech is pointing at http://chercher.tech.
gatling is searched, a GET request points at http://chercher.tech/search?q=gatling.
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)) )
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.
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.
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.
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.
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.
simulation.logand reports generated in a sub-directory.
I am Pavankumar, Having 8.5 years of experience currently working in Video/Live Analytics project.