Changing HTTP test generation preferences

The test generation preferences are as follows:

Do not generate a new page if think time is less than

Enter the shortest time, in milliseconds, that the generator uses as a delay to emulate the user think time for an HTTP page. If your tests contain fewer pages than expected, try a shorter interval.

Create a new page if delay between requests is greater than

Enter the longest delay, in milliseconds, that the generator allows between page requests. If this time is exceeded, a new page is generated. If your tests contain more pages than expected, try a longer interval.

Maximum request delay

Enter the longest delay, in milliseconds, that the generator allows before truncating HTTP requests. The requests are truncated on the generated test. The recorded test still contains the original values, and you can get them back by generating a new test.

Save only the first 4KB of responses larger than

Enter the limit of response data, in KB, that the generator saves. If a response is larger than the specified limit, only the first 4 KB of data is saved.

Suppress NSLookup() and use numeric IPs

Select this option to shorten test generation time. The disadvantage is that IP addresses in a test are less user-friendly than web page format (www.example.com).

Disable Page Cache Emulation during test generation

Select this option to disable page cache emulation. When page cache emulation is enabled, caching information in server response headers is honored. Additionally, requests are not submitted to the server for content that is confirmed by the client as fresh in the local cache. Page cache emulation is enabled by default.

Enable domain review before test generation

Clear the checkbox to not show the test generation page to select specific domains to be added to the test. By default, in addition to the domain that you intend to record, other domains linked to the original domain are also recorded.

Remove HTTP request delays from page response times

Select the checkbox to prevent the client delays in the page response times for the test or schedule, in this context, is used to refer to VU Schedule and Rate Schedule. As a default option, the page response times include delays to represent processing time caused by clients such as a web browser. Sometimes this delay could exceed the logical limit causing page response times to increase drastically.

Generate unique name for HTTP requests

The option to generate a shorter and unique name for the request is now enabled as a default option. You can view the shorter name of the request in the reports.

Use Legacy Test Generator

Select this option if you have been instructed to use the legacy HTTP test generator.

Automatically include verification point of

The option to automatically include the return code verification point with relaxed option is now enabled as the default option. You can view a response code verification point set for every request in the test. You can disable the default option from the preferences, if you want the response codes to be ignored.

Relaxed

Response codes that are in the same category (for example, 200, 201, 203, 209) are considered equivalent. An error is reported if the response code is not in the same category.

Exact

An error is reported if the response code does not match the recorded value exactly.

Accept sizes for primary request within

If you are automatically generating response size verification points, click to specify the acceptable size range for primary requests. No error is reported if a response is within the specified percentage above or below the expected size. By default, for primary requests, HTTP response size verification points use range matching.

The data correlation preferences are as follows:

Automatically correlate host and port data

By default, host and port data is correlated automatically. If tests in a previous release have significant manual correlations, or you are using proxies, the migration of the replace-host functionality feature is likely to fail during playback. In this situation, clear the check box. When you reopen your tests, they will not have the automatic correlation feature in them.

Automatically correlate URL pathname if redirected by response

Specifies whether URL path names are correlated if they are redirected by a selected response code. If a checkbox for a response code is selected, the test generator performs correlations for that response code. This option applies only to responses that are redirects, with a status code between 300 and 399.

Automatically correlate Referers

By default, the Referer field in an HTTP request header is correlated automatically. Clear the checkbox if you plan to correlate Referers manually. If you run tests against servers that do not require a Referer field, clearing this checkbox reduces the number of correlations performed when the test runs, and can increase user throughput.

Enable all other data correlation

By default, request and response data is correlated automatically. Clear the checkbox to disable automatic data correlation of request and response data. Consider clearing the checkbox if you create your own data correlation rules in the rules editor.

Create substitutions for empty strings

Select this checkbox to correlate empty strings. For example, strings such as spouse name or middle initial sometimes become important to correlate. However, correlating empty strings increases the time to generate a test.

Optimize automatic data correlation for execution

Specifies the characteristic that tests are automated for.

• With the Accuracy setting (the default), many references with an identical session ID value are created and the value of each session ID is substituted from the nearest previous reference.
• To make a test run faster by reducing the number of references that are created during automatic data correlation, change the optimization to Efficiency. For example, consider a test where a session ID, which is assigned when a user logs in, is included in every subsequent request in the test. With the Efficiency setting, all session IDs are substituted from a single previous reference. The downside of this setting is that it can result in incorrect correlations. For example, a request that contains the Joe Smith string might be incorrectly correlated with a request that contains the Joe Brown string.

URL rewriting for execution

Specifies how web addresses (URLs) are rewritten during test execution. When correlating data, the test generator replaces part of a URL request string with a value that the server returned in response to a previous request.

• Automatic (default): The test generator automatically determines when rewriting the entire URL during substitution will facilitate test execution.
• On: Select to rewrite URLs in every instance of data correlation. This produces larger tests that take longer to run. Try this setting if your tests fail unexpectedly.
• Off: Select to manually correlate the instances where URL rewriting is needed. This setting might cause execution errors.

URL encoding for execution

With this option, you can control the encoding of the URLs. If you set it to Automatic, the tool detects the encoding that already exists in the test and applies it to the substitution site. If you set it to ON, the tool always encodes the substitutions according to the encoding standards. If you set it to OFF, no encoding occurs.

The data correlation type preferences are as follows:

Data Correlation Types

Specify when to generate data correlation constructs. With the Automatic setting, the test generator creates the required constructs where needed. If the test does not contain the required constructs, change the setting to On, which will always perform data correlation. If tests do not require a specific construct, select Off, which has the additional benefit of improving performance on subsequent test generation.

Jazz Foundation Services

The On and Automatic options enable data correlation for Jazz applications that use REST storage or query APIs from Jazz Foundation Services. An example of such an application is Rational DOORS Next Generation. Although data correlation does not typically apply to browser-based Jazz web clients, it may be useful for other HTTP client-server applications that use REST services and the Atom Publishing Protocol for updating web resources.

Jazz Web Applications

The On and Automatic options enable data correlation for Jazz web applications that use the Jazz Foundation web UI framework Examples of these web applications are the web interfaces for Rational Quality Manager and Rational Team Concert. Data correlation can also be useful for other web applications that contain javascript that employs JSON for client-server data exchange. This is a common practice with DOJO- and AJAX-based applications.

JSON

To perform data correlation on web applications that uses JSON framework, ensure that Automatic or ON is set to the JSON entry.

Prioritize correlation based on ID

Select On to correlate HTML response code based on its ID attribute. Generally, the HTML response code after the recording would appears as <input type="username" name="User" id="aaa" value="John"/>. Some applications dynamically update the name attribute. Therefore, when you play back the test, the HTML response code would appear as <input type="username" name="idt020" id="aaa" value="John"/>. Because the name attribute is changes dynamically, data correlation does not occur and the playback fails. When this option is turned on, the ID attribute is considered as the basis to correlate the name attribute in the request and to locate the value attribute.