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.

Parametrising server address

The final touch to the script would be to parametrize server address so that one script could be run against different environments. This could be very handy if the scripts needs to be recorded before the application is deployed to the production (or copy of production) environment where it is to be performance tested.

Depending on the environment configuration the difference between URLs could be:

• web server hostname/IP address
  Environment1: http://development
  Environment2: http://staging
  
• port number
  Environment1: http://application:8080
  Environment2: http://application:7800
  
• context path
  Environment1: http://application/inc10
  Environment2: http://application/inc11
  
• or any combination of the above

The first scenario (different hostname or IP address) is by far more common. It is also very easy to configure in WebTest using "Parameterize Web Servers" button in the WebTest tool bar. The same approach will also work for the second case where the application server hostname and/or port is different between both environments.

WebTest context parameter

As the result of this web server URL in the whole script is replaced with parameter and new Context Parameter is automatically added to the WebTest.

It is best to keep parameter name generic (i.e. DevWebServer is a bad name since it won't be valid once URL is replaced with one pointing to Staging environment).

In case the difference between environment is reflected by different context path (e.g. http://application/ContextPath) server address parametrization cannot be done in a simple way as above.

Since I always tend to avoid doing thinks manually (which could be time consuming and error prone) I had to find another way of doing this. The easiest way I found was via editing WebTest as a XML document and running search and replace on the application address.

Name of the parameter which will replace server address would be the name of the context parameter containing application URL which would need to be created manually. This can be done by right clicking on  the WebTest parent node and selecting "Add Context Parameter" from the context menu.
If the name of the context parameter which contains server address is ApplicationServer then server address should be replaced with {{ApplicationServer}} and the exact text which is being replaced should be set as a value of this context parameter.

This approach will work with any combination of the three URL parts (address, port and context path).

As a final note please remember that web address parametrisation should only be used if both environments have exactly the same version of the application deployed.

Troubleshooting fiddler

Error while exporting WebTest from Fiddler "One or more plugins returned an error, but the remaining plugins."

This is a known issue which could be fixed following instruction from here.



Fiddler recording is missing requests
This could be due to too many simultaneous downloads as I experienced while recording scripts for AJAX application. This could be resolved by increasing number of concurrent connections in Internet Explorer following this guide.

Fiddler is not recording requests
Fiddler web browser plug-in will usually re-configure web browser and set itself as local proxy. If for any reason this automatic set up failed it might be necessary to manually configure web browser (or any application) to use Fiddler as a proxy server. By default fiddler will be listening on localhost on port 8888
The same approach could be used to configure any application based on the HTTP protocol to use Fiddler as a proxy and thus allow it to record a web script.

HTTPS traffic is encrypted "Host CONNECT"
This could be because HTTPS decryption setting is switched off in Tools > Fiddler Options > HTTPS
Once enabled it is a good idea to turn on "Hide HTTPs connects" rule from Rules main menu.

Correlating dynamic parameters

Once the script has been recorded using Fiddler tester can start correlating web requests. The aim of this process is to ensure that scripts will handle user session and other dynamic parameters in the same way as web browser would do.

Additionally to session id web application can use wide range of other dynamic parameters generated on-the-fly. For example in an e-commerce application each customer might be assigned a unique shipping cart ID which could contain a unique list of items in the shopping basket.

Since the shopping cart id is generated only after the customer adds the first item to the basket it cannot be known prior to the execution time. WebTest script will have to capture shopping cart id generated by the server and use it while adding products to the shopping basket.

If the script correlation were skipped performance test could still add items to the shopping cart created by web application during script recording. Depending on the tested application this can result in:

• no obvious functional error but only one recorded shopping card id is shared between all simulated users skewing test result
• http error page with a http error status code (i.e. 500)
• custom error page which might appear as a pass (based on the http response status code) but in fact it is a page containing error message

Performance tester needs to pay close attention to all dynamic parameters and sometimes discuss their purpose/importance with developers to ensure that realistic load is generated. It is probably a good strategy to assume that all requests failed (even if passed according to http status code) and verify each of them manually.

In general script correlation can be broke down into fore stages process:

• Identify dynamic parameters
• Locate in which response the server is sending required dynamic value to the browser
• Add extraction rules to extract dynamic values from server response
• Replace hard-coded values with the dynamically extracted values

The real benefit of using Fiddler to record VSTS WebTest becomes apparent during first two stages of the script correlation process.

When business processes are recorded in VSTS only web requests are captured by the recording engine. Using VSTS alone tester would have to execute the script multiple time each time getting slightly further in the correlation process.

If application data is single use only correlation can become even more tedious and time consuming.

On the other hand Fiddler recording contains both request and response for the whole recorded business process. Once dynamic parameters have been identified in request it can be searched for within all server responses using Fiddler and located within seconds.

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

Add extraction rules to extract dynamic values from server response

Visual Studio implements extensible script correlation mechanism which is highly reusable within and across performance testing projects. This post will explore build-in correlation rules available in Visual Studio.

Extraction Rules are used in VSTS to extract value from server response and then pass that value to the server in another request. Based on the type of extraction rule (e.g. form field, tag value) and its parameters (e.g. form field name, tag name) rule will extract required value from the server response.

The most commonly used Extraction Rules build into VSTS are:

• Extract Text
• Extract Hidden Fields
• Extract Form Field
• Extract Attribute value
• Tag inner text

The extracted value will be placed in VSTS context parameter with a name specified in Context Parameter Name parameter of the extraction rule.

Although there are no riles in naming context parameters it is usually a good practice to call the parameter with a name related to the extracted entity.

Adding transactions to the WebTest

It is not unusual for single user action (i.e. submitting form, refreshing page) to issue many HTTP requests. In order to establish true user experience while navigating between pages it is necessary to sum up all request response times. Calculated number will be how much end user will have to wait since clicking a submit button until the next page finish loading.

For that reason many performance testing tools (including VSTS) provide simple solution to this common problem – transactions.

Since it would be difficult (if not impossible) for a testing tool to automatically add the transactions it is something what needs to be done manually before a meaningful test can be executed.

Having said that it will still be possible to execute a load test without addin in transactions although some manual calculations will have to be done to figure out how much time each user action takes.

It is important to define transactions in the same way if the scripts needs to be rerecorded otherwise the results of different test executions cannot be directly compared.

In order to define transactions the WebTest:

1. Right click on the first request or comment which doesn't belong to any transaction
   
   
   
2. Select "Insert Transaction…" from the context menu
   
   
3. Enter transaction name; see transaction naming convention below
   
   
4. Select first request or comment for this transaction; this will be already preselected to the request on which "Insert Transaction…" has been clicked
   
   
   
   
5. Select last request for this transaction; if you followed this guide closely it will be the last request before next comment
   
   
6. Click OK
   
   
   
7. Repeat steps 1 to 6 for remaining requests
   
   New transaction will be added to the WebTest with the chosen requests. If for any reason the transaction is not as intended (i.e. missing requests or too many requests) it is possible to manually drag and drop requests in and out of the transaction.
   
   

Transaction naming convention
It is considered a good practise to adhere to a transaction naming convention. The naming convention which I find particularly helpful during could be defined as ShortScriptName_Index_TransactionName


Based on that convention transaction names could look as follows:

• SMP_01_NavigateToHomePage
• SMP_02_SearchForProduct

Using this naming it is possible to sort transaction by name while viewing test results and then follow transaction times in the execution order.

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

Correlating Session ID

HTTP is a stateless protocol which means that the web server is not keeping track of client (most of the times web browser) activities. Using just HTTP protocol alone user would have to enter authentication data upon each page request as the protocol defines no way of distinguishing between requests. The most common way of dealing with that problem is to append a unique identifier to each request so that web server can relate all requests with the specific id to a unique user.

This technique is called session management. There are three most commonly used ways of maintaining session id between requests:

• Cookies
• URL rewrite
• Hidden fields

Each time a web browser connects to web application without sending session id (usually upon the first access of the application) a web server will assign a new session id to that browser.

In most cases a web browser will maintain session id until the web browser is closed which needs to be replicated in a WebTest. Depending on the way the web session is maintained by the web application some manual work might be required.

Cookies

From performance test point of view cookies are usually the easiest to deal with. VSTS (as well as many other tools) will automatically extract cookies sent by the web application and use those in subsequent requests.

In most of the cases no scripting action is required to correlate cookies.

URL rewrite

URL rewrite is a session management technique which doesn’t relay on cookies support (as this can be occasionally switched off due to security constrains).

With URL rewrite session id will be appended to the URL. Recorded session id will have to be replaced with the dynamically assigned session id returned by the server.

This process of extracting value from one request and then using it in another is often referred to as correlating performance scripts.

URL rewrite URL can look similar to this:

http://www.example.com/context/homepage.jsp;jsessionid=76489BF47E98F1

Hidden fields

Another technique of maintaining web session is to embed hidden field with session id within a web form.

Similarly to URL rewrite session id will have to be extracted from the first server response where it appears and then original/hardcoded session id needs to be replaced with the dynamically extracted value.

In most of the cases correlation of the session id and other dynamic parameters can be done following the same process although it is good to have knowledge of their distinct types and purposes they serve.

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

Adding comments to the WebTest

If you created WebTest from Fiddler recording WebTest will contain additional requests acting as a "request comments". Before executing WebTests those comments needs to be replaced with genuine VSTS comments.

1. Open WebTest exported from Fiddler
   
   
   
   Requests "Navigate to Homepage", "Search for product" and "Select Product" act as "request comments"
   
   
2. Right click on the “request comment” (created during Fiddler recording session) and select Insert Comment from the context menu
   
   
3. Type in comment for the step; this comment will ultimately replace “request comment”
   
   
   
   
4. Ensure the comment is in the correct place; it should be either directly above or below “request comment”
   
   
5. Remove “request comment”
   
   
6. Repeat steps 2 – 6 for all “request comments” in the WebTest
   
   Completed script should contain only legitimate requests with all “comment requests” replaced by VSTS comment item.
   

Although comments won’t be usable during result analysis they will become very precious source of information while adding transactions or identifying execution failures.

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