You can change how performance tests are generated, such
as how tests process verification points, data correlation, and pages.
Procedure
- Click .
- Select the preference to change.
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 user think time for an HTTP page. If your tests
contain fewer pages than expected, try a shorter interval.
- Generate 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.
- Use Legacy Test Generator
- Select this option if you have been instructed to use the legacy
HTTP test generator.
- Automatically include verification point of
- Click to specify the types of verification points to be automatically
included. If a check box for a verification point 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.
- 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 check box 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 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 your
own data correlation rules in the rules editor.
- 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.
Note: To turn data correlation
off entirely or to set whether names are automatically generated for
data correlation references, click , and click the Data Correlation tab.
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.
- For Jazz Foundation Services, On and Automatic 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.
- For Jazz Web Applications, On and Automatic 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.
- After changing a setting, click Apply.