A.: This depends on your version of TestComplete:

• If you use TestComplete version 6.40 or later, you may need to specify the proxy settings that you use in your LAN (see below). No additional settings are needed.
   
• If you use TestComplete version 6.30 or earlier (including TestComplete ver. 5.x and 4.x) then you need to specify TestComplete as a proxy server. When you are recording load testing scripts with these versions of TestComplete, the latter intercepts low-level HTTP requests sent by the browser and then sends them itself. To intercept these requests, it requires that the browser does not send them through its usual port (8080 by default), they should be sent through another port specified in TestComplete’s options for the HTTP Load Testing plug-in. This port is 9999 by default, and the port specified in your browser’s options should correspond to it. So, please make sure that the browser settings specify the computer, on which TestComplete is installed, as a proxy server and the proxy port number corresponds to the Proxy port field of the HTTP Load Testing Options dialog. To call the dialog, select Tools | Options from TestComplete’s main menu and then choose Engines | HTTP Load Testing from the tree on the left of the ensuing Options dialog.
  Note that for some browsers (for instance, for Internet Explorer) TestComplete can set the needed port automatically.

If you want to test an external web site and you use a proxy server in your LAN to access the Internet, you should check the Use HTTP Proxy check box in the “Firewall settings” group of the HTTP Load Testing Options dialog. In addition, you should specify the proxy network name or an IP address in the HTTP Proxy Host field and set the correct port number in the HTTP Proxy Port field. Please see the “HTTP Load Testing Options” help topic for details.

If you want to test an internal web site (within your LAN) two cases are possible:

• If you are not using a local proxy server (typical for local networks), please disable the Firewall Settings | Use HTTP proxy setting of TestComplete.
• If you use proxy, set the HTTP load testing options as it was described for the external sites. In addition check proxy settings for local networks:
  • For the Internet Explorer browser make sure that the Bypass proxy server for local addresses check box of the Tools | Internet Options | Connections | LAN Settings dialog window is disabled.
  • For the FireFox browser check the No proxy for edit box of the Tools | Options | Connection Settings dialog. If the site to be tested is mentioned there, remove it from this box.
  • For Opera and Netscape Navigator browsers no changes are required.

A.: To perform load testing, TestComplete records the HTTP traffic sent to the tested web server. TestComplete records requests sent to any web server, regardless of which Internet browser you are using (Internet Explorer, Netscape Navigator, Mozilla or Opera), web server type (Internet Information Services, Apache, etc.) and platform (Windows, Linux, etc.). It does not matter which browser you use to record the traffic.

With TestComplete you can record the traffic using one browser and play it back by emulating another browser. Currently, TestComplete can emulate the following browsers:

• Internet Explorer 5, 6 and 7
• Netscape Navigator 6.0
• Opera 8.0
• Firefox 1.1-1.5
• Pocket IE
• Smartphone

A.: The HTTP Load Testing feature is used to perform load testing on client-server applications that use the HTTP protocol for communication. TestComplete records HTTP requests sent by the client program and plays them back to simulate the activity of an actual user. The client program can be any application that uses the HTTP protocol, not just a web browser.

If your client-server application does not use the HTTP protocol, take a look at the Network Suite feature. By using it, you can run several copies of your client application on several workstations, where TestComplete (or TestExecute) are installed. One of the computers will be the Master host that will coordinate the work of all other computers using special synchronization features such as synchronization points, critical sections and others. The Master computer will run tests on all other machines, and the tests will simulate user actions in your client application. Thus, you will simulate several users working with your server.

A.: TestComplete version 6.40 has an updated load testing engine and does not require the proxy server functionality. So, if you have this version, you do not have to specify TestComplete as a proxy server.

As for earlier versions of TestComplete (TestComplete 6.30 and earlier, including TestComplete versions 5.x and 4.x) you should specify TestComplete as a proxy server in order for TestComplete to be able to record HTTP requests. For Web browsers, that support WinINET technology (Microsoft Internet Explorer, for example), TestComplete can modify the proxy settings automatically. The only pre-requisite is that those browsers should be running when you start load testing with TestComplete. For other browsers, you have to change the settings manually. Changing the proxy settings every time you need to record HTTP traffic or play back load testing scripts is a waste of time. To avoid this extra work, you can create (or record) a script routine that will allow you to set your Internet browser options to the desired state. You can then run this script before recording or playing back your load testing scripts. Do not forget to change back the proxy settings, when load testing is finished. The corresponding script routine may be helpful in this task.

A.: The HTTP Load Testing feature is included in the TestComplete Enterprise edition and TestExecute (TestExecute is included in the Enterprise edition). The basic license includes 5 virtual users. You can upgrade to 50, 250, or unlimited virtual users by ordering TestComplete load testing add-ons or TestExecute load testing add-ons.

A.: It depends on the server you are testing. The level of suitable performance may differ from one server to another. You are the one who determines whether the current performance is acceptable or not based on the specifics of the tested server. You can base your judgement, for instance, on the Avg Process Time or Performance column of the Load Testing Analysis page (see TestComplete - Load, Stress and Scalability Testing Support).

You can also perform testing with a different number of virtual users and see whether the difference in performance is suitable.

A.: To determine whether a request was simulated successfully, TestComplete checks whether the tested web server responded to the request and whether the status code returned as part of the server’s response coincides with the status code recorded for this response. If the returned status code differs from the recorded code, TestComplete reports a warning. If the server did not respond for some reason (for instance, the connection was broken or the server hung), TestComplete reports an error.

As a rule, the cause of the difference is that the recorded requests are conditional and they contain the If-Modified-Since and/or the If-None-Match fields. If the status of the requested resource differs from its state when you are recording a task and when you are playing it back, the server response will be different resulting in the Warning state of the request in the load testing results.

To work around the problem, try clearing the cache of the web browser before recording a task. Requests should not be conditional in this case.

A.: To get the actual server response, you need to handle the OnLoadTestingResponse event and work with the Request parameter of the handler routine. Data that is returned by the LoadTesting.HTTPTask(…).Connection(…).Request(…).ResponseBody.Contents property corresponds to the response contents that were recorded during the load testing task recording and that are displayed in the Load Testing Task editor.

For complete information on checking the server response, see the “Checking Server Response” topic in TestComplete’s help.

A.: To perform load, stress and scalability testing of web servers, you record a load testing task, which then can be played back with one or more virtual users. Typically, the same task is simulated with several virtual users in order to simulate massive load on the server. However, you may want to parameterize the task for some virtual users, so that the general actions they “perform” are common in general, but differ in detail. For instance, if you test an order form and a simulated request includes the number of ordered items, you may want to modify this request so that different virtual users “order” a different number of items.

To parameterize a task:

1. Create a separate copy of the task for each user --

   [VBScript]
   Set User1.Task = LoadTesting.HTTPTask("MyTask")
   Set User2.Task = LoadTesting.HTTPTask("MyTask")
   

   -- instead of assigning the same copy to each user:

   [VBScript]
   Set Task = LoadTesting.HTTPTask("MyTask")
   Set User1.Task = Task
   Set User2.Task = Task

2. Change requests’ data in a desired way. You can do this before running your test (if all data can be obtained at this stage) or during the test execution by handling the corresponding events (if the data can be obtained only during the task execution).

To modify the request data before running the test:

• Use the Task.Connection(…).Request(…) property to obtain the Request object corresponding to the desired request.
• Use the BodyVariables, URLVariables or Variables property of the Request object to work with the request’s variables.

  Use the RequestHeader and RequestBody properties to work with the request’s header and body. A couple of other similar properties - ResponseHeader and ResponseBody - provide a scripting interface to the response header and body.

  One more property, ContentDisposition, provides scripting access to the ContentDisposition structure of the request.

If you need to modify requests during the test run, you should --

1. Create the OnLoadTestingRequest event handler. This event is generated when a request is sent to the tested web server. The Request parameter of the event handler provides scripting access to the request being sent.
2. Use the above-mentioned properties of the Request object (BodyVariables, URLVariables, RequestBody and others) to modify the request data.

Note that if you modify requests with the event handler, the event handler’s execution time will be included in the request simulation time.

For details on how to work with task contents, please see the “Checking Server Response” and “Modifying Recorded Traffic” topics in TestComplete’s help.

A.: Most likely, you are using a TestComplete version earlier than 6.40 and are trying to record test actions over a web page or page elements that are accessible through the HTTPS protocol. The versions of TestComplete earlier than 6.40 were unable to record the HTTPS traffic and TestComplete’s proxy server did not transmit HTTPS requests. So, to test HTTPS web sites, you have to record load-testing tasks via HTTP and then modify these tasks so that they run via HTTPS. For complete information on this, see “Testing HTTPS Connections” in TestComplete’s help. In TestComplete 6.40 this is no longer needed. This version of TestComplete records HTTPS traffic in the same manner in which it records HTTP traffic.

A.: The answer to this question depends on the version of TestComplete you have. TestComplete 6.40 and later is able to record HTTPS traffic in the same manner, as it records HTTP traffic. That is, you just start recording, open the tested pages in your Web browser and perform the desired actions.

Earlier versions of TestComplete (TestComplete 6.30 and earlier, including TestComplete 5.x and 4.x) were unable to record HTTPS traffic directly. To test an HTTPS web site, you had to switch the site to HTTP, record a task and then modify this task so that it is executed via HTTPS. For detailed information on this, see “Testing HTTPS Connections” in your TestComplete documentation.

A.: Yes. TestComplete can record and replay SOAP requests sent from the client application and the web service and capture responses, which allows you to perform load testing of web services. Load testing of web services is very similar to load testing web servers. You can record load testing tasks for the tested web service and play them back using one or more virtual users. You can also parameterize the tasks by modifying the request parameters and verify the contents of the corresponding responses:

• To modify the SOAP request data, create the OnLoadTestingRequest event handler. The Request parameter corresponds to the request that is being sent. To verify that the request is a SOAP request, check the Request.SOAPRequest.SOAPAction property value.

  To access the request contents, use the Request.SOAPRequest.DOMBody property. The SOAP data is stored in the XML format, so this property returns an object that implements the IXMLDOMDocument interface. You can work with the request contents by using the methods and properties provided by this interface. For the IXMLDOMDocument interface reference, please see MSDN:

  http://msdn2.microsoft.com/en-us/library/ms756987.aspx

• To verify the SOAP response, use the OnLoadTestingResponse event handler. You can work with the response contents by using the approach that was described above. The only difference is that to access the response data, you should use the Request.SOAPResponse.DOMBody property.

In TestComplete 6, load testing of web services includes a special program object called WebServiceInfo. It lets you manage the requests’ and responses’ data from scripts in an object-oriented manner, without having to parse it manually.

For complete information about load testing of web services, see the “Load Testing of Web Services” topic in TestComplete’s help.