Variables - Methodology Design

Variables - Methodology Design

Methodology 4 minutes

A look at the variable types we can use to make our test scenarios more realistic.

HTTP Protocol

HTTP Protocol

Our goal here is to understand how HTTP works. Then we can focus on how to make it work for our tests.

It is not the purpose of this training to talk about a specific technology. That being said, more than 99% of modern applications use HTTP/S to communicate. And what we’re going to talk about could be said of most other protocols.

So initially the client (browser) sends a message to the servers. They will work together to come up with an answer. When the client gets the response, he displays it. That process is usually called rendering. And then he will proceed to send another message, etc…

We will come back to this graph and add more on top of it later. For now let’s focus on what the message sent by the browser contains.

HTTP Parameters

HTTP Parameters

There are many ways to send information as part of an HTTP request. The most common is to send parameters. Based on the information transmitted we will put them in different categories.

Static parameters

Here we talk about any value that is sent just for information purpose. It could be something like:


The important thing is that they will remain the same:

  • For different users,
  • At different points in time.

In the end static values can safely be ignored.

Functional parameters

These values are displayed to the user on screen. Wether he/she entered them or they were pre-filled is not relevant. What matters here is to understand if they need to be changed. An easy example is the login/password, each user must provide a different one. Another example is the email on a subscription form. You must provide a new unique value each time or your script won’t work.

But most of the time these values do not matter. An adress or a name will rarely change the way the server behaves in a relevant way. Think of them as values you should randomize when possible.

Dynamic parameters

These values are critical to the script. If you do not use the right value, it will fail or behave in a different way. Servers generate them dynamically at runtime for your client to use. They are usually session identifiers or equivalent mechanisms. You can recognize them because their values usualy looks like random letters/numbers.

Parameter example

Parameter example




The first type of variable is usually called datasets. The idea is to import lists of data before the test so that every virtual user get a different one. This way you can ensure that the activity will be stressing different areas of the database or creating the right amount of sessions.

Let’s take the example of a webshop, where you login 1000 users with the same account and have them add something to the cart. In that case you may be putting 1000 products in the same cart instead of 1 product in 1000 carts. That’s probably not the same load to the servers thus your test will not be realistic. Instead you should have used a list of 1000 login to have each virtual user pick a different one.


Runtime variables are used to extract dynamic content during replay. For instance, you extract the sessionId from the login response and use it in further requests. We will talk more about this later, here the important takeaway is that you can’t know their value in advance. This is what differenciates them from datasets.

Value distribution

Value distribution

When working with datasets, it is important to configure how the values will be distributed amongst all your virtual users.


The idea is to associate a value with each virtual user and stick to it. This can be usefull when the login needs to be absolutely unique. But mostly when you want your script to stick to the same value all the time.


The purpose of random is to make your virtual users more dynamic, more chaotic. This way you can avoid load that would be too predictable. You want to have local spikes of load from time to time and random behaviors to some extent.


The principle this time is that the list of values is shared by all virtual users. Each one will pick the next value in the list, ensuring that they all get a new value. This is especially usefull for data that can’t be re-used (subscription form, etc…).


Each virtual user will pick values in a sequential order from the start of the file. This option is really recommended when you don’t care about how the values are used. It could be for a dataset of names to input in a form or anything similar.

Get our whitepaper,
A beginners guide to performance testing!