This page is about Gatling 1. About Gatling 2, see here.
To represent users' behaviors, testers will have to define scenarios which will be written as scripts given to Gatling. These scenarios can be the result of measurements on the running application with analytics tools, or expected behavior from the future users of a new application. In any case, the creation of these scenarios is the key to meaningful results of the stress test.
A scenario represents a typical user's behavior, for example, in an e-commerce application. A standard scenario could be:
This is a functional scenario, understandable by anyone. There can be as many scenarios as different use cases of the application. We can also imagine the use of a product comparator or an admin panel; each use case can be described as a scenario.
In Gatling, scenarios are represented as easy-to-maintain scripts in conjunction with a DSL (Domain Specific Language). This allows fast writing of scenarios and easy understanding of existing scenarios. Here is a simple example of scenario written for Gatling:
scenario("Standard User") .exec( http("Access Github").get("http://github.com") ) .pause(2, 3) .exec( http("Search for 'gatling'").get("http://github.com/search").queryParam("q","gatling")) .pause(2))
As we can easily guess, this scenario:
Pauses are here to simulate the reading or thinking time of the user. Indeed, when a user clicks on a link, the page has to be loaded and the user will read it and decide what to do next.
The HTTP requests are the ones which are actually sent to the tested application when a user clicks on a button or a link. Each HTTP Request is easily read:
For a complete description of scenarios, see the Reference articles
A simulation is a load test. It is made of different scenarios, each representing a typical user behavior. Here is an example of simulation definition:
val stdUser = scenario("Standard User")... val admUser = scenario("Admin User")... val advUser = scenario("Advanced User")... setUp( stdUser.users(2000).ramp(60), admUser.users(5).ramp(400).delay(60), advUser.users(500).ramp(200) )
Each scenario is defined first; here, we have three scenarios representing standard users, advanced users and administrators. For each population of users, the Number of users is defined along with a Ramp and a Delay.
Note: Using a ramp can be critical for JVM based applications as the JIT compiler identifies hot spots. (The JVM "warms up")
For each simulated user, there is a session. This session is accessible to one and only one user at runtime. It allows Gatling to store information while processing the scenarios, but it also allows testers to dynamically store data and use it in their requests.
For more information, check the Session reference section.
When the tested application offers the possibility to authenticate, tests should take this into consideration and use data to test log in, log out, actions allowed only for certain users, and so on.
Gatling doesn't provide the tools to generate this test data. However, it allows you to take existing data and feed scenarios with them thanks to Feeders
For more information, check the Feeders reference section.
Each time a request is sent, a response is eventually sent by the server. Gatling is able to analyze this response with checks.
A check is a response processor that captures some part of it and verifies that it is what the user expects. For example, when sending a HTTP request, one could expect a redirect; with a check, you can verify that the status of the response is actually a 30X code.
These checks allow you to be sure that the results obtained during the simulation are not related to server malfunctions. For example, Gatling could retrieve responses with good response times, but these responses may not be what they should, therefore, the analysis you could make on the results given by Gatling may be wrong.
For more information, check the Checks reference section.
By default, Gatling automatically generates reports at the end of a simulation. They consist in HTML files, therefore, they are portable and they can be viewed on any device with a web browser.
Reports are detailed in the corresponding page
Last edited by Stephane Landelle,