All ASP.net web applications use two specific parameters: __VIEWSTATE and __EVENTVALIDATION. When the client part of such application communicates with the server side, every produced HTTP request includes these two parameters:
The values of the __VIEWSTATE and __EVENTVALIDATION parameters are essentially dynamic. In fact, they are changing for each request within a session. Of course, they are also different for different sessions. This means that you cannot repeat the recorded requests “as is” to produce a copy of the recorded session.
Initially the values are produced by the server part of the application and transferred to the client inside the body of each response. After receiving the updated values the client should include them as parameters in the next request. In response to that request it will receive new values that should be used in the next request, and so on.
Why is this needed? Obviously this question should be better addressed to the creators of ASP.net, but I will try to provide my version. Overall the situation is very similar to how web applications use session IDs. They are usually handled by cookies. I wrote about that here.
The difference is that in general it is possible to work with several different “viewstates” within the same session. The client can revert to an older value of that parameter and the server will know that the current request should be applied to the corresponding older context.
Anyway, what is important for us is that every server response contains new __VIEWSTATE and __EVENTVALIDATION values. To reproduce user sessions correctly, WAPT should extract those values to variables and pass as parameters inside the next request.
Let’s see how these values appear inside server responses. There are two different notations used for this. They are shown on the following images.
In the first case the values are passed inside the hidden controls of HTML forms. When WAPT meets such values, it parameterizes them automatically. It creates variables for all hidden form values, including ones we need. This is described in more details here.
It also uses the values of the created variables in the next request. As a result, everything works fine and the whole thing is done automatically.
However what happens in the second case? Unfortunately the values remain not parameterized, as we see on the following screenshot.
What will happen if we verify or run a test with such profile? In most cases the web site will not produce an error. It will receive the old __VIEWSTATE value and will treat the request as one belonging to the originally recorded session. This will be obviously incorrect, but the exact outcome depends on your web application. Possibly you will not see any errors on the test verification, however if you check the returned response, it may include incorrect data.
For example, imagine that when you originally recorded the session, your application accessed a specific database record. When you execute your test with 100 virtual users, you want each of them to pick a different record and perform the same operations with it. You can parameterize the record number (or other higher level options used to pick it) and this will work fine for the request that initially selects the record. However as soon as the session comes to the request with the not parameterized __VIEWSTATE value, that request will apply its actions to the database record selected in the initially recorded session, not the right one.
That looks quite bad. So, what to do? The answer is very simple: you should parameterize all occurrences of the mentioned values for all requests in your profile. You should specify how to extract the values from server responses to variables. Then you should insert these variables to the list of parameters instead of the initially recorded values.
Of course, this may require some time to go through all the requests. Fortunately there is a much faster way to do this. It is provided by a special extension module for WAPT. It is installed and licensed separately from the main product. You can download it here.
After you install the module, WAPT will handle the responses containing the __VIEWSTATE and __EVENTVALIDATION values differently. It will use additional functions implemented in the module to extract those values in all cases. Now the response processing tab will look like this:
The parameters containing our values will be made dynamic automatically with help of the corresponding variables:
Conclusion. Our customers often ask me if they need to purchase the Module for ASP.net testing in order to test web sites implemented in ASP.net. The answer is: if your web application always passes the mentioned above values only inside hidden form controls, you do not need the module. Otherwise you can either make parameterization manually, or use the module.
The reason why we recommend using the module is that otherwise you will need to check thoroughly all the requests in your profiles. As I noted above, if the ASP.net values remain not parameterized, this does not usually lead to HTTP errors easily visible in the log. However this can make the user emulation incorrect and essentially reduce the reliability of your test.
P.S. All screenshot in this post were made using a profile recorded at the following ASP.net demo resource: http://www.ezineasp.net/Samples/ASP-Net-AJAX-cs/Extensions/AJAX-UpdatePanel/Default.aspx
You can try recording with and without the module to see the difference.
