In the previous post I demonstrated how to parameterize a simple profile. That profile consisted of only three requests. First request opened the main page of a web forum with sub-forums listed on it. Second request opened one of the sub-forums. Third one opened a topic inside that sub-forum.
The goal of the parameterization was to make WAPT open a random sub-forum on the second step and a random topic on the last step. Initially both were recorded as constant values.
The main idea was that when we want the value of a certain request parameter to be dynamic, we can use special functions to extract it from server response to the previous request. While this worked perfectly for our simple example, this does not seem to be a general way to handle such situations. What if the required value is contained in the response to, say, 5th request of a profile, and it should be used in the 10th request?
The answer is: we can extract that value to an internal variable and then use that variable in any subsequent request. I mentioned this mechanism before when I wrote about extracting values from hidden controls in HTML forms. Now I am going to show how to do this with other values.
I will continue using the same example and will simply change the parameterization. Basically I will use the same “Search” function that finds a value surrounded by two boundaries, but this time I will extract that value to a variable.
I select the first request in the left view and the “Response processing” tab in the right view. This tab specifies what WAPT should do with the server response to the selected request during the testing. The most important thing here is the definition of variables. The list of variables is shown at the top of the page. Initially it contains only values of hidden form controls for which the variables are created automatically.
Now let’s add a new variable for the number of sub-forum. I click the “Add…” button near the variables list. The “Add variable” dialog is displayed.
This dialog is very similar to the “Edit parameter” dialog that is used to specify how to calculate the value of a parameter. Actually, sometimes people even mess parameters of a request and WAPT internal variables. Even though both things are specified in a very similar way, they are completely different in meaning. The variables are used to store values during a user session. It is a very common practice to extract a value into a variable and then assign the value of that variable to a parameter of a subsequent request. This is exactly what we want to do now.Watch Full Movie Online Streaming Online and Download
I specify the name for our new variable and click the “Add” button to add an extraction function. This will be the “Search parameter” function specified as follows.
I use the same right and left boundaries that we used before.
Now I need to specify how to use the created variable. I select the second request in the left view. We need to change its showforum parameter. I click the “Edit” button to open the “Edit parameter” dialog, and one more “Edit” button inside it to open the “Edit function” dialog. Here I select “Variable” for the function type and click the “Select…” button near the variable name. I could simply type the variable name, but this dialog provides a more convenient way.
By the way, note the Session_number variable. It is always present in the list and contains the number of the current user session starting from 0. It is very useful sometimes, if you need to have some unique value for each user session.
Basically that is all. We can repeat the whole procedure for the topic number in the third request and verify the test. If we do everything correctly, the verification log will be absolutely the same as before.
So, in short: when we need to use a value contained in the latest server response, we can extract it directly to a parameter. However if we need to use an “older” response, we have to create a variable in the processing of that response and extract the value to that variable. Only after that we can use it in subsequent requests.
Why is this important? In old days all page requests inside user sessions were created by users clicking links and buttons on the web pages. In such case you would never need to extract data from “old” responses, because the only content available for the browser at the moment of sending next request was the current page. So, any data included in the request could have been taken either from current page or from direct user input.
That was simple… But then they invented JavaScript and AJAX. Now while you are browsing a page containing AJAX, your browser can send additional requests to the server and receive additional data from it to update the current page without fully reloading it. As a result, the page that you see when sending the next request actually contains data received in several server responses, so you need to have a way to extract values from any of them.