Features Added to LoadComplete 4.0

Enhanced Data Correlation Support

Improved Scenario Format and Editor

Overall Improvements

Known Issues

Discontinued Support

• New predefined correlation rules. Version 4 includes predefined data correlation rules for popular Web frameworks, sites and technologies: .NET, JSF, Java, ADF, E-Business, Siebel, ICEFaces, and many others. This ensures that request parameters in your user scenarios will be correlated correctly and you will not need to fine-tune your scenarios after recording. If needed, you can modify the predefined rules, or use them as a base for your own rules.

• User-defined correlation rules. In LoadComplete 4, you can easily create correlation rules specific to your tested Web application. You do this in the Tools > Options > Recording > Data Correlation dialog. You can create a rule from scratch, or copy settings from some other rule to start from. To learn how to do it, see Creating Custom Data Correlation Rules Manually.

• Easier creation of correlation rules. After you finished recording a scenario, LoadComplete now shows a wizard that automatically detects matching values in the recorded traffic and forms appropriate regular expressions, which you can approve or decline.

• Correlating at design time. In earlier versions, LoadComplete created correlation rules automatically only after scenario recording. In version 4, you can run the correlation procedure at any time by clicking the new Correlate Requests and Responses toolbar button in the scenario editor:

  

  Click the image to enlarge it.

• Automatic correlation in Rich Internet Applications (RIA). In earlier versions, you had to correlate dynamic parameters in Rich Internet Application scenarios manually. Now you can configure LoadComplete to correlate dynamic parameters in RIA scenarios automatically.

Version 4 introduces a new format of user scenarios:

• New operations. In addition to pages, requests, connections and WebSocket messages, user scenarios can now include specific operations for –

  • Condition request execution (If... Then... Else),

  • Creating loops (Loop, While, Break),

  • Calling other scenarios (Call Scenario),

  • Pausing and stopping scenario execution (Delay and Stop),

  • And more.

  

  Click the image to enlarge it.

  You can easily add new and arrange operations in your user scenario. All these make it possible to create more powerful and flexible tests as compared to recorded request sequences that you had in earlier product versions. For example, you can use a data selector to extract some value from a response, check this value with the If operation and stop or continue the simulation depending on the result of the check.

  For complete information on available operations and their properties, see Operation Reference.

  LoadComplete automatically converts existing scenarios to the new format when you open a legacy test project. No manual corrections are needed.

• Improved scenario editor. Changes in the scenario format and concepts caused changes in the scenario editor:

  • The request tree has been “lightened”. It does not display think time and dependent requests anymore. So, it is easier to track the request flow and understand what happens in a scenario. The Think Time value is displayed in the operation editor on the right. As for dependent requests, you can find information on them in the Provides Data For and Uses Data From panels of the Request operation editor.

    

    Click the image to enlarge it.

  • The request tree has been renamed to Scenario Explorer as it displays other operations besides pages and requests.

  • The editor has a new panel – Operation Repository. It lists operations that you can add to your tests. To add an operation to the scenario, you simply drag the operation from this panel to the request tree.

  • Some header fields like Set-Cookie or request and response headers are expandable. This helps you easier separate values from each other.

  • The new Summary panel helps you easily see information on child operations and on erroneous settings in your scenario.

  • The request editor now uses only one panel – Request Body – for displaying contents of various request types. The same happened with response-related panels: one panel for displaying the contents of various response types. Earlier versions of the product used several panels: HTML, Text, Parameters, and so on.

  • To show the contents of WebSocket client and server messages, the editor now uses the new Message Contents panel.

• Usability improvements. Changes in the scenario format and editor caused changes in the concepts that were used in earlier versions of the product:

  • Rendezvous points have been changed. Earlier, to set a rendezvous point, you selected the “Rendezvous point” check box for some scenario (it marked this request as a synchronization point for all the virtual users running the same scenario). Now, you set these points by adding the Rendezvous Point operation to your scenario. This helps you easily see where the rendezvous point resides in the scenario:

    In version 4.0

    In earlier versions

  • The “Think time” setting is available for any operation type now (request, connection, WebSocket messages, loops, condition check, and so on).

  • Earlier versions used the complex scenarios. A complex scenario was a special scenario type that could call other scenarios. Now, you call a scenario from another scenario by using the Call Scenario operation.

• Enhanced data modifiers and data selectors. Earlier versions used several similar features:

  • Data modifiers (they replaced data in simulated requests) and cookie replacers (they changed cookie values).

  • Data selectors (they extracted data from server responses) and cookie selectors (they extracted cookie values from server responses).

  In version 4, the similar concepts have been merged. Now, we use terms: data replacers and data selectors.

  The data replacers and data selectors have a unified set of properties:

  • Area - Specifies the request part to which the replacer will be applied: header, body, or cookie, and specifies the replace type: regular expression or name (path). For example, you can specify the data to be replaced in a request header or body with a regular expression, or you can specify a cookie or header field by name.

  • Expression - Specifies the regular expression, header field name (path) or cookie name.

  • Attribute (works along with regular expressions) - Helps you specify a subexpression in your data replacer. That is, you can create a regular expression that matches a larger part of the request body or header and use a subexpression to pinpoint to a smaller part to be replaced within this later data.

  • Variable - Specifies the variable to which a selector will save the extracted data, or whose value a replacer will insert instead of the found data in a request.

  • Convert - Specifies the encoding or decoding rule to be applied to data before insertion. Earlier, the conversion was possible for data selectors only. Now, you can decide yourself when it is more convenient for you to convert the values: at the moment of extracting or inserting.

    Also, version 4 includes several new conversion rules as compared to earlier product versions (see below).

  • Rule - Informational property. Specifies how the data selector or data replacer was created: manually (by a user), automatically (by a pre-defined correlation rule), or migrated from a project created in an earlier LoadComplete version.

• LoadComplete now processes requests during the recording rather than after it. You can now view the recorded requests before the recording is over.

• LoadComplete Remote Agent Service is now used both to record and run tests. If you stop this service, you will be unable to record your tests.

• The Decode property of data selectors has been renamed to Convert. The same property was added to data replacers, so you can transform data both at the moments of extraction and insertion. New conversion rules have been added.

• Traffic filters now work when recording in proxy mode.

• If you have TestComplete 11.20 or later, you can convert your functional web tests in TestComplete to load tests in LoadComplete automatically. See Creating Load Tests Based on Functional Tests.

• When you uninstall LoadComplete, the uninstallation wizard checks whether the LoadComplete installation folder contains files or folders that are not part of the product installation and asks whether you want to remove them.

  When you uninstall the LoadComplete Remote Agent, the uninstallation wizard automatically removes all files in the <LoadComplete Remote Agent>\Bin folder.

• The default timeout for requests and responses is now 5 minutes (300 seconds).

• A number of bugs have been fixed.

• LoadComplete may fail to record traffic in non-proxy (standard) mode in Firefox 40 and later, or traffic may be recorded incorrectly. We recommend that you do not record traffic in this mode. Use the proxy mode instead (it is enabled in LoadComplete by default).

• LoadComplete no longer supports test logs created in LoadUIWeb. They will be either unavailable, or displayed incorrectly. You still can open and work with projects created in LoadUIWeb 2.99.