Troubleshooting an HTTP archive-based load test
Did you know that you can use the cloud-based load testing service in VSTS to create and run load tests using HTTP archive (.har) files? The feature preview is available now. To learn more, see this link.
This blog post covers how to troubleshoot any request failures that may be happening in your test.
As you run a load test, requests are sent to your application, in the specified sequence in your web-scenario. Ideally, you want a clean run, with all requests passing. However, requests may fail because of issues in your app or in your test. The load test results view offers two tabs to help you with identifying these errors: the ‘Diagnostics’ tab and the ‘Logs’ tab.
The ‘Diagnostics’ tab provides insights into any test errors and important status messages from the load test service that may have occurred during the load test run. For failing requests, you can see the Error, the specific error subtype, the # of times the failure occurred, etc.
The ‘Logs’ tab gives you access to logs from all 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 very same format that 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 like. You can then inspect the details of each request and it’s response to troubleshoot any failures in your test.
The following screenshot shows how you can import the log in Fiddler.
Exporting test to Visual Studio
Sometimes one or more requests will fail every single time they are executed. If you have eliminated the obvious possible causes (correctness of the URL, the target URL not being reachable or any application issues), requests may be failing because the application uses dynamic parameters in these requests, whose values are generated fresh every time the target is accessed. Information such as session ID, cookies, values set in hidden fields such as ASP.NET VIEWSTATE, etc. are such examples. When you create a test using an HTTP archive, the following cases are automatically handled 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.
Dynamic parameters may also appear elsewhere in requests such as query string or form post parameters. Extraction and handling of such cases is currently not supported. If you find that your test fails because of this reason, you can fix the test by exporting to Visual Studio.
This will download a Visual Studio load test project with the necessary web performance test and load test for your application. You can learn more about how to fix dynamic parameters using Visual Studio, on this page. Sean Lumley’s blog post has a detailed example of how dynamic parameters can be identified by inspecting the test and test results.
- I want to see what’s possible in Visual Studio after I export the test, but I don’t have Visual Studio Enterprise.
>> You can use Visual Studio Enterprise Trial for 90 days. Using the Enterprise trial, you can still run cloud-load tests. See this blog for details.