Teach Yourself Visual Studio® .NET 2003 in 21 Days [Electronic resources] نسخه متنی

Using the ACT Standalone Application

To test the standalone application and the parameters that can be set in the Application Center Test environment, start with the standalone program, which can be found under the Visual Studio .NET Enterprise Features in the Visual Studio .NET folder on the Start menu.

When the ACT IDE is open, you're brought to the ACT Samples list that's installed when you installed Visual Studio .NET for the first time. Figure 19.14 shows the ACT standalone IDE when opened for the first time.

For this demonstration, you'll browse to the test project we created in Visual Studio .NET. Select File, Open Project and navigate to the location of the saved ActProject1 you created earlier. On my system, this project was saved to its default location under the ActWebTest solution in the Visual Studio Projects folder, which is at the path C:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\ACTWebTest\ACTProject1 as Figure 19.15 demonstrates.

When the project is open and you click on the ACT-VBSTest1, the VBScript is displayed. On top is an area in which you can make notes about the test and the procedures that you took for future reference.

Next, right-click the ACT-VBSTest1 project in the left pane and select Properties to view the properties for this ACT project. The Properties dialog box is shown in Figure 19.16.

The General tab is where you set the number of simultaneous browser connections allowed and whether the test should be based on time or iterations. This is similar information to the property page displayed in the Visual Studio .NET IDE. Notice that the properties you set in the Visual Studio .NET IDE, such as the iteration setting of 2, are kept with the project.

If you click the Users tab on the Properties dialog, as Figure 19.17 demonstrates, you're shown the options for the users of the ACT project.

ACT automatically generates 20 default users. You can create your own users and group them. In this screen, you can only specify previously created groups of users, not specific users.

The final tab is Counters. This enables you to add performance counters for any computer in your network. By default, there are no counters.

I've added three counters here: the processor time, the server bytes/second, and the available bytes of memory as Figure 19.18 demonstrates.

Depending on the environment you're working in, the client computer (which drives the test) and the target Web computer may be separate machines.

As you add load, you can use the results of these counters to see whether either the client or the server has reached a peak load.

Close the Properties windows. Now right-click the ACT-VBSTest1 test in the left pane and select Start Test.

Real-time results are displayed as shown in Figure 19.19. Note that HTTP, domain name server (DNS), and socket errors are displayed as well as the number of iterations and the requests per second (RPS). If you click the Show Details button, a graphical representation of the test is displayed in the real-time results dialog. I also ran this with five connections. The RPS went up to 80 and the test time was three seconds. Because the test was very short, the differences weren't as dramatic as you would see with more iterations and/or a heavier test load.

If you select Results from the left pane in the ACT IDE, you'll see a list of the different tests that have run, along with the Performance Counters used for each test. On my machine, I ran the test several times to test various output. You can see the extremely useful reports in Figure 19.20 if you select any of the tests listed in the Test Runs window.

In the Report window, you can select one of three report options: Overview, Graph, or Summary. Based on the type of information you're looking for from the test, each report gives you different data based on the test results.

Customizing the ACT Tests

As you saw earlier when adding a new ACT test in Visual Studio .NET, either JScript or VBScript can be used to create a test. Both allow access to the ACT object model. However, only VBScript is created by the browser-recording tool.

To better understand what the tests are doing, we'll go over some of the more important objects in the ACT object model. As with any other object model, you can programmatically interact with any facet of the ACT tests that you're running by simply modifying the script that's running the test. After reviewing the major objects, we take a closer look at the script generated by the browser-recording tool.

The ACT Object Model

A number of objects are contained in the ACT object model. The core of it all is the Test object, which defines each test, its script, and other parameters.

The other objects not contained in the Test object are used to set up an environment, control the tests, and report the results. This is referred to in the documentation as the Application Object Model.

Application Object Model Level

The Application object contains objects that enable you to manipulate the test, such as Project, Controller, Report, and User. Each object is defined further in the following bullet points:

• Project:
  With the Project object, you can create a new project or open an existing project and modify and save changes. It also allows access to the collections of Tests and UserGroups contained within the project.




• Controller:
  The Controller object allows starting and stopping of tests in projects. This object can be thought of as the client computer running the test.




• Report:
  The Report object contained in the Reports collection stores information collected during the running of a test. This includes information about the computer the test ran on (the client), any performance counter information, requests used, and response codes received. It also contains basic information such as the requests per second, start time, duration, and report name.




• User:
  The User object is the entity running the test or the person doing the browsing if the testing isn't automated. The User object has a name, password, and a collection of cookies. The User objects are contained in a UserGroup collection, which in turn is contained in the UserGroups collection at the application level.

Test Object Level

The Test object level is the interface to the requests and responses being made from the client application to the Web server. Each of the core Test objects is further defined in the following bullet points:

• Test:
  The Test object is the main piece of running a test. The Test object creates connections and requests, and controls tracing users and the test environment. The Test object is also used to start and stop tests.




• Connection:
  The Connection object is created with the test object and manages the connection to the target Web page. With the Connection, you can specify the server, port, and whether an SSL connection is in use.




• Request:
  The Request object allows creation of a Web request, in a way very similar to what a Web browser does. The path, headers, verb (get and post, for example), encoding, and body are important properties. When the request is sent by a test, it results in a response that can be analyzed.




• Response:
  The Response object is returned by the Web server being tested. In addition to the headers and body returned, a number of other useful properties are returned such as result code, time to first byte, and time to last byte.




• Header:
  A Header is a name/value pair used for both requests and responses. Multiple headers may be included to store information about the HTTP request or response.




• User:
  User objects are used to log in to specific Web pages or services. They allow cookies, usernames, and passwords to be used when sending HTTP requests.