Posted September 07, 2005
TestComplete 4 Sneak Peek - Load Testing - Part 2
As noted in Part 1 of the TestComplete 4 Sneak Peek - Load Testing edition: The upcoming TestComplete 4 includes major enhancements to load testing. In Part 2, I am discussing the new LoadTesting Project Item Editor, Stations Editor, Tasks Editor and Load Test Editor.
LoadTesting Project Item Editor
The LoadTesting Project Item Editor allows you to modify settings of the load testing project. The editor holds the Authentication information table that contains information needed to simulate traffic to Web servers supporting the NTLM authentication.
The information used for authentication is:
Specifies the domain or workgroup to which the tested server belongs.
The name of the computer, on which the tested Web server is installed.
User account used to connect to the tested Web server.
The password used to connect to the tested Web server.
Using the LoadTesting Project Item properties, you can easily authenticate request made to the tested Web server without having to write one line of script code.
The Stations Editor allows you to modify the station's properties via a new user interface.
Each station has two properties:
- Host - Either the computer name or IP address of the workstation.
- Port - Port number that TestComplete 4 will use to connect to the remote workstation.
Using the Station's properties, you can easily configure the stations used for load testing without writing one line of script code.
HTTP traffic recorded by TestComplete 4 is organized into tasks. Using the Tasks Editor you can view and modify HTTP traffic recorded by TestComplete. The Tasks Editor contains the Target server edit box, a tree of recorded connections and requests, Request tab, and a Response tab.
The Target server edit box specifies the host, the traffic to which TestComplete records. TestComplete will send the requests to this host when playing back the recorded task. If the tested Web server has been moved to another address, you can simply specify the new name (or IP address) in the Target Server value rather than re-record the task. Any of the following formats can be used:
- hostname:port (for instance, www.ourhost.com:80)
- IP_address:port (for instance, 192.168.1.10:8080)
A tree of recorded connections and requests ID display to the left of the editor. The requests ID is used to identify requests during the script run. When the request ID is clicked it displays the request properties and the content of the response to this request through the Request and Response tabbed pages.
The Request tab page contains properties of the request that is currently selected in the tree on the left of the Task editor. The fields of the request header are shown in the table and can be modified. For instance, you can change the browser in the User-Agent field to simulate that the request was sent from another Internet browser, or you can change the variables passed to the Web server via the HTTP address. The request method (GET or POST) and the protocol version in use are specified in the edit box above the properties grid.
The Response tab page displays the properties and the contents of the responses received from the tested Web server on the request that is currently selected in the tree. The fields of the response header are shown in the table. The Content-Length field specifies the size of the response and its value depends on the response content. The response content is displayed below the properties grid. If the response returns an image, TestComplete will show this image. If the response returns a Web page, TestComplete shows this page and the pages HTML source. With TestComplete you can also view and modify the content of SOAP responses. The type of response data is specified by the Content-Type field of the request header. When you change the field in the Task editor, TestComplete automatically shows the appropriate editor for the selected content type. The response result (for example, 302 Found) and the protocol version (for instance, HTTP/1.0) are shown in the edit box above the properties grid.
Of course, all of the Tasks Editor items can be implemented or edited through scripts, but with these new GUI enhancements, it is much easier to change them directly through the Tasks Editor. The screenshot below displays the Task Editor. Notice the request ID to the left and the Response tab page on the right. Within the Response tab page are HTML and Text tabs. As you can probably tell, the HTML tab display the response as a web page. The Text tab displays the actual source of the response. Tasks Editor
Load Test Editor
The Load Test Editor lets you view and modify properties of a load test that is created in TestComplete 4. Also, you can now create virtual users through the Load Test Editor, without having to write one line of script code. The Virtual Users section holds information on virtual users that will be simulated during the test execution. Each row in the Virtual Users table corresponds to one or several virtual users. User properties are:
The number of virtual users to which the settings specified in other columns will be applied to. Name
TestComplete posts results of virtual user simulation to the test log. The string specified in the Name column lets you identify testing results of a user in the log. If a row holds several users, TestComplete will add a number to the Name string when posting results to the log. For instance, if the Name column of some row holds MyUser and this row specifies settings for 10 virtual users, the log will hold strings like MyUser (0), MyUser (1), MyUser (2), etc. Workstation
The workstation on which the user(s) will be simulated. You can select one of the workstations added to the Stations collection of the LoadTesting project item. Browser
Specifies the Web browser, on which virtual user(s) will work on. You can select one of the supported browser from the dropdown list. TestComplete will automatically modify the User-Agent field in the header of all requests sent by this virtual user to the tested Web server, so that this field will indicate that the user employs the selected Web browser for simulating recorded requests. Start Delay
By default, the simulation of all the virtual users that belong to the same test are started when the load test execution is started. This column specifies the time delay (in milliseconds) between the test start and the start of virtual user simulation. This can be used to emulate the growing load on the tested Web server.
Creating virtual users is as easy as configuring the above properties. Below, is a screenshot of the Load Test Editor. As you can see, three virtual users have been configured to use Internet Explorer, Netscape 6.0 and Firefox 1.1 through the Master Workstation. This is the last configurable item needed for creating a load test with these new editors. Once you have created a load test, you can simply execute it as a test item or write script code that will execute the test. The whole idea behind the above Load Testing enhancements is to make it easier and more user friendly for non-programmers or programmers alike. Load Test Editor