Showing posts with label Visual Studio 2008. Show all posts
Showing posts with label Visual Studio 2008. Show all posts

Wednesday, October 21, 2009

ASP.Net Web sites Load Testing using Visual Studio Team system(VSTS)


This document demonstrates how to create a load test using Visual Studio Team System to simulate workload against web applications and analyze the performance metrics from the resultant load test.

Note 1:

Load Tests should be executed ONLY in VSTS 2008. The reason being dynamic parameters are not properly handled in VSTS 2005 which might result in any of the following listed common errors.
  • Context parameter ‘HIDDEN1._EVENTTARGET’ not found in the test context
  •  Request Failed: Context parameter ‘HIDDEN1._VIEWSTATE’ not found in the test context
These errors occur when the Web test attempts to use a hidden field in the Web test context that it was unable to locate and extract from a previous response page it received. The dynamic parameters change every time the web test runs which was not handled in VS 2005 and this is addressed in VS 2008.
Another common error expected during execution of a web test is “500 Internal Server” which indicates a bug in the Web application.

Note 2:

  • To set up complete test project and run both web tests as well as load tests start from Step 1 (Page 2)
  •  To execute an existing Load test, Start from Step 14 (Page 15) 

Step 1:

Creating a Test Project

Create a test project that will capture scenarios from web application simulating the workload. Name your project; by default it will have an empty unit test. We will add Web Test and Load Test to this project in later steps.
We create the test project by selecting new project option from File menu in VSTS IDE. Create New Project dialog box pops up prompting to create new test project.  In the New Project dialog box choose Test Project under Project Types pane and give appropriate name for project and click OK as shown below.



Creating Test Project


Step 2:

Creating a Web Test:

In this step, we’ll create Web Test. This web test will be used in Load Test. In the Solution Explorer,
Right click the project click Add and then click Web Test. This opens up a new instance of browser with special Web Test Recorder explorer bar as shown below



Creating a Web Test


Step 3:

Recording Web Test:
  1. In the new browser instance, on the address bar, enter the URL of asp.net website and hit enter button.
  2. Below screenshot shows a demo website which I use. This is part of scenario being recorded for subsequent playback.
  3. Once you open your website, browse pages to generate scenarios to be used later for load testing.
  4. Once the desired actions are recorded, close the browser window and save the test.


Recording Web Test

Automatically, the project will now include the Web test case file along with each of the recorded requests as shown below


Generated Web Test Case


Step 4:

Running a Web Test:

  1. In the main window of Web test click the Run Test button in the left hand corner. Or you can right click the Web test and choose the option Run Web Test.
  2. The Web test will be run for a single user, and result displayed in the main window as shown in the figure.
  3. This will open up the Test Results windows and mark each test as pending while it is in progress and Passed/Failed once execution completes.  You can view test results in Test Results window tucked at the bottom as shown below


Running Web Test



Step 5:

Adding Load Test:

In this step, we’ll add the Load Test to the existing project. We will then set various properties of your Load Test in subsequent steps.

  1. In Solution Explorer, right-click the project node. Select Add, and then click Load Test.
  2. The New Load Test Wizard starts.
  3. The Welcome page of the New Load Test Wizard is the first page.
  4. Click Next.


New Load Test Wizard


Step 6:

Specify Scenario Settings:


Configuring Think time for Load Test

The choice of Think Time Profiles depends upon intend of usage.
  • By choosing to use recorded think times, Think times are used exactly as they were recorded in the Web test. Because a load test simulates multiple users, using the same think time could create an unnatural load pattern of synchronized virtual users.
  • By choosing normal distribution, think times are used, but varied on a normal curve. Provides a more realistic simulation of virtual users by slightly varying the think time between requests. Normal distribution will simulate more realistically the usage of the Web application where users will differ in think time fluctuation.


Step 7:

Specify Load Pattern Settings:

In this step, you will set the load pattern, with the number of concurrent users. The number of concurrent users represents the business volume like total number of users – sessions in a given time; we’ll use default Constant Load Pattern for our case. Instead, we can also use a Step load Pattern as necessitated by the situation.



Load Pattern Settings


Step 8:

Specify Test mix model for Load Test


Specify Test mix model


  • Based on total number of tests:
  • This model of test mix determines which test is run when a virtual user starts a test iteration. At the end of the load test, the number of times that a particular test was run matches the assigned test distribution
          Based on number of virtual users:

  • This model of test mix determines the percentage of virtual users who will run a particular test. At any point in the load test, the number of users who are running a particular test matches the assigned distribution. Follow this model when you’re basing the test mix on the percentage of users running a particular test.
          Based on user pace:

  • Over the course of load test, each test is run the specified number of times per user per hour. Follow this model when you want virtual users to run tests at a certain pace throughout the load test.


Step 9:

Add Web Test to Load Test:


Adding Web Test to Load Test

  1. In the Add tests to a load test scenario and edit test mix screen, Click the Add button.
  2. In the Add Tests dialog box that opens, in the Available tests list box, select the Web test created in previous steps and then click the right arrow to move it to the selected tests list box.
  3. In the Add Tests dialog box, click OK


Step 10:

Specify Browser Mix:

In this step, you add the browser mix by specifying types of browsers being used and distribution ratio for each type of browser.
  1. From the drop-down list of browser types, select the IE 6.0 browser to add to the mix.
  2. Our Load testing uses IE browser exclusively so the distribution of 100%
  3. Then click Next.



Browser Settings


Step 11:

Specify Network Mix:

In this step, you add the network mix by specifying types of network, on which the application is accessed and distribution ratio for each type of network.

  1. Typically in our scenario, we’ll be accessing from across LAN for testing purpose, so our network mix consists of LAN
  2. From the Network Type drop down, select the LAN type
  3. Then click Next.



Specifying Network Mix


Step 12:

Specify target computer and counter settings

In this step, you will specify the performance counters to be used for capturing load test results, in order to validate your tests against the objectives

Click Add computer, enter the computer name or IP address. Click on the check box on the left side of the computer. The default counters will be displayed. You may continue to add other computers that need to be monitored.



Computer and Performance counters settings

Select the check boxes, Application, ASP.Net and .NET application. Select the counters applicable to different servers, marking the check boxes on the counters under the machine chosen


Configuring the Performance counters



Step 13:

Specifying Run time Settings:

In this step, specify set of properties which determine how the Load test runs. The run settings determine the length of the test, warm-up duration, maximum number of error details reported, sampling rate, validation level etc.

  1. On the Run Settings page choose your initial settings.
  2. Set the Warm-up duration as 5 minutes.
  3. Set Run duration 10 minutes (can vary in actual load test)
  4. In the Description edit box specify the description of the Run Settings.
  5. Accept the other default settings.
  6. Click Finish. Your Load test is opened in the Load Test Editor.




Review and Edit run settings for a load test


Step 14:

Run the Load Test:

In this step you run the Load test to see, how the Web application responds to the web test, under the load simulation.
  1. In the Load Test Editor right click on the Load Test and select Run Test option.
  2. Click View menu in main window then select Full Screen, this will maximize the viewable area.
  3. Once the Load test is complete, it displays a message, "Load Test 'LoadTest1' is complete. The test data currently displayed only represents a portion of the available results. Would you like to view the detailed results from the load test result store?"
  4. Click Yes on the message.






Load Test in Progress


Dialog Box shows up asking for detailed results from load test result store


Step 15:

Analyze Test Results:

  • Analyze if the number of tests completed and failed tests are meeting the performance goals as identified in the Performance Goals section. Click on tables then tests
The number of Demo_Browse completed scenarios is 713 which mean total numbers of 713 tests are posted.

Test Results in Tables Format
  •  
Load Test Results in Graph format

                Key Indicators parameter values
  • Key Indicators from a closer view

Load Test Summary

Load Test Summary Continued


Processor Time and Memory Usage counters:

Note:
Following test results are from different web tests created from asp.net web application. These results vary from the above results.

RUN 1:

Controller and Agents Resources
Machine Name
% Processor Time
Available Memory at Test Completion (Mb)
VHV000204
55.0
79



Test Results
Name
Scenario
Total Tests
Failed Tests (% of total)
Avg. Test Time (sec)
Browse_WebTest
LoadTest1 
147
0 (0)
70.8
Search_WebTest
LoadTest1 
165
0 (0)
69.1
ApplicationInsert_WebTest
LoadTest1
224
0 (0)
51.8
Load Test Summary Continued


RUN 2:

Controller and Agents Resources
Machine Name
% Processor Time
Available Memory at Test Completion (Mb)
VHV000204
50.9
71


Test Results
Name
Scenario
Total Tests
Failed Tests (% of total)
Avg. Test Time (sec)
Browse_WebTest
LoadTest1
79
0 (0)
94.2
Search_WebTest
LoadTest1
87
0 (0)
93.1
ApplicationRetrieval_Webtest
LoadTest1
99
0 (0)
76.8
ApplicationInsert_WebTest
LoadTest1
114
0 (0)
69.0

At a Glance:
We can also specify threshold values for performance counters like specifying processor time and errors to watch for critical levels.
Session duration is sometimes important. The modeled Demo_Browse scenario session time is negligible.
Adopt an incremental approach esp. for Think times and number of users so as to model the work load accurately and precisely.

Reference:

13

Sunday, October 11, 2009

Java script debugging support in Visual Studio 2008

JavaScript debugging in Visual studio 2008:
Every one of us is well aware of problems posed when debugging client side script code. This article talks about various new techniques and troubleshooting tips that help debug client side script code efficiently in Visual studio 2008.

Client side script code means that it can be VB Script or J# script or Java script. Client side script is embedded in .aspx pages, .html files or inside .js files. Generally, client side script is loaded by client application like Internet Explorer running on your local machine.

There are two different ways in which can debug client side scripts in Visual Studio 2008. They are:


  • Visual Studio .Net IDE

  • Microsoft Script Editor
Configuring machine to enable client side script debugging:
Before we start to debug client side script code, certain settings have to be made like

Enable client side script debugging in Internet Explorer. To do this go to Tools ->Internet Options and on advanced tab make sure that the Disable script debugging is unchecked. Below listing highlights above step              



Enable Script Debugging in IE


Visual Studio .Net IDE:

You can now debug client side script code directly in Visual Studio 2008 environment. It is made possible through powerful debugging options that enable you to debug managed code, script code, T-SQL code, and native code. Visual studio 2008 supports 64-bit debugging either locally or remotely. You can now debug Java scripts hosted by IE. Visual studio debugger provides enhanced new features like data tips, visualizers which allow us to view contents of complex variables and data types in a meaningful way. Let’s see new capabilities using an example


We create an ASP.NET web application that greets the user. We use Java Script for processing the result.


  1. Open Visual Studio 2008 Environment and On the File menu, choose new website and choose your own specific language(VB or C# template)

  2. Copy this code and press F5 (Start Debugging) to start debugging. IEXPLORE.EXE process is attached automatically to debugger. We are using IE to load the scripts so IEXPLORE.EXE is attached.

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Greetings</title>
<script language ="javascript" type="text/javascript">
   function btnGreeting_Clicked()
   {  
        debugger
        var firstname;
        var lastname;
        var greeting;
                  firstname = document.all('txtName1').value;
        lastname = document.all('txtName2').value;
        greeting = "Hai" + " "+ firstname + " " + lastname + " " + "Have a great Day!";
        alert(greeting);
        return false;
    }
</script>
</head>
<body>
   <form id="form1" runat="server">
    <table>
   <tr>
     <td width="100">
             <asp:label id="lblFirstName" runat="server" Width="125">
                 FirstName:
              </asp:label>
      </td>
      <td width="50">
             <input id="txtName1" type="text" maxLength="30" name="txtName1" style="width: 140px">
      </td>
    </tr>
    <tr>
     <td width="100">
             <asp:label id="lblSecondName" runat="server" Width="125">
                 LastName:
              </asp:label>
      </td>
      <td width="50">
             <input id="txtName2" type="text" maxLength="30" name="txtName2" style="width: 139px"/>
      </td>
     </tr>
    </table>
  <br>
<table>
  <tr>
      <td width="150" align="center">
       <input id="btnGreeting" onclick="return btnGreeting_Clicked()"
         type="submit"  name="btnGreeting" value="Greeting">
      </td>
   </tr>
</table>
    </form>
</body>
</html>

HTML Listing for greeting program


You should always include keyword “debugger” as the first line of Java script code you wish to debug in Visual studio 2008. This keyword automatically invokes Visual Studio client side debugger.


Once we run above code, we get the below output.

Output listing for greeting program


Return to Visual Studio .Net environment and click Debug ->Other windows->Script Explorer and set the breakpoints at the desired places. 


Again return back to IE. Give the values for the first name and last name and click greeting button. You can see control returning to Script Explorer as shown in below listing. Use F10 to step over each line of code. Similarly, use F11 to step into each line of code. In script explorer, you can set new breakpoints and use Locals Window to inspect values of local variables in the script. Immediate Window evaluates the values of variables. See the Data tips by hovering over the variables.


To invoke Immediate Window click Debug->windows->Immediate. Similarly Locals Window is invoked via click Debug->windows->Locals


Script Explorer in Action


You can also use Command Window to execute commands against script code variables like Debug.print command. To invoke Command Window click->View->Other Windows->Command Window. Several other features like Autos Window, Call Stack Window are also accessible. You can observe Command Window in below listing

Script Explorer in action


Microsoft Script Editor:


Microsoft Script Editor (MSE) is powerful tool which debugs Java scripts using Internet Explorer as script host. It is shipped as free component in Office XP and Office 2003. This is an attractive option when all that you need is to debug Java scripts for IE and you don’t have Visual studio .Net installed on your machine. You can check for MSE in your machine by clicking View option on IE and see if you can find script debugger option. (Please see below listing)



Let’s use same example to demonstrate debugging client side script code using MSE.


Going with the same example, Open the page in Internet Explorer and click View as shown in below listing


IE with MSE


After clicking Open /Break at Next Statement you can see Just-In-Time Debugger dialog box




Click yes to use MSE and you can see below listed dialog box

Click Ok and you can see Microsoft Script Editor Environment open up and MSE offers almost same IDE as Visual studio.Net and similar others features like Locals Window and Command Window. You can use same F10 to step over code. (See the below listing)

Microsoft Script Editor IDE


Alternatively, you can also use put a line like this in Java script
  Debugger;


Debugger keyword will create a breakpoint. When this breakpoint gets hit, your MSE will launch and you will see a message that says "An unhandled exception 'Script Breakpoint' has occurred in script. See below given listing



Just-In-Time Debugger


Choose yes and remaining steps are same as discussed in first method of working with MSE. Control is transferred to Script Editor IDE.



Microsoft Script Editor IDE


Finally you get after successful debugging you get this message as output



When you are done debugging make sure the browser is not waiting for debugger. Simply press F5 to continue or else explicitly close the debugger. Click ‘Yes’ when it prompts to close debugger.  This way you can save from computer hang up. (It happened to me!!) When using MSE.



Visual Studio 2008 Integrated debugger is very powerful and rich in features. You can now debug client side script code with the same flexibility as you used to have with debugging server side code. You can say good bye to clumsy alert statement technique employed in Java script debugging. Microsoft Script Editor is another attractive option for debugging with no fewer features compared to Visual studio 2008 debugger.