Wednesday 30 June 2010

Opening Fiddler archive using Fiddler

  1. Disable Capturing mode from the bottom left corner


  2. Remove all requests from Fiddler; this step is optional and if it ware skipped fiddler will append requests from loaded archive to the current list of requests
  3. Chose File > Load Archive from the main menu



  4. Open Fiddler archive file (.*saz)
For the full guide to developing VSTS WebTests please refer to the Using Fiddler with VSTS.

Tuesday 29 June 2010

Saving fiddler session and exporting WebTest

For the best results it is recommended to save Fiddler recording session as a fiddler archive file *.saz as well as VSTS WebTest file.

Archive file will contain all requests with their corresponding responses and webtest will be used by VSTS during performance test.

In order to save recording as a fiddler archive:
  1. Click File menu



  2. Select location to save the file good practice to include recording number


At this point it is a good idea to export the recording to the VSTS WebTest format:

  1. Select all requests to be exported from Fiddler. This can be done by selecting Edit > Select All from the main menu



  2. Chose “Visual Studio WebTest” from the drop-down and click next button

     

  3. Select the location where to save the file

    It is a good practice to give the same filename to both files since it will make it easier later on to match WebTest to original Fiddler archive file.

If all steps have been followed correctly two files should be created:
    • BusinessProcess1-Rec1.saz
    • BusinessProcess1-Rec1.webtest

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

Recording VSTS WebTests with Fiddler

Although VSTS can be used to record WebTests there is added benefit of using HTTP proxy in that process as explained here.

Following is a general guide on how to use Fiddler to record a WebTest for use in VSTS performance testing:

  1. Start fiddler

  2. Make sure that fiddler is in “Capturing” mode (bottom left corner)


  3. Lunch web browser and navigate to any page

  4. Check Fiddler window; if no request is recorded make sure fiddler plug-in is turned on in the browser. Alternatively web browser proxy settings can be configured manually to 127.0.0.1 and port 8888

  5. Delete all requests from the Fiddler using Remove->All menu option


  6. Switch to the “Request Builder” tab on the right side, type in comment for the next step in the business process (e.g. navigate to application homepage) and click execute button.



    This will result in an incorrect (red) http request recorded by Fiddler which is expected.



    The purpose of this procedure is to add a comment to the recorded script. Once the script is exported into VSTS those invalid requests will be replaced with comments.

    Although there is comment functionality already build-in Fiddler it is awkward to use. Fiddler comments will not be visible in Fiddler and they will only appear when the webtest is opened in VSTS

  7. Refer to the business process script and perform action in the web browser (e.g. navigate to the login page, login, logout, etc.)

    Add a new comment each time a new request(s) is recorded. It is common for a single button click to generate many requests.

  8. Repeat steps 6-8 to complete business process

  9. Switch to Fiddler and click “Capturing” icon in the left bottom corner to stop recording

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

Using Fiddler with Visual Studio Team System (VSTS) 2010

When business processes are recorded from VSTS only the requests are captured which might be problematic during correlation. That problem can be overcome by using open web debugging proxy – Fiddler.

Fiddler acts as a web proxy between any web browser and the application under test recording all requests issued by the browser. Each request is recorded witch its response which vastly simplifies correlation process.

Fiddler

Fiddler session can be saved as a *.saz file which will preserve all request\response data and probably more interestingly as a VSTS WebTest.

Following posts will attempt to guide you though the whole process of recording and correlating VSTS WebTests.
  1. Recording the script
  2. Saving the script
  3. Opening recording session in Fiddler and VSTS
  4. Adding comments and transactions to the WebTest
  5. Correlating the script
  6. Script data parametrisation
  7. Parametrising environment URL
  8. Developing custom extraction rules
Additional resources:

Introduction to the Visual Studio Team System 2010 WebTest

Visual Studio 2010 is a great tool for performance testing and if we consider just the web protocol I would say it is as good as HP LoadRunner.

The real power of the tool comes not from the fact that it is .NET based but from the fantastic tree view structure. Microsoft has accomplished tremendous job by allowing testers to record the scripts in as an XML and presenting it as a tree view list of requests with their POST, Query String parameters.



Each request can be expanded and depending on its type it will have any combination of the following child items:

  • Headers
  • Dependant requests
  • QueryString Parameters
  • Form Post Parameters

Each group can be easily edited through the Properties pane and new items can be added by using web request context menu.

Headers
Most of the request web headers are generated by VSTS automatically based on the Load Test scenario configuration.

A classic example is a User-Agent header which is automatically added (during test execution) to each request issued by VSTS based on browser mix in the Load Test scenario.



Dependant requests
When the web browser requests a web it then parses server response (HTML) and identifies all embedded resources such as images, iframe pages, scripts, CSS stylesheets etc. While the new resources are being downloaded the page will slightly change its appearance which can be observer on the computers with slow Internet connection.
Each of the items requested by the browser based on the parsed HTML response is called dependent request. VSTS will usually be able to parse the HTML page and requests all resources as the web browser would do in which case no dependant requests will be added to the request. While running a test VSTS will parse the response and automatically request all related resources.
In some cases VSTS won’t be able to identify where in the resulting HTML page a given resource is called from. Since the dependent requests cannot be identified from the resulting HTML during recording VSTS won’t be able to identify it during load test and thus the test won’t be accurate.
Any resources requested by browser during script recording which cannot be linked to the HTML will be added as a dependant requests. Each dependant request has exactly the same structure as any other request and it can even have its own dependent requests.


QueryString Parameters
QueryString Parameters could be used with either GET or POST requests. These parameters are passed to the server in the last part of the URL address. QueryString starts with the question mark character “?” followed by key=value pairs of the querystring parameters witch each pair separated by ampersand character “&”
All QueryString Parameters are displayed under QueryString Parameters folder under the request



Form Post Parameters
Form Post Parameters can be either a list of key=value pairs separated by ampersand (same as in the query string but with no question mark at the beginning) or data format.
The first case (i.e. key=value) is very common in all types of web applications whereas the second is usually found in Web 2.0 applications.
If the application uses key=value pairs to pass data to the server those pairs will be listed under Form Post Parameters folder in the same way as QueryString Parameters.



Form Post Parameters can also list files uploaded to the web server



If the post body contains any other content VSTS will record it as a String Body



In order to view/edit String Body right-click on String Body item and select Properties from context menu. The Properties panel on the right hand side will show String Body value and two additional parameters.
The most widely used types of post data types are JSON and XML.

XML example:


JSON example:

Visual Studio Web Test Viewer

Visual Studio WebTest Viewer is a portable tool which reads VSTS WebTest XML into familiar tree structure.

As the name states this tool is just a viewer. It could be used to open WebTests exported from Fiddler without the need of having Visual Studio installed.

Due to its small size it can be placed on the USB stick and run from any PC with .NET framework installed.


This tool can be downloaded from its CodePlex project page: http://webtestviewer.codeplex.com/

Cleaning VSTS test results database

Cleaning test results database

Default installation of Visual Studio comes with SQL Server Express database which is used for storing load test data.

With every new test run the Visual Studio results database gets bigger and bigger and might eventually reach a 4BG which is the maximum database size in the SQL Server Express edition. When that happens no more tests can be run.

This problem can be overcame by either removing some of the historical results or renaming LoadTest database to something else and recreating the schema.

Removing test results

Removing no longer needed results will usually take longer as the SQL stored procedure needs to remove records from many related tables. The advantage of using this method is that there will only be one database containing only the important test results.

All operations described on that page require SQL execution engine such as Microsoft Management Studio.

Removing individual results

Test runs could be deleted from within Visual Studio by opening "Manage Test Results", connecting to a controller (or local instance of Visual Studio), selecting the result and clicking Remove button.

Test results could also be deleted directly from a database by executing Prc_DelereLoadTestRun stored procedure on the LoadTest database.

Exec Prc_DeleteLoadTestRun 1

In order to find more information about runs execute this SQL statement:

Select * from LoadTestRun

Removing old results based on date

Following code (which comes from Bill Barnett blog at http://blogs.msdn.com/billbar/archive/2006/02/09/528900.aspx) is a more robust SQL script which remove all test run results which are older then 14 days. This number could be changed depending on how many results needs to be deleted.

USE LoadTest
DECLARE @LoadTestRunId int
DECLARE OldLoadTestsCursor CURSOR FOR
SELECT LoadTestRunId FROM LoadTestRun
 WHERE datediff(dd, StartTime, getdate()) > 14

OPEN OldLoadTestsCursor
FETCH NEXT FROM OldLoadTestsCursor INTO @LoadTestRunId
WHILE @@FETCH_STATUS = 0
BEGIN
EXEC Prc_DeleteLoadTestRun @LoadTestRunId
FETCH NEXT FROM OldLoadTestsCursor INTO @LoadTestRunId
END
CLOSE OldLoadTestsCursor
DEALLOCATE OldLoadTestsCursor


Recreating results database

This approach is faster to use since the database data remains the same and only the database name gets changed.

Ones connected to a database rename the LoadTest database to something else and:

  1. Open Visual Studio command prompt
  2. For Visual Studio 2008 type: cd "C:\Program Files\Microsoft Visual Studio 9\Common7\IDE"
  3. Type: SQLCMD /S localhost\sqlexpress /i loadtestresultsrepository.sql

For more complete guide to setting up LoadTest database please refere to this MSDN article: http://msdn.microsoft.com/en-us/library/ms182600.aspx