In this article, we shall discuss about 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 the Gatling's request generator to ping requests continuously as if the requests are created by the browser events.
The virtual users has its own data and own browsing path. It is able to create more than thousand concurrent requests with the help of virtual users. Some other tools uses 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 as 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 work flow. For example, while we visit into 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 with 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 any 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 says 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 it's 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 place holder, 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 secure 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 of 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 send back by the server to the Gatling.
Gatling analyze 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. Example, when sending an HTTP request, we may expect that there may be a 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 which will define acceptance criteria based on the Gatling Statistics. It will return a 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.