Changing HTTP test generation preferences
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.
- 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 check box 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
- To not include the client delays in the page response times for the test or A schedule, in this context, is used to refer to both VU Schedule and Rate Schedule., select this check box. By default, 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.
- 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.
- Create substitutions for empty strings
- Select this check box 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.
Note: To turn data correlation off entirely or to set whether names are automatically generated for data correlation references, click Data Correlation tab. , and click theThe 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.
- After changing a setting, click Apply.