Set HTTP test generation preferences

Set test preferences

Test generation preferences

To set test generation preferences, go to...
Window | Preferences | Test | Test Generation | HTTP Test Generation

...and set...

Do not generate a new page if think time is less than Shortest time, in milliseconds, that the generator uses as a delay to emulate user think time for an HTTP page. If the tests contain fewer pages than expected, try a shorter interval.
Generate a new page if delay between requests is greater than Longest delay, in milliseconds, that the generator allows between page requests. If time is exceeded, a new page is generated. If the tests contain more pages than expected, try a longer interval.
Maximum request delay 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 Shorten test generation time. IP addresses in a test are less user-friendly than domain names
Disable Page Cache Emulation during test generation When enabled, caching information in server response headers is honored. Requests are not submitted to the server. Default is enabled.
Use Legacy Test Generator Select to use the legacy HTTP test generator.
Automatically include verification point of If verification point check box is selected, the code and edit controls for this type of verification point are generated in all tests. Verification points can also be enabled or disabled within specific tests.
Accept sizes for primary request within If response size verification points are generated automatically, 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.

Data correlation preferences

To set data correlation preferences...
Window | Preferences | Test | Test Generation | HTTP Test Generation | Data Correlation tab

Use Automatic to have test generator create the required data correlation constructs where needed. Use On to always perform data correlation. Use Off if tests do not require a specific construct. This will improve performance on subsequent test generation.

For Jazz Foundation Services.
On and Automatic enable data correlation for Jazz applications that use REST storage or query APIs from Jazz Foundation Services, such as Rational Requirements Composer. Data correlation does not typically apply to browser-based Jazz web clients, however it may be useful for other HTTP client-server applications that use REST services and the Atom Publishing Protocol for updating web resources.
For Jazz Web Applications.
On and Automatic enable data correlation for Jazz web applications that use the Jazz Foundation web UI framework, such as the web interfaces for Rational Quality Manager and Rational Team Concert. Useful for web applications that leverage DOJO and AJAX javascript for JSON for client-server data exchange.

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 the tests, they will not have the automatic correlation feature in them.
Automatically correlate URL pathname if redirected by response If a check box for a response code is selected, the test generator performs correlations for that response code. Applies to redirect responses, 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 check box if you plan to correlate Referers manually. If you run tests against servers that do not require a Referer field, clearing this check box 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 check box to disable automatic data correlation of request and response data. Consider clearing the check box if you create our own data correlation rules in the rules editor.
Optimize automatic data correlation for execution 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 containing the Joe Smith string might be incorrectly correlated with a request containing the Joe Brown string.

URL rewriting for execution 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 Rewrite URLs in every instance of data correlation. Produces larger tests that take longer to run. Try if the tests fail unexpectedly.
Off Manually correlate the instances where URL rewriting is needed. This setting might cause execution errors.

Related:

Record reliable HTTP tests
Configure Internet Explorer for recording from a secure web site
Record an HTTP test
Split an HTTP test during recording
Reset browser LAN settings if recording is interrupted
Create HTTP tests manually
Record Adobe Flex content
Record Microsoft Silverlight applications

Error 404 - Not Found
Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.

Do not generate a new page if think time is less than	Shortest time, in milliseconds, that the generator uses as a delay to emulate user think time for an HTTP page. If the tests contain fewer pages than expected, try a shorter interval.
Generate a new page if delay between requests is greater than	Longest delay, in milliseconds, that the generator allows between page requests. If time is exceeded, a new page is generated. If the tests contain more pages than expected, try a longer interval.
Maximum request delay	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	Shorten test generation time. IP addresses in a test are less user-friendly than domain names
Disable Page Cache Emulation during test generation	When enabled, caching information in server response headers is honored. Requests are not submitted to the server. Default is enabled.
Use Legacy Test Generator	Select to use the legacy HTTP test generator.
Automatically include verification point of	If verification point check box is selected, the code and edit controls for this type of verification point are generated in all tests. Verification points can also be enabled or disabled within specific tests.
Accept sizes for primary request within	If response size verification points are generated automatically, 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.