Identifying and locating dynamic values

Identify dynamic parameters
Although it is certainly possible to identify some of the dynamic parameters just by looking at the single recording session it is far better to record the same script twice and then check which values stays the same and which are dynamic and need to be correlated.

Dynamic parameters can appear as part of the Query String, Form Post data (i.e. web form) or Post Body string (e.g. XML, JSON, etc.)

It is useful to create a list with all dynamic parameters with their respective values.


Locate in which response the server is sending required dynamic value to the browser 
Once the dynamic parameters have been identified Fiddler search function can be used to locate the first occurrence of the required value in server response.

Following search criteria will look through only server responses for number “536877651” and mark matching sessions in yellow:

Fiddler find window

Once the request is found Fiddler Inspectors tab can be used to learn request parameters and response data.

The most convenient way to work with the server response is to open raw data file by clicking “View in Notepad” button under Raw sub-tab in response pane.

Once the value is located in the text editor some XML/HTML skills are required to identify the context in which the value is used. The value might be a form field, HTML tag attribute, HTML tag value/innertext or something more exotic such as JSON serialised object.



For example for the following HTML fragment:

      

Although it would be possible to extract value of hidden field _activityId_ using text extraction rule or hidden field extraction rule it is always best to use the more specific rule which in this case would be hidden field rule. The benefit of using hidden field over extract text rule is that the former will work even if there is additional attribute between name and value attributes.

If the value cannot be located in any server response before the request where it needs to be sent then it is either generated by script or entered by user.

Data entered by application users is called parameter data and it is usually parameterised using VSTS Data Source feature.

If the value is generated by the script then some investigation is usually required to discover what the dynamic value means (i.e. unique/random value, date/time). Once the logic behind script generated values is known tester can create a custom request plugin which will generate the vale at run time.

For the full guide to developing VSTS WebTests please refer to the Using Fiddler with VSTS.