Web Testing


Testing a web user interface does not have to be a manual process. In fact, if it is, testers cannot be expected to test every permutation of a data-driven user interface. Instead, they often test a common path through the system and rely on (and hope) the other combinations produce similar results.

Visual Studio 2005 automates web testing. It provides the web test tools for this purpose. These tools enable you to record navigation paths through your site, manage these requests, bind these requests to data in a database, and then run the tests over and again. You can also review and save the test results to TFS.

Recording a Web Test

You create a new web test by adding a web test item template to a test project. When you do this, Visual Studio automatically launches the web test recording tool in the browser. The intent of this tool is to allow a tester to record a set of web requests in the system. This recording will serve as the basis for defining the web test.

As an example, suppose you want to define a web test for a Customer Manager CRM application. Assume the current release being tested contains web forms that allow a user to find customers, edit their profiles, and view their orders. The tester would then navigate to each of these features in turn using the recorder. Figure 22.15 shows an example.

Figure 22.15. The Web Test Recorder.


Notice the recording being captured on the left. The Web Test Recorder provides a toolbar for pausing your recording, stopping it, deleting a request from the list, and adding comments (or notes) in between requests. Finally, notice that the details of requests containing QueryStrings and form posts are captured. We will cover more on this in a moment.

Visual Studio writes the requests to the web test upon stopping the recording. The complete set of requests is captured and contained within the test. Figure 22.16 shows the details of the sample web test inside the web test viewer.

Figure 22.16. The recorded web test.


Notice the web test toolbar. The buttons on this toolbar allow you to (from left to right) rerun the test, bind the test to a data source, set user credentials for test execution, do more recording, set a web test plug-in, set a request plug-in, generate code from the web test, and parameterize web servers. We will cover most of these items in the following sections.

Managing Web Test Requests

The requests in the web test can be manipulated. You can move them up and down in the list (they are run in order), delete them, and add new requests between them. When you define an effective web test, you should be sure to cover all requests and possible request conditions. However, you often end up with a lot of redundancy in your recorded requests. Therefore, it makes sense to go through each request and pare down your test to the essentials.

In the example, you want the following list of requests:

  • Request for the home page (Default.aspx)

  • Request to FindCustomers.aspx

  • A form post on FindCustomers.aspx that searches for customers by clicking the Find button

  • Request to EditCustomer.aspx that passes the customer ID on the QueryString

  • A form post on EditCustomer.aspx that saves the details of the customer using the Save button

  • Request to FindOrder.aspx that passes the customer name on the QueryString (from the FindCustomer page)

  • A form post on FindOrder.aspx that searches for a customer's order based on the user's entering a portion of the customer name and clicking the Find button

You can see that this list covers all the bases for the pages you are testing. Figure 22.17 shows the list cleaned up inside the IDE.

Figure 22.17. Cleaned-up web tests.


Running the Web Test and Viewing Results

You can run your web test from the web test toolbar. When you do so, Visual Studio executes each request and captures all statistics relative to the same. This includes the outcome of the request, its size, response time, and actual details of what happened. Figure 22.18 shows the results of the web test created earlier.

Figure 22.18. Web test results.


Notice that you can navigate each request and view its details. These details can be stored for later review. This provides proof of what exactly happened when the test ran. You have access to the actual HTML that was returned, the request details, the response details, the context of the request, and other details such as exceptions and extraction rules (we will look at these rules in a moment).

Seeding a Web Test with Data

The real power of the automated web test is the capability to seed it with data from a database. In this way, you can test many more possible permutations of your web application. This is simply not practical when you're doing manual testing.

Using the example, you have a few options for database seeding. First, say you want to be able to call the edit profile screen for each user in the database. You then might also want to save those profiles back to the database. As another option you might also seed the find pages with data elements and filter the lists accordingly. Running this small number of tests with a lot of data rows should give the web interface a good workout.

Defining the Web Test Data Source

The first step is to define a source for the data that will seed your web test. You can do this from the web test toolbar (database icon). Selecting this toolbar button brings up the Connection Properties dialog box, which is the standard database connection dialog box.

After you define the connection information, Visual Studio asks which tables you want to use for the web test. You select them in the Choose Tables dialog box. For the example, use the customer and order tables.

Figure 22.19 shows the data source added to the test. You can add multiple data sources to a given test. These data sources are specific to each test. That is, they do not have an effect on any other portion of your code. Finally, notice that in the figure the customer table is selected and its properties are shown. Here, you can set how data is accessed or loaded for each web test. You can have that data pulled in one of the following ways:

  • Random Access rows in the table randomly.

  • Sequential Access each row in the table in order. After the entire table has been executed, the process will start over (loop) for the duration of a load test.

  • Unique The same as sequential without the looping.

Figure 22.19. Web test data source.


As you can see, this setting is more important in a load test where the test is executed over a duration of time. In a web test, you will indicate how many (or all) rows you want to execute as part of the test.

Binding Tests to Data

The next step is to bind the tests to the data. Typically, binding is done to the QueryString parameters and the form post values. To bind the parameters and values, you select the QueryString parameter from beneath the given request in the web test. You then view the properties of the parameter. Here, you can set the value property to a field in the database. Figure 22.20 shows an example.

Figure 22.20. Binding the test to the data.


Before you run the test, you must tell the tool to run your web test once per row in the database. You can also determine a fixed count for your web test. You modify this setting through the .testrunconfig file. Figure 22.21 shows an example. Here, you select the option button One Run Per Data Source Row.

Figure 22.21. Configuring the web test to run once per data row.


Finally, you run the web tests. The tool will take care of pulling the data from the table and executing each test once per row in the database. Each execution is considered a run. All runs are saved and presented in a list for your review.

Figure 22.22 shows the results of the sample runs. Notice that run 2 executed fine but run 3 had errors. This is what you hope to find with a web test: errors that only present themselves based on certain data conditions. In this case the value stored in the state field in the database cannot be found in the drop-down list control on the user interface. You can take this test and generate the appropriate work item bug to get the problem fixed.

Figure 22.22. Web test results.


Binding to Form Posts

Thus far, we've looked at binding a simple request to a data source. Next, we want to examine how to bind a form post to the database. The good news is that the process works the same way. The form post parameters are listed in the web test request. Each parameter can then be bound to a database field from the Properties window.

The web test example has a few form posts: each time the user clicks the Find button to search for a customer, again when he or she searches for an order, and then when the user clicks Save to write customer details to the database. The first two posts you simply bind to the name field on the customer table. This will ensure each customer name is searched for in the list. Searching for all customer names in the database will provide a nice test that is easy to configure. However, if you prefer to seed this test with your own values (not from the database), you can take a couple of steps: Create an object or XML data source with your own values or simply copy the test and manually enter a series of search values (one for each copy).

To bind the save parameters, you need to ensure the QueryString parameter is bound to the customer.id field and then bind each form element to a field on the customer table. In this case, you have text boxes, a drop-down, and some check boxes. Figure 22.23 shows the results of the binding.

Figure 22.23. A data-bound web test.


The final step is to run the tests and view the results. Figure 22.24 shows the results of the web test created earlier. Notice that we have navigated to the EditCustomer.aspx test. Clicking the Context tab in the results window will show you the context in which the test was run. In this case, you can see which values were used to seed the test (and thereby posted to the form and saved).

Figure 22.24. Data-bound web test results.


Tip

Visual Studio provides complete control over the web tests for those testers who can write code. On the web test toolbar, there is an option to generate code. Selecting this option will create a class file that represents the web test. The web test uses the Microsoft.VisualStudio.TestTools.WebTesting namespace and can be coded manually or edited from this generated code. Listing 22.3 shows a portion of the generated code. This test is for the FindOrder.aspx page. The QueryString and the post parameters are bound to the database.


Listing 22.3. Web Test Autogenerated Code

WebTestRequest request7 = new   WebTestRequest("http://localhost:2465/Debugging/FindOrder.aspx"); request7.Method = "POST"; request7.QueryStringParameters.Add("cust",   this.Context["UnleashedDb1.customer.name"].ToString(), false, false); FormPostHttpBody request7Body = new FormPostHttpBody(); request7Body.FormPostParameters.Add("__VIEWSTATE",   this.Context["$HIDDEN1.__VIEWSTATE"].ToString()); request7Body.FormPostParameters.Add("ctl00$ContentPlaceHolder1$TextBoxCustomer",   this.Context["UnleashedDb1.customer.name"].ToString()); request7Body.FormPostParameters.Add("ctl00$ContentPlaceHolder1$Button1", "Find Order"); request7.Body = request7Body; yield return request7;

Extracting Values from Web Tests

You can further refine your web tests by creating your own extraction rules. These rules allow you to extract key information from the request and save it as part of the test results. As an example, you might want to extract the values inside an HTML attribute such as an anchor tag's URL or button's name. Other examples might include extracting text from the page, form field values, values of hidden fields, and so on. Figure 22.25 shows an example.

Figure 22.25. Defining the extraction rule.


You access this dialog box by right-clicking a web test request and choosing Add Extraction Rule. From here, you can define various rule types. For this example, say you are creating a rule to extract the value from a form field, TextBoxName. Notice that this rule's Context Parameter Name is CustomerName. This name will allow you to identify the parameter in your test results. Figure 22.26 shows these results. On the Context tab, you can find the extracted values. Also, on the Details tab (not shown), you can review the results of your extraction tests.

Figure 22.26. Viewing the extracted value.


Linking Pages with Extracted Values

In addition to viewing these extracted values, you can also use this information to link requests together. You can pull a value from one page and then pass it to another. For example, when defining the extraction rule, you gave the parameter a name, CustomerName. This name becomes a variable name that you can use inside the Properties window when binding test items to values. Figure 22.27 shows an example of binding the CustomerName exTRacted value to the FindOrder.aspx search request.

Figure 22.27. Binding to the extraction.


Requesting Validation Rules

You can also add validation rules to each of the requests in your web test. Validation rules allow you to check a page (or request) for certain expected values. These additional tests are run against the request. Validation rules include the capability to check for expected form field values, verify HTML tags, check expected request times, and more.

You add a validation rule by right-clicking a web test request and choosing Add Validation Rule. Selecting this option brings up the Add Validation Rule dialog box. Here, you can define the rule type and its parameters.

As an example, on the FindCustomer.aspx page, a set of instructions is loaded on the master page. You can create a validation rule to check for these instructions. To do so, you create a FindText validation rule and enter the appropriate parameters. Figure 22.28 shows an example.

Figure 22.28. Defining a validation rule.


Note

Validation rules can sometimes have an effect on performance. Therefore, you can use the Level property to indicate when a given validation rule should run. Typically, you set your validation rules to High and then on a load test you indicate that you want to run tests on a Low level to get a more accurate view of performance.


The results of the validation rule are shown on the Details tab for the request. Figure 22.29 shows the results of the sample validation rule.

Figure 22.29. Validation rule results.





Microsoft Visual Studio 2005 Unleashed
Microsoft Visual Studio 2005 Unleashed
ISBN: 0672328194
EAN: 2147483647
Year: 2006
Pages: 195

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net