- Redirection support for HTTP tests
When you run HTTP tests, redirect requests are followed automatically, which supports common usage patterns, such as load balancing.
- Creating secondary HTTP requests
A recording creates multiple HTTP requests and responses. In some cases, a response from the server can be dynamic, because of which the subsequent requests might need to be modified. While playing back the test, some of these dynamic requests might fail. For example, recording and playback might involve a different set of users with different permission settings or the UI elements might have changed since the time you recorded the test.
- HTTP test editor overview
With the test editor, you can inspect or customize a test that you recorded.
- Specifying the number of allowable URL redirects during test runs
When you run a test in a load-sharing environment, an unexpected redirection loop might occur during HTTP processing. An unexpected redirect response occurs when an HTTP request that normally returns a specific document redirects the browser to another location.
- Cutting and pasting in tests
You can cut, copy, and paste in HTTP tests.
- Defining requirements in tests
You can define requirements for elements in a test. These requirements specify acceptable thresholds of performance and validate service level agreements. Starting from version 9.2.0.1, you can define both performance and functional requirements in the tests. The verdict of the test is computed based on the requirements defined in the schedule. You can view the verdict in the Requirements report.
- Adding an authentication folder
Web application servers can include an option to force a login. You might have recorded a test with this option disabled but want to run the test with the option enabled. Adding an authentication folder to the appropriate test request lets you do this without recording the test again.
- Adding or removing header in batches
You can add or remove HTTP header from multiple HTTP requests or responses in batches to improve the script efficiency. For example, during the development process, there might be HTTP headers change or addition of new HTTP headers to the requests. These changes in the HTTP headers will result in the test script failure.
- Verifying expected behavior
To check whether an expected behavior occurred during a run, you add verification points. When you run a test that contains a verification point, an error is reported if the expected behavior did not occur. When global verification points are disabled (the default), you can enable verification points for a specific test.
- Specifying error-handling behavior
You can specify how error conditions are handled when running a test or schedule. Error conditions include verification point failures, connection failures, server timeouts, custom code alerts, and problems with data correlation.
- How loops affect the state of virtual users
If verification points fail unexpectedly during a run, the cause might be that virtual users in loops do not maintain their original state. To enable each virtual user to enter the loop in the original state, you can modify the test's HTTP options or add custom code.
- Splitting a test
After you record a test, you can split it into smaller tests. By splitting a test, you can create modular building blocks of smaller tests and combine them to make bigger tests. The original test is unchanged.
- Splitting a test page
You can split an HTTP page into two contiguous pages. The page title, think times, primary request, and delay are automatically recalculated for the affected pages. Customized page titles, think times, primary requests, and delays revert to the default values.
- Merging test pages
You can two or more contiguous HTTP pages into one page. The page title, think times, primary request, and delay are automatically recalculated for the affected pages. Customized page titles, think times, primary requests, and delays revert to the default values.
- Disabling and enabling secondary HTTP requests
You can disable all secondary requests within an HTTP performance test or a subset of requests in the test. Secondary requests are all requests within a page other than the primary request.
- Adding custom actions to requests
After an HTTP test is generated, you might want to add a few actions before or after a particular request is processed. For instance, for preprocessors, you can modify the headers before sending them to the server. Similarly, for postprocessors, you can extract data from the response and set it to a variable.
- Reusing tests on different hosts: Server connection variables
Your tests represent a significant investment in time and effort. You can share or reuse them for different configurations and web hosts by changing the variables for the host name and port.
- Converting tests to use SSL connections
You can convert a test that was recorded without Secure Sockets Layer (SSL) connections to use SSL connections.
- Working with Server Name Indication (SNI) recordings
If you have recorded against a server that supports Server Name Indication (SNI), an extension of the TLS protocol, the recording session file displays true for the SNI Extension field. There might be a need for you to access both SNI and non-SNI applications from the same server. To run the same test without using the SNI extension, you can manually change the value to false.
- Viewing a test in the Protocol Data view
The Protocol Data view enables you to inspect the actual test data. You can see requests, response headers, and response contents, as well as the rendered images that you see through your browser. Use this view to obtain the information you need to add custom code or to manually correlate data. This view also lets you compare the recorded data with the data retrieved during a run.
- Testing Siebel applications
When you record a Siebel application, a Siebel-specific test is automatically generated. However, before you run this test, install the Siebel Test Automation library and edit the test to use built-in Siebel variables.