One of the coolest features I think we’ve added in Visual Studio 2010 is the ability to add your own tabs into the webtest playback view.  Extending the user interface in this way allows you to do data analysis and have it pop up right in front of you in whatever format you want.  No more exporting to excel or whatever your favorite analysis tool is, just compile everything you one in one place and voila!

That being said, I have been told that it can be difficult to grok at first glance.  So, I wanted to post a sort of ‘how to’ in order to get one of these working.  A colleague of mine suggested that I could use this forum to demonstrate how to keep track of something that affects the performance of many users’ websites.  Namely, Viewstate.   So, below is a step by step instruction on how to create a webtest playback tab which keeps track of the viewstate size for each request.

Step 1:  Create the add-in project

Visual Studio Add-ins have their own special type of project, you can find it under “Other project types / Extensibility”.   I’ve named mine “ViewstateAddin”.

Step 2:  Walk through the create add-in wizard

When the wizard launches, you’ll be add a “welcome” screen.  Click next to move to page 1.

Page 1 asks you which language you’d like to program your add-in with.  I chose C#, but VB or C++ are supported as well if you prefer.

Page 2 will ask you where your add-in needs to be hosted.  Since webtest playback is not available within VS 2010 Macros, you can uncheck that box and simply leave the main VS 2010 product selected.

Page 3 asks you for the name and description of your add-in.  These will be visible to your users in the manage add-ins dialog, so don’t skimp here.  I’ve added mine as shown.

Pages 4 and 5 will ask you for a general idea of what your add-in will do.  For example – when you want the add-in to load into memory and whether you will be popping any modal UI from your code.  I suggest leaving all of the boxes unchecked (on both pages) if this is your first time creating an add-in.

Page 6 is just a summary page of everything you’ve selected thus far.  If everything looks as you expect, click finish to create your bare bones add-in.

Step 3:  Creating the user control and adding required references

The user interface you design will be housed within a single user control.  Inside that control you can do as you please, but first you must create the user control container.  This is accomplished under the project menu by selecting “Add User Control”

You can name the user control anything you want.  I’ve named mine “ViewstateControl.cs”.  This will add a blank user control to the project which will be used extensively in the next few steps.  For now, you can leave it blank.

Before moving on, you will also want to add 2 references to your project:

First - Microsoft.VisualStudio.QualityTools.WebTestFramework.dll (This one can be found on the .NET tab of the add reference dialog.)

Second – Microsoft.VisualStudio.QualityTools.LoadTestPackage.dll (This one you will need to use the browse tab in the add reference dialog and look in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies)

Caution:  Make sure you’re using Version 10.0 of these assemblies or your add-in will not work.

Step 4:  Adding the connection code

The process of getting a playback add-in to work for you is a two step one.  First, you need to tell the playback window that your control exists.  Then you need to register for event notifications.  First, let’s go over telling the playback window that you want to have your user control displayed.

This is done from within the Connect class.  If it’s not already open, open the Connect.cs file from solution explorer.  Inside the Connect class, you will need 2 things.  First, an object containing a list of your user controls. (One add-in can provide support for any number of user controls.  Each user control will get its own tab.)  Second, you will need a handle to the LoadTestPackage Extensibility object. (Don’t worry, it’s harder to say than it is to use.)

Each of these objects needs to be global to the Connect class and declared as follows:

The next method is one you’ll need to add to the Connect class.  It will be called when your add-in is loaded for the first time to attach to any existing playback windows as well as each time a new playback window is created.  It is responsible for making sure the playback window is displaying a tab with your control on it.  If you’re having trouble getting a tab to display, this is one of two likely places to look for a problem.

If you’re having trouble getting all of the above objects to resolve, make sure you have the following using statements in the file:

• - Microsoft.VisualStudio.TestTools.LoadTesting
• - System.Collections.Generic
• - System.Windows.Forms

As you can see above, there is no constructor for ViewStateControl that takes a WebTestResultDetails argument.  Don’t worry about that just yet.  It’s expected since we haven’t written any code for the control.

Now that you’ve created the method which will be called when your control needs to load, you need to make sure it gets called.  There are 2 times when your control will need to load.

• - When your add-in is loaded and there are existing webtest playback windows open.
• - When a new webtest playback window opens.

For the first case, we just need to call the WindowCreated method from the OnConnection method.  You do this by first creating a handle to the Loadtest package extensibility object and then calling WindowCreated for each open window.  For the second case, you need to subscribe to the WindowCreated event from the extensibility object and call WindowCreated from within the event handler. 

Your OnConnection method and event handler should now look like this:

That’s all that is required to get your new tab to display within webtest playback.  If you were to fix up the call to the nonexistent constructor above, you could compile and give it a shot.  Sadly though, you’d see nothing but a blank tab.  So let’s keep going and finish the add-in.

Step 5:  Registering for events

Now that the add-in will display, you can get to the meat of the add-in, registering for and handling events.  The following events are available for your add-in to hook.

• WindowCreated   [Called when a new playback window is created]
• WindowClosed     [Called when a playback window is closed]
• SelectionChanged   [Called when a new request is selected in the playback window]
• TestCompleted    [Called when the webtest has completed]

You have already seen how to subscribe to the WindowCreated event in Step 4 above.  The other events are subscribed to similarly and in the same place.  In fact, for this demo you will need to subscribe to each of them.  Here’s what the OnConnection method should look like after you’ve subscribed to the events.

For now, you’ll need to create stubs of each of these event handlers so that the code will compile.  We’ll get back to writing these handlers in step 7.

Step 6:  Writing the UI

Now that you’ve created the add-in, it’s time to add the meat of what you want to see.  I am by no means a UI expert, but I’ll give you enough to get started here.  I dropped a listview and a label onto my user control.  The listview I gave 3 columns – row number, viewstate size, and the URL.   The label will contain the viewstate size of the currently selected request in the UI.  It looks like this:

For the code behind the UI, I created 3 main methods.  The first is a utility method to pull out the viewstate from the response body of a request.

Next, a method to iterate through the list of requests and update the listview…

And finally, a method which will update the label with the viewstate size of the currently selected request.

Step 7:  Putting it all together

At this point, all of the code is written except the event handlers.  We just need to add calls from the event handlers to the UI update handlers and clean up memory.

The TestCompleted event is a good event to use when getting summary data.  I’ve used it to call the UpdateSummaryDetails method as shown below.

For changing data when different requests are selected in playback, you’ll want to use the SelectionChanged event.  I have used this event to call the UpdateSelectionDetails method written in step 6.

And lastly – there is a WindowClosed event which will allow you to remove your tab from playback and release any resources you may have tied up.

Step 8:  Turning it on

At this point, you’ve finished creating the add-in and it’s ready to go.  Just compile it and launch a new instance of Visual Studio.  Once you’ve launched the new instance, you can look under the tools menu for “Add-in manager”.  you should see your add-in listed and be able to turn it on.  If you want your add-in always loaded, make sure to choose the enable on startup option.

Next, just run a webtest and see the results!

If you haven’t yet heard, Visual Studio Team System 2010 has reached Beta 1 and is available for public download.  (You can find a copy of it here).  Over the next few days my colleagues and I will be writing up information about some of the most anticipated features for the load testing portion of the product.  If you haven’t yet checked out Ed Glas’s listing of the newest web and load test features, I recommend taking a look.  As we write up more of these blog entries, he will link to them directly from his list.

In this post, I’m going to describe how (and why) to use multiple load test plug-ins with your load tests.  If you want to run code at specific times during the loadtest, the best way to do that is to write a loadtest plug-in.  Prior to Visual Studio 2010 this functionality was available, but you were limited to one plug-in per loadtest.  This can be less than ideal if you want to create reusable plug-in code since all of the code had to be crammed into the same plug-in, regardless of whether it was logically similar to do so.  In Visual Studio 2010 we’ve made this quite simple.

1) Add your test plug-ins to your project and compile the project.

2) After creating your loadtest, right click on the test node in the loadtest editor, and choose “Add Load Test Plug-in”

3) Select the plug-in you wish to add.  From here, you can view its properties and set the initial values you wish for them to have at run time.  Note that you can expose as many properties as you want from your plug-ins; just make them public, settable, and of a base type such as Integer, Boolean, or String.

4) Click “Ok”, and the newly added Load Test plug-in will be shown in the editor tree.

5) Repeat the process to add as many plug-ins as your loadtest will need.

6)  If you’re worried about the order the plug-ins will execute, just click and drag the plug-ins to rearrange them.  They will run in the order you have listed.

If you know of something that fits the “My web test recorder bar isn’t working” criteria and isn’t on the list, please let me know and I’ll try to add it.

VSTS 2005 : Any OS : Recorder bar is not displaying when recording a webtest.

Fix:  Upgrade to VSTS 2005 SP1.   There are a few bugs preventing the webtest recorder bar from displaying under certain circumstances that were fixed in SP1.  If you're having trouble in VS 2005 and haven't yet upgraded to SP1, that's your first step.

VSTS 2005 : Vista  : Recorder bar displays, but the controls are disabled.

Fix:  Webtest recording using VS 2005 on Vista only works when running in elevated mode.  [When launching VS 2005, right click the icon and choose to run as administrator]

VSTS 2005, 2008 : Windows 2003 / Vista : Recorder bar comes up, but the controls are disabled.

Fix : the web test recorder bar does not work with IE enhanced security enabled.  (VSTS 2008 will actually display an error message telling you this)  IE enhanced security can be removed from within the Control panel / Add Remove Programs / Windows Setup

VSTS 2008 : Vista, Win7 (64 bit) : Recorder bar does not appear when recording a new webtest

Fix:  Vista caches the list of explorer bars you have available and the recorder bar was not included in your list.  The fix is to force Windows to rebuild that cache.  To do this, first make sure you have all Internet Explorer instances shut down, then open the 32 bit registry editor and delete the following keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021493-0000-0000-C000-000000000046}
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021494-0000-0000-C000-000000000046}

[Note: by default, the 32 bit registry editor is located in %WINDIR%\SysWow64\RegEdt32.exe]

The next time you boot Internet Explorer, your explorer bar cache will be rebuilt and the recorder bar should be available.

VSTS 2005, 2008 : Any OS : Recorder bar does not appear when recording a new webtest

Fix:  Make sure that you don’t have browser add-ons disabled.  Specifically, the web test recorder helper add-on needs to be enabled.  For Internet Explorer 7, you can find this setting in Tools / Internet options / Program [tab] / Manage add-ons.  From there, verify that Microsoft Web Test Recorder Helper is enabled.

VSTS 2008 : Any OS (IE 7) : When recording, a new web browser opens up and the new browser doesn’t have a recorder bar.

Fix:  The reason for this is that by default, about:Blank is displayed in the browser when you start recording.  This website is (by default) in the internet security zone (protected mode: on).  When you open a website in a different zone (without protected mode) it will be handled by a new instance of internet explorer.  

The fix is to do one of 2 things: a) Move about:blank into the zone where you’re attempting to record from or b) Change the default web page which is brought up when you start recording to something in the same zone as you’re trying to record.  You can accomplish this by setting the following registry key

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\WebLoadTest]

"StartingLocation"="https://server/website"

 VSTS 2005, 2008, 2010 Beta 1 : Windows 7 : When launching the recorder, the recorder bar does not appear

Fix:  The Windows 7 security model is slightly different than previous versions of windows. (go figure :)   To get the recorder to show up, you'll have to run Visual Studio in elevated mode.

VSTS 2005, 2008, 2010 : IE 8 : While recording, the recorder bar will sometimes just stop working and tell me it wasn't launched from within Visual Studio

The issue here is yet again, security.  In this case, when you cross the zones defined in IE.  When you cross between different zones (by default, these are trusted sites, intranet and internet), Internet Explorer will actually kill your existing IE process and launch up a new one.  This new IE process was, as the error message says, not launched by Visual Studio and hence the recorder cannot work.

Fix:  There are multiple fixes for this problem, any one of which *should* work equally well.

1) Turn off "Protected Mode" in Internet Explorer.  (Tools | Options | Security - There should be a checkbox to enable / disable protected mode)  You'll need to reboot IE.

2) Change the initial URL which Visual Studio loads when recording a webtest to one in the same zone as you wish to record.  The regkey to do this is below.  Note that "9.0" here corresponds to the Visual Studio version you have installed.  (2005 = 8.0, 2008 = 9.0, 2010 = 10.0)

Support for initialization and termination tests per virtual user.

In the past it's been difficult to manage operations which only have to be performed once at the beginning and/or end of a test.  Things like login, checkout, creating a user, etc needed to be managed creatively to get to work.  Visual Studio 2008 has first class support for initialization and termination tests, which, as their name implies are run at the beginning and ending of a virtual user sesson.

Adding them is easy.  Just bring up the test mix editor (shown below), select the checkboxes at the bottom, and choose which test you want to be your initialization and / or termination test.

 [Test mix editor]

Once you've selected your init / terminate tests, the webtest editor shows them as part of your scenario:

Multiple Web Test plug-ins and request level plug-ins:

With multiple Web Test plug-ins, componentizing your code is much easier in VSTS 2008.  You're not forced to cram all of the code you might need into a single plug-in so you're free to mix and match plug-ins across multiple projects without the extra overhead.  Additionally, you can also expose public properties from your plug-ins to make them even more useful on a per-test basis.  Here's a screenshot of what adding a Web Test plug-in looks like now:

True request level plug-ins are now a reality as well.  Just like Web Test plug-ins, you can have multiple request level plug-ins directly attached to a specific request rather than having to filter requests inside the plug-in.  Of course, the request plug-in infrastructure from VSTS 2005 was not removed and your existing plug-ins will run without modification.  In fact, they still provide a great way to run code after every request without adding a request plug-in to each node in the editor.  Here's a look at the new Web Test editor with multiple plug-ins added:

Lastly - worried about the order your plug-ins will run?  They run top-down in the order you see them in the UI!

For the plug-in to work, you need to have a few things set on your loadtest.

Thresholds:

For each perfcounter you intend to track, you need to set the warning and critical threshold values on that perfcounter.

Context variables:

MinLoad: <The Minimum amount of load you wish to apply, regardless of perfcounter thresholds.>

MaxLoad:  <The maximum amount of load you wish to apply, regardless of perfcounter thresholds.>

LoadStep:  <The amount of load to step when increasing or decreasing.>

LoadChangeInterval:  <How often you wish to change the load (in seconds and if necessary)>

I recently joined the Visual Studio Team Test group as a Software Design Engineer in Test.  After spending the last 9 years working on various portions of Office, the developer organization is a breath of fresh air.

From time to time I will update this blog with neat little tidbits that I've picked up or perhaps code samples for plug-ins that I've written and think that people might find useful.  If you have questions regarding my blog posts or the content therein, feel free to comment here directly and I'll get back to you.  However, if you have a general question regarding VSTS the best place to go for an answer is the VSTS forum page, located here:  https://forums.microsoft.com/msdn/showforum.aspx?forumid=19.

--Mike