| Team Services |
You can record and then replay cloud-based load tests on your web app or website directly using an HTTP Archive file and Visual Studio Team Services.
Before you start:
This feature is currently a preview version. During the preview period it is available to all users except Stakeholders. You can use your monthly free 20,000 virtual user minutes (VUM) allowance to try it. If you want to use load testing beyond this, you can set up billing for your Team Services account.
Create your Visual Studio Team Services account, if you don't have one already.
About HTTP Archive testing
If you have used cloud-based load testing before, you may be familiar with the ability to get performance information on your app when under load by using the Visual Studio Team Services web portal. It's a great way to:
- Quickly run a URL-based load test for your app; you just need to enter the app URL.
- Easily learn about the basic load test features such as running tests from different locations around the world, viewing and analyzing results in the browser, analyzing the test errors, and more.
At the other end of the spectrum is using Visual Studio Enterprise to create and run load tests. While you can certainly create a URL-based load test using Visual Studio Enterprise, the real advantage is the ability to write tests that mimic several end-to-end user scenarios. These may include a distributed mix of tests, the ability to use data to drive your test, and even use of the rich extensible framework to create plugins necessary to suit complex testing requirements.
HTTP Archive testing also allows you to create load tests that mimic end-to-end user scenarios, but with fewer capabilties than the rich Visual Studio Enterprise load tests. However, by using HTTP Archive files you can represent user scenarios that:
- Support multiple URLs
- Send requests other than just a simple GET
- Simulate a complete user scenario
The example shown here uses the Google Chrome browser, but you can use the browser of your choice such as Edge, Internet Explorer, or Firefox. For example, this video shows how to create an HTTP Archive with different browsers and with Fiddler.
Create an HTTP Archive file
Follow these steps to create an HTTP Archive (.har) file using your browser.
Launch the browser and press F12 to open the developer tools.
Ensure that the browser traffic is being recorded. For example, if you are using Chrome, check that:
The recording button is "on" (the round button is red).
The Preserve log checkbox is set to ensure that the complete sequence of URLs for your scenario is captured. If you do not set this option, network activity recordings are discarded whenever you reload the current page or load a different page - which means that an end-to-end scenario may not be captured.
Exercise your user scenario. Enter the URL in the address bar and go through the sequence of actions a typical user would follow. For example, in a retail store site, the user would browse for a product, enter a product name in the search box, choose links of interest, view the product information, and (hopefully) place an order.
As you go through these steps, you will see that all the traffic between the browser and the server is shown in the Network tab of the developer tools.
After you have finished recording your user scenario, save the URLs as HTTP Archive (.har) file. In Chrome, do this by opening the shortcut menu for the URL list and choosing Save as HAR with content. Enter a name for the file and save it on your computer.
You can also create an HTTP Archive using tools other than a browser. For example, Fiddler is a popular tool for viewing and troubleshooting traffic. Use Fiddler to record traffic in the same way and export sessions as an HTTP Archive.
Create a load test using the HTTP Archive file
Follow these steps to create a load test in the Team Services web portal using an HTTP Archive (.har) file.
Sign in to your Visual Studio Team Services account (
Go to the Load Test hub.
If this is the first test you have created, you will see the "Get started with cloud-based load testing" page. In the HTTP archive section, choose Create test.
If you have previously created any tests, you will see a list of these. In this case, open the New menu and choose HTTP Archive based test.
In the Import HTTP Archive file dialog, select the .har file that you recorded in the earlier steps and choose OK.
The HTTP Archive file is uploaded and read, the URLs are extracted, and all the details (the HTTP method, headers, querystring parameters, form post parameters, and more) are displayed. You can add URLs and edit the existing URLs to provide a friendly name for each request in the center Add URL pane. This will help you easily identify each request.
The right-hand section of this page shows details of the selected request URL.
Some dynamic information such as ASP.NET viewstate, event validation, and more that varies from session to session, and must be retained in order for a sequence of requests to succeed. These values are automatically identified and extracted from a request and correlated in any subsequent requests that use them.
Open the Settings tab to view and change any load test settings.
Enter a name for your load test, then choose Save.
Choose the Run test link to execute your load test. A progress bar shows the current status of the test run.
As the load test runs, you see a rich set of metrics that indicate how your app is performing under load. When the test is complete, you can explore the results.
For more information about the results and reports, see URL-based load testing with Visual Studio Team Services.
As you run a load test, requests are sent to your application in the sequence you specified. Ideally, you want a clean run with all requests succeeding. However, requests may fail because of issues in your app or in your test. The load test results view offers two sections to help you identify these errors: Diagnostics and Logs.
The Diagnostics section provides insights into any test errors and important status messages from the load test service that occurred during the load test run. For failing requests, you can see the error type, the specific error subtype, the number of times the failure occurred, and more.
This page also lists the requests that were tested, and the test you executed.
The Logs section gives you access to logs from all of the load-generating agents. If requests in your test are failing, these logs will help you figure out what went wrong. The test logs are available in HTTP Archive (.har) format, the same format as you used to record the user scenario and create the test. You can download these logs and view them in a HAR viewer such as Fiddler, HAR Analyzer, or any other viewer that you prefer. You can then inspect the details of each request and its response in order to troubleshoot any failures in your test.
This screenshot shows how you can import the log into Fiddler.
Export the test to Visual Studio
Sometimes, one or more requests will fail every time they are executed. If you have eliminated the obvious causes such as correctness of the URL, the target URL not being reachable, or any application issues, requests may be failing because the application uses dynamic parameters (such as session ID, cookies, values set in hidden fields such as ASP.NET VIEWSTATE, and others) in these requests. When you create a test using an HTTP Archive, the following cases are handled automatically when the test is executed:
- Dynamic parameter values set in cookies.
- Dynamic parameter values set in hidden fields, such as ASP.NET VIEWSTATE and EVENTVALIDATION.
However, dynamic parameters may also appear elsewhere in requests such as query strings or form post collections. At present, the load test mechanism does not support these types of dynamic parameters. If you find that this is the cause of your test failures, you can export and run the test in Visual Studio.
This export mechanism downloads a Visual Studio load test project containing the required web performance test and load test for your application. See how to fix dynamic parameters using Visual Studio. Sean Lumley's blog post has a detailed example of how dynamic parameters can be identified by inspecting the test and test results.
Q: Can I simulate actions from different users and data-drive my test?
A: No, this capability is planned but is not available at present.
Q: Does the feature automatically identify and correlate all dynamic information from all requests?
A: No, this capability is currently supported only for the ASP.NET information such as VIEWSTATE, EVENTVALIDATION, and similar values. Your request may fail if it contains other dynamic information. In these cases, you should run the tests using Visual Studio.
Q: Can I test REST APIs using the functionality provided by the Team Services portal?
A: Yes, you can use the URL-based test to test REST APIs. Enter the request URL of your API and the details required to create your test.
Q: I want to see what's possible in Visual Studio after I export the test. Do I need to have Visual Studio Enterprise edition?
A: No, you can use the 90-day trial version of Visual Studio Enterprise edition. This allows you to run cloud-based load tests. See this blog post.
- Run URL-based load tests with Visual Studio Team Services
- Run Apache JMeter load tests with Visual Studio Team Services
- Performance test your app in the cloud
- Performance test your Azure web app under load
Help and support
Submit bugs through Connect, make suggestions on Uservoice, and send quick thoughts using the Send-a-Smile link in the Visual Studio, Team Services, or TFS title bar. We look forward to your feedback.