Page request fields apply to the page that is currently
selected.
- General tab
- Version
- Indicates the HTTP version.
- Method
- Indicates the HTTP request method that was used during recording.
Typically, you do not change this value unless you are adding a new
request to a test. GET, POST, PUT, HEAD, and DELETE are supported.
- Primary request for page
- Displayed for the primary request, and cannot be modified. A page
can contain only one primary request.
- Click to set as primary
- Displayed for all secondary requests. Because each page can have
only one primary request, if you select this option, the Primary
request for page option is moved to this request, and
the Click to set as primary option is moved
to the original primary request. To undo your change, select Click
to set as primary on the original primary request.
- Connection
- Specifies the connection to the web server. The connection includes
the host name, which is typically the fully qualified domain name,
and the listener port on the web server. Click the name of the connection
to navigate to the server access configuration where the connection
is defined. Click Change to change the connection
used for this request.
- URL
- Specifies the path to a resource (such as a page, graphics file,
or stylesheet file). When the method is GET, the URL field
typically includes query strings that are designated as datapool candidates.
- Data
- Specifies additional content data that might be needed to clarify
the request. When the method is POST, the data frequently includes
values that are designated as datapool candidates.
- Request Headers
- Lists each request header and its value. To change the value
of a header, click the row, and then click Modify.
To add a new header, click Add. To delete a
header, click Remove.
- Enable response time breakdown
- Select to enable the collection of response time breakdown data.
You can enable response time breakdown collection at the parent or
page level. Not all test elements support response time breakdown
data collection.
Use the Advanced page to configure
performance requirements, error handling, and delay behavior for the
request.
- Advanced tab
- Always log details
- To ensure that the details about the request is always logged,
select this check box.
- Use substituted URL in performance reports
- Use this option to view the substitutions in Page Elements report.
- Performance Requirement
- All performance requirements are displayed in the table. Shaded
requirements indicate that they are undefined. To define a requirement,
provide details in Operator and Value.
To apply the defined requirement to multiple requests, select the
requests in the test, right-click the requirement row in the table,
and click Copy Requirements.
- Enable Performance Requirements
- Select to enable the use of performance requirements for this
test.
- Name
- Specifies the name of this set of defined performance requirements.
By default, the name is the URL of the request. Although you can change
the name to improve readability, only the Performance Requirements
report uses this name. Other reports use the default name. Click Use
Defaults to reset Name to the default
value.
- Operator
- Click this field to display a list of mathematical operators.
Select an operator for the performance requirement.
- Value
- Click this field to set a value for the requirement.
- Standard
- Select to enable this requirement to be processed by the report
as a standard requirement. Standard requirements can cause a test
to fail. Performance requirements that are not listed as standard
do not cause the test to fail.
- Hide Undefined Requirements
- Select to prevent the table from including undefined performance
requirement candidates. Selecting this check box hides all shaded
rows.
- Clear
- Select one or more requirements, and click to remove the definition.
The requirement is still available and can be redefined.
- Error Handling
- Click to open the error condition table. You can use error handling to specify an action to take
and a message to log when a specific condition occurs. Error conditions include verification point
failures, server timeouts, custom code alerts, and data correlation problems. All error conditions
are displayed in the table, beside the action to take and the message to log when the error occurs.
To define an error handler, select a Condition, and then click
Edit. The Errors report lists the number of errors and the corresponding
actions that occurred in the test or schedule. You can also specify whether an error contributes to
the health of the page. To set the health parameter, select a Condition and select the
Override contribution to health status check box. The Page Health report
shows the health of each page.
- Hide unselected conditions
- Click to display only the selected error handlers. Hiding a condition
does not deactivate the condition.
- Applied Transform
- Indicates the data transformation that is applied to the request.
Click Change to select a data transformation
to apply to the request.
- Character set
- Indicates the character set to be used for the page request. Click Change to
see the valid character sets.
- Client Processing Delay
- Previous versions of tests support only waiting for primary requests. Wait
for and Release when are not available.
The additional delay in previous versions of tests is measured from
the first character received of the primary request.
- Wait for
- Indicates the associated request that must start or finish before
this request is issued. Click Request to select
a different request. Click the Clear request association icon
to remove the association.
- Release when
- Select Last Character Received or First
Character Received to indicate when this request is issued
in relation to the associated request.
- Additional delay (ms)
- Indicates the additional delay, in milliseconds, to wait before
this request is issued. Delays are statistical emulations of user
behavior. You can scale this delay at the test level to make a test
play back faster (or slower) than it was recorded.
- Digital Certificates
- Lists details about the certificate stores that the test uses.
Click Add to add a certificate store for the
test to use. HTTP and SOA support digital certificates. Other protocols
do not support digital certificates.
- Enable response time breakdown
- Enables collection of response time breakdown data. With response
time breakdown, you can see statistics on any page element. The statistics
show how much time was spent in each part of the system under test.
You can use response time breakdown to identify code problems. You
can see which application on which server is the performance bottleneck,
and then drill down further to determine exactly which package, class,
or method is causing the problem.
This option is displayed in multiple
test elements. Enabling this option in an element also enables it
in the element’s children. For example, enabling monitoring at the
test level also enables monitoring at the page and request levels.
You can enable monitoring for a specific page; doing so enables monitoring
for the requests of that page, but not for other pages or their requests.
HTTP and SOA support response time breakdown. Other protocols
do not support response time breakdown.