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

Understanding ACT Projects, Users, Tests, and Connections

Much of today focuses on using projects, users, tests, and connections in ACT.

A project may contain one or more tests. A project may be opened or created with the standalone tool or from the Visual Studio .NET IDE. They share a common file format and both have the file extension .act.

Note

Note that you can't have the same ACT project file open simultaneously with both the standalone tool and the Visual Studio .NET IDE.

Users are agents that are started and run tests. They generate the load and simulated Web site access. Normally (and always if you run only from the Visual Studio .NET IDE), users are generated as needed automatically by the program. If you use the standalone program, you can define your own users. This enables you to create accounts, assign names, passwords, and user rights, and also to manipulate and reuse cookies.

Connections are used to send requests and receive responses from the target Web server.

Tests are what you run. A test is a VBScript or JScript file that executes. Test is the main ACT object and is used to modify, control, and monitor a test.

If you start the ACT standalone tool, you'll see a number of sample projects, ranging from simple to complex, with some of them targeted at the Visual Studio .NET Web samples.

Creating a New ACT Project

To see the overall use of ACT within the framework of Visual Studio .NET, you'll create a new ASP .NET Web application, add an ACT project to the solution, and then add and run a test. Later today, you'll learn about the additional control you have in the standalone version of Application Center Test.

To start, create a new ASP.NET Web application and name it ActWebTest. On the default Webform1, add a Label server control. Set the Text property of the Label control to ACT Web Test. Figure 19.1 shows what your project should look like at this point.

So far, you've just added a single control to the default Webform. Keep in mind that as you add more controls and objects to a Web Form, you'll see different results in the tests.

The next step is to add an ACT project to your existing solution. To do this, right-click on the ActTestWeb project name in the Solution Explorer, and then select Add, New Project. The Add New Project dialog pops up. From the Project Types pane on the left side of the dialog, drill into the Other Projects node, and select Application Center Test Projects. As Figure 19.2 demonstrates, only one template is shown: ACT Project.

If you select the Act Project template and click the OK button, the new ACT Project will be added to your solution. Accept the defaults, but note where it's being saved so you can open it later outside the Visual Studio .NET environment. Now that you've added the ACT project to the solution, your Solution Explorer should resemble Figure 19.3.

The next step is to add a test to ACTProject1. To do this, right-click on the ActProject1 in the Solution Explorer and select Add, New Item. The Add New Item dialog now pops up, as Figure 19.4 demonstrates.

Three test templates are displayed: Browser Recorded Test (.vbs), Test (.js), and Test (.vbs). The last two create blank test script files that you can fill in using either JScript or VBScript.

From the Add New Item dialog box, choose Browser Recorded Test. The recording dialog box pops up as shown in Figure 19.5.

Press the Start button to begin recording. After pressing the Start button, a new Web browser session is opened to the address About:Blank, as Figure 19.6 shows.

Because the browser opens up to the About:Blank page, you must navigate to the URL of the test site. Type http://localhost/ActWebTest/WebForm1.aspx in the Address box. Figure 19.7 is the page you created earlier.

Now that you've browsed to the page, you can stop the recording process. To stop the recording, go back to the Visual Studio .NET IDE and click the Stop button. Then click the OK button as Figure 19.8 demonstrates.

Visual Studio .NET now displays the VBScript that was generated from the recording process. Figure 19.9 shows what you should be looking at now. You go through the script code in detail later today, but for a single browse to a page, it consists of a Main sub routine that calls the SendRequest1 subroutine. If you browse to multiple pages, click a submit button or other controls, or if the pages contain images and other objects that must be downloaded from the Web site, more subroutines are generated. When I first tested this, I was also downloading email from my MSN email account, and all the activity for that was recorded also. So, the actual script that's generated gives you all the activity on the machine when the test is run, not just the information about browsing to the test application you created.

Now that the test has been generated, you need to actually run it. First, you must set some of the properties for the test. Right-click on the test (the default name in this case is ACT-VBSTest1.vbs) and display the properties as in Figure 19.10.

There are two basic methods of controlling how long a test runs: either by specifying the RunTime property (in this case, 300 seconds by default) or by the number of iterations.

If testing is based on time, a warm-up period can be set. The warm-up time could eliminate caching and other variables to allow a steady state to be achieved before performance measurements are started.

To allow quicker testing and demonstration, set Iterations to 200, which clears the 300 seconds.

The other important property is Connections. By default, this is set to 1. The Connections property controls how many simultaneous browser connections are made. The 1 corresponds to what you did when recording the browser sessiononly one browser was open.

Depending on the power of your client, you can set this to a higher value. With multiple connections, the number of requests per second will be higher until your test computer runs out of processor, memory, or network capacity.

To run the test, right-click on the ACT-VBSTest1.vbs test in the Solution Explorer and select Start Test, as shown in Figure 19.11.

You can monitor the progress of the testing in the Output window. The output for my test is displayed in an expanded Output window in Figure 19.12.

The results include the total runtime, one second in this example. There were 200 iterations and, because there was only one request per iteration, 200 requests as well. The Avg. Requests/sec is 200.

Avg Time to First Byte (msec) is the time between the request and when data starts arriving back from the Web server, averaged over all the requests. This includes any compilations the Web server needed to execute the page and communication delays; for instance, a satellite link might have a high data rate but long initial delay.

Avg Time to Last Byte (msec) is the time to the final response from the Web server. The difference between these is the time the Web server took to actually execute the entire page and actual transmission time (data rate related) on the intervening network. All HTTP, DNS, and Socket errors are also displayed.

You can view the final results by right-clicking on the test in the Solution Explorer and choosing View Results. The final results are shown as a row of data in the View Results window. If you run more than once, the multiple runs are displayed and saved until you delete them. Figure 19.13 shows the Application Test Center Results window with two tests listed.

Now that you've seen how to create ACT tests in the Visual Studio .NET IDE, you can close Visual Studio .NET. Next, you'll learn how to use the standalone ACT application to run tests.