Customizing Web Performance Test Recordings Using Web Performance Test Editor
Web performance tests can be customized and configured to meet most of your Web application testing needs. For example, you can customize a Web performance test. For information about how to create a Web performance test recording, see Creating Web Performance Tests Using the Web Performance Test Recorder.
Tasks
Tasks |
Associated Topics |
|---|---|
Edit an existing Web performance test recording: After you have created a Web performance test, you can edit it and add validation rules, database connections, and other properties. You can set properties within Web performance tests to control the way the test runs and verify aspects of the site that you are testing. For example, you can set the StopOnError property so an error on an HTTP request will cause the test to fail or you can add a reporting name for a Web request. A reporting name makes it easier to identify in the Web Performance Test Results Viewer. |
|
Add more Web requests to your Web performance test: You can add more Web requests to an existing Web performance test by running the Web Performance Test Recorder from the Web Performance Test Editor and then modifying the new request to meet your Web application testing needs. |
|
Convert a recorded Web performance test into a coded Web performance test: After you have created a Web performance test and configured it, you can convert it into a coded Web performance test. A coded Web performance test is a .NET class that generates a sequence of WebTestRequests. It can be programmed using either Visual C# or Visual Basic. Note A coded Web performance test can be created manually, but it is suggested practice to convert a recorded Web performance test to a coded Web performance test. |
|
Add comments to your Web performance tests: You can add comments to your Web performance test to make notes about what logical action is occurring at each point in the Web performance test. For example, when you modify a Web performance test in the Web Performance Test Editor, comments can help identify the purpose of each request. Additionally, comments are valuable for making notes about validation and extraction rules that should be added to specific requests. |
|
Add reporting names to clarify identification of Web requests: You can add reporting names to Web requests to make it easier to identify Web requests in reports and while you are testing. The reporting name will be displayed in place of the URL. |
|
Customize a Web performance test with artificial user think times: Think time is the time spent by a user perusing a Web page, including viewing the page and determining the next action. You can customize think times by configuring how many seconds you want your Web performance test to spend on specific Web pages. |
|
Configure the permitted response time for a Web page in a Web performance test: An important aspect of Web applications is the time it takes for each Web page to load. This is known as response time. When you create a Web performance test, you can set a response time goal for each Web page request in your Web performance test. |
|
Add a data source to a Web performance test: You can add a data source to a Web performance test so that you can bind HTTP requests to it. The data source can be from a database, an XML file, or a comma separated value file (CSV). |
|
Add validation and extraction rules to Web performance tests: You can add validation rules to your Web performance test to help verify that a Web application is working correctly by validating the existence of text, tags, or attributes on the page returned by a Web request. Validation rules can also verify the time that it takes a request to finish, and the existence of form fields and their values. You can also add extraction rules to help verify that a Web application is working correctly by extracting data from the responses to Web requests. Extraction rules store results in the test context as name value pairs. Extraction rules can extract form fields, text, attributes, headers, regular expressions, and hidden fields |
|
Customize a Web performance test using loops, branching, and transactions: You can add flexibility to your Web performance tests by adding loops, branching conditions, and transactions. |
|
Using transactions in a Web performance test: Within a Web performance test, you can encapsulate a set of actions in a transaction. You can think of a typical transaction as starting a timer, requesting a page, requesting another page, and then ending the timer. This series of actions, from start to end, constitutes a transaction. .gif "Note") Note
The transaction response times are displayed in the transaction table of the Load Test Analyzer when a Web performance test that contains transactions is used in a load test.
|
|
Add calls from your Web performance test to another Web performance test: You can insert a call to another Web performance test into an existing Web performance test. |
|
Configure a Web site to use specific user credentials: You can set the credentials in your Web performance tests for a Web site that uses basic authentication or Integrated Windows authentication. Web sites that contain personal information frequently require user authentication before they display any information through the browser. |
|
Customize the Web performance tests Web server URL using parameterization: You can parameterize the URL for your Web server to make it easy to change the Web server that your tests target. |
|
Promote dynamic parameters in a Web performance test: Your Web application being tested might dynamically generate data, such as a session ID. A Web performance test can use such a generated parameter value by capturing it from the HTTP response, using an extraction rule, and then binding it to a subsequent HTTP request. This capture and binding sequence is the promotion of dynamic parameters to Web test parameters. Dynamic parameter promotion can prevent many cases of playback failure. |
|
Quickly find and replace text in requests in a Web performance test: You can quickly find and replace text in the Web requests of a Web performance test by using the Web Performance Test Editor. |
|
Use context parameters in a Web performance test: You can use context parameters in your Web test to parameterize a string value. For example, you might want to parameterize the Web site URL so that you can quickly change where the test is run on all the Web requests. |
|
Add profiling data to your Web application: The Profiling Tools that are included in Visual Studio Premium let developers measure, evaluate, and target performance-related issues in their code. For more information, see Analyzing Application Performance by Using Profiling Tools. With Visual Studio Ultimate you can run performance sessions on your Web application either using the Web Performance Test Editor or the Load Test Editor. To obtain the data that you need to analyze, you must first create a performance session and then run the session. The Performance Wizard lets you do both. |
|
Set request details for requests in a Web performance test: You can specify Web request details to apply to your Web performance test in the Web Performance Test Editor. The Web requests details include reporting names, think times and response time goals. |
|
Extract some Web requests to use in another Web performance test: You can extract some of the Web requests in an existing Web performance test and create a new one based on it. The original Web performance test will then call the new Web performance test to use the extracted requests. This can be useful if you need to include the requests in more than one Web performance test. |
|
Use a proxy server with your Web performance test: You can configure your Web performance test to use a proxy server if the site you are testing is affected by a firewall. |