Export (0) Print
Expand All

Record and run a web performance test

Web performance tests are included in load tests to measure the performance of your web application under the stress of multiple users. You record a web performance test by browsing a website as if you were the end user. As you move through the site, requests are recorded and added to the test in Visual Studio Ultimate. After you finish recording, you can customize the test by editing its properties.

We’re going to use a sample ASP.NET app. It has three .aspx pages—the default page, Red, and Blue. The default page has a radio control to choose either Red or Blue and a submit button. The other two .aspx pages are very simple. One has a label named Red and the other one is labeled Blue. When you choose submit on the default page, one of the other pages appears. You can create an app like that, download our sample, or just follow along with your own web app.

  1. If you don’t have Visual Studio Ultimate, get it here.

  2. Press CTRL+F5 to run the web app in the browser. Copy the URL. You’ll need it when you record your test.

    Run the test and copy the URL

  1. Add a web performance and load test project to your solution using either Visual C# or Visual Basic template. Name the test project ColorWebAppTest.

    Name the web performance and load test project

  2. Rename WebTest1.webtest to ColorWebTest.webtest.

    Rename the web performance test

  1. Start recording the test.

    Add a recording to web performance test

  2. Copy and paste the URL from the website you’re testing into the browser.

    Paste the URL into the web browser

  3. Browse through your web application. For example, browse to the Red and Blue pages using the Submit button.

    Navigate to the Blue page

    The web test recorder displays the HTTP request and response URLs as you navigate through the web app.

  4. Choose Stop on the test recorder.

    A dialog box displays a message that Visual Studio Ultimate is detecting dynamic parameters, along with a progress bar.

    Because the ColorWebApp does not have any dynamic parameters, you’ll get a message that it did not detect any dynamic parameters to promote.

    After the dynamic parameter detection finishes, the web performance test editor displays the test as a list of the HTTP requests.

  5. Open request details to edit some request properties that are commonly modified in tests, including Reporting Name, Think Time and Response Time Goal. (You can also customize other request properties in the properties window.)

    Choose the request details button

    Enter response time goals

    • Reporting Name: This is great for helping identify specific requests while running the test, viewing the test results, and in identifying requests in reports.

    • Think Time: You can use think times to accurately reflect realistic human pausing.

      Be aware that the think times reflect your pausing as you record the test. You can edit the think times to reflect what your users really do when they run the application. Think times set the pace of the test in load tests.

    • Response Time Goal: This verifies that the page loads within the time specified.

      If you want to know that your response time goals were not met, set the tolerance to a value greater than 0. The test will fail if the response time goal exceeds the tolerance value—tolerance is a percentage of the response time goal.

      Enter a value for the respone time tolerance

      When you run your web performance test under stress in a load test, you will be able to analyze each page for the following values:

      • The average response time for the page

      • The percent of test iterations that meet the response time goal for the page.

  6. Save your project.

  1. Run the test.

    Run the test from the Web Test Editor's toolbar

    As the test runs, each of the HTTP requests you recorded appear. Notice how the reporting names help you distinguish between the Red and the Blue pages. Without reporting names, they would display as default.aspx.

    Running web performance test

  2. After the test is finished, the test results are updated.

    Completed test showing test results

A: Configure the add-ons in your web browser to include web test recorder. Also, verify that you’re not running in protected mode.

A: To access web sites that are outside your firewall, set the proxy property.

  • Ask your network administrator for a valid proxy server name, or type default to use Internet Explorer's proxy settings.

    Set the proxy property for the test

    Using default can cause performance issues when including your test in a load test.

A: Yes, you can create a test by extracting individual requests from an existing test. Use this method to factor your tests into reusable test components and then call them from other tests. For example, you could factor a shopping application into log in, browse, buy, and log out components.

  1. Extract the web performance test, enter a name, and select the first and last request that you want to include.

    Extract requests into a new test component

  2. Add a call to another web performance test.

    Add call to another web performance test

    The test is added to the request tree.

    Call to web performance test added to test

    If the new test is not in the correct location in the tree, drag it to the correct location.

Total time represents:

  • For a request, it is the total page time. This is the amount of time it took to retrieve the request and all its dependents.

  • For a transaction, it is the transaction time.

  • If your test includes component tests, it is the duration of the component.

A: Although you can add validation rules in web performance tests, we recommend that you use coded UI tests for this purpose.

A: Yes, you can add loop logic to web performance tests, and you can configure each loop with specific conditional rules and properties too. This provides a simple way to have requests within a web performance test run multiple times.

Loops should model what a single user will do on the site. Looping should not be used to have a single user looping hundreds of times. Instead, let the load tests do this. When possible, use less than 10 iterations in your loops because it can consume a lot of memory.

When you add loops to a web performance test, the length of time the test runs could impact the test mix in your load test. Reset the test mix if necessary.

  1. Assuming we’re using the ColorWebApp sample modified in Adding a data source to a web performance test, expand the second request and verify that the value for RadioButtonList1 is ={{ColorsSQL.Color.ColorName}}.

    Verify data source

  2. Insert a loop on the same request node.

    Insert a loop

  3. Choose Counting Loop and then change the values for both the Max Number of Iterations and the Iterations properties to 8.

    Select rule and modify properties

  4. Expand the Data Sources node, and then select the Color table. Change the value for the Access Method property to Random.

    Specify random access method
  5. In Solution Explorer, open local.testsettings and in the Test Settings dialog box, select Web Test, and verify that the Fixed run count option is selected and that its value is set to 1.

    Set fixes run count to 1 in test settings

  6. Close and save the test settings file.

  7. Run the web performance test. There will be eight loop iterations of the web request that you added the counting loop to. These iterations randomly select either the red.aspx or the blue.aspx pages.

    Run results showing randomized loop iterations

A: Yes, you can add if/then branching logic to tests and then assign specific conditional rules and properties. For example, you could create a condition on a web request to verify if a cookie is present.

  • Insert a condition into the test.

    Add conditional rule to test

    The request is now encapsulated within an “if” condition.

    Conditional rule added to test

A: Yes, if the site uses either basic authentication or integrated Windows authentication. If you want to reuse the credentials in another test, you can copy and paste the web performance test into a new test and re-record it.

  • Choose the Set Credentials button and enter the name and password.

    Set the user credentials for the test

    You can also bind the name and password to a database.

A: Yes, you can easily change servers by re-mapping the web server context parameter to another server. You do not have to re-record the test, or re-code a coded test.

  1. Parameterize web servers.

    Parameterize the web server

    Select the web server that you want to parameterize and then choose change.

  2. Type a context parameter name and select a server option.

    Enter context parameter names

    The context parameter displays in the test’s requests.

    Parameterized web server nodes

A: Yes, you can use a transaction. Think of a transaction as starting a timer, requesting a page, requesting another page, and then ending the timer. After you create a transaction, you can drag requests in to and out of it.

When using web performance tests in a load test, transaction response times are displayed in the transaction table of the Load Test Analyzer.

  1. Select the request where you want to start the transaction. Right-click and select Insert Transaction.

    Insert a transaction into test

  2. Enter the name, and the starting and ending request for the transaction.

    Name, starting and ending requests for transaction

  3. The transaction is added to the test.

    Transaction added to test

A: You only need to generate a coded test if you can’t meet your testing needs without adding some custom code. See Generate and run a coded web performance test.

A: Yes, use the mstest.exe command line tool.

  1. Open a Visual Studio command prompt.

    Open the developer command prompt

  2. Change directory to the folder that contains the test. For example: CD C:\Users\abarrl\Documents\Visual Studio 2013\Projects\ColorWebApp\TestResults.

  3. Use the mstest.exe in one of the following procedures.

    • Run a single test: Use the /TestContainer argument. A .webtest file or .loadtest file is considered a test container and a DLL that contains unit tests is also a test container. For example, if you have a web performance test called WebTest1.webtest, use this:

      mstest /TestContainer:WebTest1.webtest

    • Run multiple tests: Use the /TestContainer argument multiple times. For example, if you want to execute WebTest1.webtes and WebTest2.webtest, use this:

      mstest /TestContainer: WebTest1.webtest /TestContainer: WebTest2.webtest

    • Run a test that specifies deployment items: When you run tests from the command line, you cannot take advantage of the automatic processes in Visual Studio Ultimate. When you run a test in Visual Studio Ultimate, it tries to determine what dependencies need to be deployed in order for the test to run. For example, if you have written a custom validation rule or a custom extraction rule, these would be dependencies.

      Be explicit about what you deploy. For example, if you have a DLL that needs to be deployed for test, you’ll need run mstest and specify the /testsettings parameter. Test settings can also include deployment items.

      mstest /TestContainer:WebTest1.webtest /TestSettings:NewOrEditedTestSetting.testsettings

    • Run a distributed test using a test controller and test agents: When you run a test, you need to create or use a test setting that has a test controller specified in it by using the /testsettings parameter.

      mstest /TestContainer:WebTest1.webtest /TestSettings:NewOrEditedTestSetting.testsettings

    • Run a coded web performance test: Use the /testcontainer argument set to the DLL name that contains the coded test:

      mstest /TestContainer:TestProject1.dll

      When you specify a DLL for the test container, mstest will execute all of the tests within the DLL. If you want to execute just one test within a DLL, you can use the /test argument. For example, to run WebTest1Coded contained in a DLL, use the following:

      mstest /TestContainer:TestProject1.dll /Test:WebTest1Coded

      If you wanted to execute two web performance tests, specify multiple /Test arguments:

      mstest /TestContainer:TestProject1.dll /Test:WebTest1Coded /Test:WebTest2Coded

    • Specify a test results file: Results file (.trx file) are saved using a unique name that contains user, machine, and a timestamp. If you want to specify the name of the results file and where it is generated, use the /resultsfile parameter.

      mstest /TestContainer:WebTest1.webtest /resultsfile:c:\results\MyResults.trx

A: To correct this, convert your test into a coded web performance test and add the EncodeRedirectedUrl property in your implementation of the WebTestRequest class to true:

WebTestRequest request1 = new WebTestRequest("http://localhost:16939/Default.aspx");
request1. EncodeRedirectedUrl = true;

Web sites that use script or ActiveX controls might display this error message:

Your security settings do not allow Web sites to use ActiveX controls installed on your computer. This page may not display correctly...

The web performance test engine uses standard HTTP request/response messages to communicate directly with the target Web server. It does not execute JavaScript or ActiveX controls. A real browser would potentially display some additional dynamic content in the page. Typically, no user action is required in response to this message.

A: Yes.

  1. On the Tools menu, choose Options.

  2. Expand Test Tools, and then choose Web Test.

  3. Configure the following options:

    • Specify the default starting URL   The default value for where web performance tests will start in the Web Performance Test Recorder.

    • Hidden field matching   Specify if hidden field matching is performed immediately after recording the web performance tests.

    • Dynamic Parameter detection   Specify if dynamic parameters are detected immediately after recording web performance tests.

    • Recorder dependents   Specify if recorder dependents are put under page immediately after recording web performance tests.

    • Internet Explorer Instances   Specify if web performance tests record from all the open instances of Internet Explorer when while they are recorded.

    • Add or remove content types as binary payloads   Add or remove content types to be considered as binary payloads.

© 2014 Microsoft