Search This Blog

Welcome to Machers Blog

Blogging the world of Technology and Testing which help people to build their career.

Thursday, August 7, 2008

Performance testing using VSTS

Web Testing in Visual Studio 2005 Team System

Lab 1: Creating a Web TestLab ObjectiveThe objective of this lab is to provide an introduction to the web testing functionality that comes with Visual Studio Team System. Web testing has been added to the Suite, Developer, and Tester SKUs. The web testing functionality enables developers and testers to record tests against a website and then to play back those tests at a later time either interactively with the developer watching or within a build script. This lab will give an overview of how web tests are created and how simple validation can be performed on the text within the web page. Team System’s Web Testing functionality records the HTTP traffic that is sent across the network and then records and analyses the HTTP traffic returned. The recordings are made in the application network layer so it is able to handle encrypted traffic sent using HTTPS. However, it does not execute or verify any rendering of the HTTP traffic. As a result, it does not have any built in support for verifying browser compatibility of a website or running any client site script that may be part of the downloaded web page.In this lab, you will learn how to:

Add a web test to a projectRecord the web testAdd validation to the web test

Estimated time to complete this lab: 30 minutesExercise 1 – Test the Personal Website ApplicationIn this exercise we will record a web test. Focus on becoming familiar with the interface, as well as how the recorder works.Task 1 – Create the web test projectTo begin, we add a web test to the test project. In addition, we reconfigure the Personal Website so that it no longer uses a dynamic port. This allows the web test to run consistently against the same port.1. Navigate to the following folder (a shortcut may be provided for you on the desktop):C:\Documents and Settings\darren\HandsOnLabs2. Double-click on the folder entitled: WebTestLab3. Delete the Begin folder (if present)4. Right-click and copy the Copy of Begin folder5. Right-click and paste within the folder6. A folder called Copy of Copy of Begin should appear7. Right-click on the Copy of Copy of Begin folder8. Select Rename9. Rename the folder to Begin10. Navigate to C:\Documents and Settings\darren\HandsOnLabs\WebTestLab\Begin.11. Open the WebTestLab.sln file.12. Select File->Add->New Project… from the Visual Studio menu.13. Expand the Visual C# tree and select Test for the project type. Select Test Project from the installed templates section.14. Name the project WebTest and set the location to C:\Documents and Settings\darren\HandsOnLabs\WebTestLab\Begin (where C:\Documents and Settings\darren maps to the environment variables %HOMEDRIVE%\%HOMEPATH%).15. Click on OK to create the test project.16. Optionally delete AuthoringTests.txt, UnitTest1.cs, and ManualTest1.mht from the project as we will not be using them in this exercise.

Figure 1: Solution after WebTest project created The Solution Explorer is shown in Figure 1 if the additional test files are removed.17. In Solution Explorer click on the …WebTestLab\Begin project (not the test project) and press F4 to view the properties pane for the project.18. Verify the Use dynamic ports is set to False and the Port number to 18770 as shown in Figure 2. Since the testing framework will need to access the same web page over and over, if the port setting was configured to use dynamic ports, it wouldn’t be guaranteed that the Development Server would always start on the same port.

Figure 2: Configure the ports to not be dynamicTask 2 – Create a web test1. Right click on the WebTest project and select Add->Web Test… as shown in Figure 3.

Figure 3: Add a Web Test fileThis will open up Internet Explorer in “Record” mode.In the address bar for Internet Explorer, enter http://localhost:18770/Begin/ in order to navigate to the correct web page for testing. (You can right click on the ASP.NET Development Server tray icon and select View In Browser (does not exist) to obtain the correct URL - see Figure 4)

Figure 4: ASP.NET Development server Tray IconEnter the user name labuser and the password L@buser.Press login to log in to the web site.Notice in the Web Test Recorder Bar (Figure 5) that when the new page comes up, another entry is displayed in the Web Test Recorder list

Figure 5: Web Test Recorder after the login succeedsClick on the Stop button in the Web Test Recorder window to stop the recording of the test.Open the WebTest1.webtest file and examine the contents (shown in Figure 6). Expand the second entry in the test tree and examine the Form Post Parameters. These are the values that are passed around, and they can be modified from within the test.

Figure 6: Finished testTask 3 – Execute the test and validate resultsBy default, the web test will verify that a particular web request will not return an error for itself or any of the links within the returned page. However, this alone may not be sufficient to verify the website behavior. In addition, you may want to verify the content within a page. In the following task we add validation to a URL.

2. Press Ctrl-F5 to run the tests. (The ASP.NET Development Server tray icon from previous executions should still be displaying, indicating the website is still running.) Although the test completes successfully, all that was verified was that the website could be loaded. There were no validation tests performed.3. Open the Test Results window and double click on the WebTest1 result.4. From this view, you can see what requests were made and also what page was displayed. Click through the Request listbox and view the results from each (see Figure 7).

Figure 7: Web Test Results Window5. Close down the WebTest1 results window.6. Open the WebTest1.webtest.7. To add validation rules to the second web request, right click on the second test and from the menu select Add Validation Rule….

Figure 8: Add a validation rule to the testSince the user should now be logged in, the web page should show “Logout” somewhere on the page, so let’s look for that text.8. From the Add Validation Rule window, select Find Text and in the parameters for the text, type LOGOUT for the Find Text field and set Ignore Case to True.

9. Click on OK to close down the window and add the validation to the test.10. Re-run the test by pressing Ctrl-F5.11. When the test finishes, open the Test Results window again and double click on the WebTest1 run.12. Select the third item in the Request list and then select the Details tab. Notice that the validation test that was added also passed.

Figure 9: Test results after performing text validation

Load Testing in Visual Studio 2005 Team System

Lab 1: Creating a Load TestLab ObjectiveIn this lab you will create two types of load tests. First, the test will focus on creating a load based on a web test. Second, another load test will be created using a unit test. The support for both types of load tests demonstrates that the load testing functionality within Visual Studio Team System can be used both with web sites and rich client n-tier/service oriented applications.

a) Add a load test to a Test projectb) Run the Load Test Wizard, adding a web test c) Define a new Load Test that uses Unit Testsd) Review the graphs created by the Load Tests

Estimated time to complete this lab: 30 minutesExercise 1 – Creating Load Test based on a Web TestIn this exercise you will create a load test based on a web test. It will familiarize you with the load test user interface as well as with how the recorder works.Task 1 –Setup2. Navigate to the following folder (a shortcut may be provided for you on the desktop):C:\Documents and Settings\darren\HandsOnLabs3. Double-click on the folder entitled: Load Test4. Delete the Begin folder (if present)5. Right-click and copy the Copy of Begin folder6. Right-click and paste within the folder7. A folder called Copy of Copy of Begin should appear8. Right-click on the Copy of Copy of Begin folder9. Select Rename10. Rename the folder to Begin11. Navigate to C:\Documents and Settings\darren\HandsOnLabs\Load Test\Begin\WebTest.12. Double click on the WebTestLab.sln file to open the solution inside of Visual Studio 2005.Task 2 – Create a load test13. Right click on the WebTest project and from the menu select Add->Load Test….14. This opens up the New Load Test Wizard. On the Welcome screen, press Next.15. On the Scenario screen, type General Use for the scenario name, then press Next.16. Select Constant Load with a user count of 25 on the Load Pattern screen, then press Next.17. On the Test Mix screen, select the Add button and then choose the WebTest1 method by moving it into the right list box and clicking the OK button, then press Next.18. For Browser Mix, accept the default saying that IE will be 100% of the browsers, then press Next.Notice that it is possible to specify additional Microsoft browsers. The browser mix identifies the percentage of calls emulating a particular browser to the server. Only if the server provides different responses depending on the client browser will the mix have any effect on the load test.19. On the Network Mix screen, select the dropdown list and change the Network Type to Cable/DSL 768K, then press Next.Additional network simulations can be added on this screen as well to simulate various load conditions.20. Press Next to accept the defaults for Counter Sets.21. Modify the Run Settings so that the Run duration is only 2 minutes. For the Description, type To simulate general use load.22. Click Finish to close down the wizard. The resulting Load Test is shown in Figure 1.

Figure 1: Configured Load Test23. Start the ASP.NET Developer Server that hosts the web site by right clicking on the …\WebTest\ web project and selecting the View in Browser menu.24. Verify the WebTest project is set as the startup project and press Ctrl-F5 to run the tests.25. To view the test data while the load test is running, right click on the LoadTest1 test in the Test Results window and select View Test Results Details.

Figure 2: Open up the test results details26. Data is displayed in a graph form (see Figure 3) and is updated based on the Sample Rate configured in the wizard (does not work).

Figure 3: Test results as test is running27. When the tests are finished, a dialog box, shown in Figure 4, is displayed notifying you that the test has completed and asks if you would like to refresh the data in report to display the detailed results. (This assumes you displayed the detailed results before the tests completed.)

Figure 4: Dialog window displayed when tests complete Select Yes.28. The graph can be changed between Default and . When in Default mode, user load, requests per second, and avg. response time is displayed. When viewing the graph, % processor time and available megabytes are shown.

Figure 5: GraphTask 3 – Modify the load test19. Double click on LoadTest1.loadtest to open the load test designer.20. Navigate through the entries in the tree view, paying attention to the Properties window to see what options are available for each entry.21. Under the Scenarios->General Use node, select the Constant Load Pattern node.22. Using the Properties window, change the Load Pattern – Pattern value from Constant to Step.23. Examine the default values associated with this pattern, but don’t change any items.24. Rerun the load test by pressing Ctrl-F5. The results are shown in Figure 6.

Figure 6: Test run after changing to Step BasedExercise 2 – Creating Load Test based on a Unit TestIn this exercise you will create a load test that uses unit tests rather than web tests for the load.Task 1 –Setup1. Navigate to C:\Documents and Settings\darren\HandsOnLabs\ LoadTestLab\Begin\UnitTest.2. Double click on the TicTacToeLogicSolution.sln file to open the solution inside of Visual Studio 2005.Task 2 – Create a load test1. Right click on the TicTacToeLogicTest project and from the menu select Add->Load Test….2. This opens up the Load Test wizard. On the Welcome screen, press Next.3. On the Scenario screen, type General Use for the scenario name.4. Set the Think time between test iterations value to 5, then press Next.5. Select Constant Load with a user count of 25 on the Load Pattern screen, then press Next.6. On the Test Mix screen, select the Add button and then choose the MakeMoveTest method. Press OK. Notice that when the test is not a web test, Browser Mix and Network Mix disappear as options in the wizard, then press Next.7. Press Next to accept the defaults for Counter Sets.8. Modify the Run Settings so that the Run duration is only 2 minutes. For the Description type To simulate general use load.9. Click Finish to close down the wizard.

Figure 7: Configured Load Test10. Verify the TicTacToeLogicTest project is set as the startup project and press Ctrl-F5 to run the tests

11. To view the test data while the load test is running, right click on the LoadTest1 test in the Test Results window and select View Test Results Details.

Figure 8: Open up the test results details12. Data is displayed in a graph form and is updated based on the Sample Rate configured in the wizard. Notice on this graph, which appears in Figure 9, that Tests per Second and Average Test Time is displayed instead of Requests per Second and Average Response Time, which were displayed in the web test.

Figure 9: Test results as test is running13. When the tests are finished, a window is displayed notifying you that the test has completed and asks if you would like to refresh the data in report to display the detailed results. As before, this only occurs if you opened the Load Test before it had completed running Figure 10: Dialog window displayed when tests complete14. The graph can be changed between Default and . When in Default mode, user load, tests per second, and average test time is displayed. When viewing the graph, % processor time and available megabytes are shown. Figure 11: Graph15. Counters can also be added to the individual graphs. Expand the Overall->Test->Passed Tests node and double click on the _Total item. The resulting graph is shown in Figure 12.