In the previous post I wrote about web forms containing hidden controls. The purpose of these controls is to pass some data from the server to the client and then receive it back in the next request (along with the other data submitted in the form).

However when a load testing tool, such as WAPT, replays a recorded user session, it does not create the submit request from the actual form. It only has the recorded version of that request. Its parameters contain data that was submitted on recording (read more on this here).

So, the load testing tool should somehow send the same request, but with different values of parameters, including the values taken from the hidden controls of the form contained in the latest response. In WAPT this is done with help of the variables.

The general concept is that you can create any variables during the user session. For each request in the profile you can specify which variables should be created and what values to assign to them after the request is completed. Usually this is done with help of special functions that extract data from the received server response. Each variable has a unique name within a profile, so if you assign a value to a variable with the same name in a subsequent request, this will be a reassignment to the same variable.

Now let’s see this on a very small profile example that I mentioned before. I select the second request of the profile in the left view in WAPT and switch to the “Response processing” tab in the right view. The name of that tab speaks for itself, because this is the place where we specify how to process the server response. The most important part of the processing is the extraction of values that are assigned to variables. So, in the list of variables for this response we see the following:

WAPT automatically finds all hidden controls inside the web forms on the pages returned by the server and creates variables for them. We see two variables here: forum1 and referer1. The names of the variables were created from the names of the corresponding controls. Numbers are added in order to be able to create other variables for the controls with the same names when processing other requests.

I select the referer1 variable and click the “Edit” button to check the details of the variable specification. The following dialog appears:

This dialog is very similar to the “Edit Parameter” dialog that I mentioned here. Actually, parameters and variables are specified in WAPT using the same approach: the assigned value is calculated as the concatenation of several specified functions. In most cases only one function is used. In our case this is a function called “$Hidden()”. I click the “Edit” button again to see the details of that function. This is what I see:

So, now we understand how the value of the referer1 variable is assigned. But how is it used? I select the third request in the left view and choose the “Properties” tab in the right view:

The parameter called referer is defined with help of the “$Var()” function. It is not hard to guess what that function does. It simply returns the value of the specified variable that was assigned during the processing of the previous request.

Now let’s understand how WAPT did that substitution. When it analyzed the recorded response to the page_2 request, it found two hidden controls and created a variable for each of them. Then it analyzed the parameters of the recorded page_3 request and found one that had the same name and value as the corresponding web form control on page_2. So, it replaced the static value for that parameter with the value of the created variable. That’s it!

But why is this important to know, if the whole thing was done automatically? Because this describes the general concept behind any parameterization of requests required to create correctly executing user sessions. In simple cases it can be done automatically, but as soon as things get more complex and less standard (which means specific for each web application), we need to do similar things manually. In such cases WAPT records sessions as is and we should modify the profile to replace static values of parameters with dynamic ones extracted from server responses. We need to tell WAPT how to extract them in each case.