Cookie Correlation

Example. A public website uses a session cookie to maintain state integrity for every visitor. The server issues a unique cookie to every user on the first visit. A cookie is stored in the user's browser and is included in requests on subsequent visits. If cookie handling is disabled in the browser, the website might not work correctly.

Load testing requirements. To avoid request failures, a recorded cookie must be replaced by a unique value generated by the server for every VU. Cookie persistence should be provided for the duration of the test for every VU. StresStimulus handles cookie correlation automatically, regardless of the webserver platform, to ensure that every VU adheres to its client session. For example, it automatically feels the JSESSIONID cookie in Java applications and ASP. NET_SessionId cookie in applications.


Example. A stateless Webserver sends the client a dynamic value representing the application state. This value is included in the response body as a hidden web form field. On the subsequent request, the server expects to receive the same value to maintain application integrity from this client. The application state can change from request to request.

Load testing requirements. During load test execution, reissuing requests with recorded application states can result in server errors. To avoid these errors, every request from a virtual user must include the dynamic application state that the server provided. To achieve that, the dynamic value must be identified, extracted from the responses, and then used to replace the recorded value in the subsequent requests. This process is called correlation. StresStimulus handles correlation automatically for all web application platforms. For example, it automatically correlates __VIEWSTATE, and __REQUESTDIGEST hidden web form fields for ASP.NET and SharePoint applications, respectively. Autocorrelation supports various types of web sessions, such as HTML and AJAX pages. During test execution, autocorrelation rules automatically modify requests to make VUs compatible with dynamic web applications.

Note: Internally, each autocorrelation rule is implemented as a hidden unnamed response extractor and a parameter that uses the extractor to substitute a recorded value in the subsequent request. The extractor is hidden, but the parameter appears on the Test Case Tree. Though it is not recommended, you can delete autocorrelation rules.

Parameterization with Server Data

Example 1. A secure Web application requires users to login. The Webserver creates an authenticated session for every user, generates a unique token, and sends it back to the browser in the response body. On every subsequent request, the browser sends the token to identify the user and its session.

Load testing requirements. Reissuing requests with the recorded session ID during the load test execution will result in server errors. To avoid these errors, every request from a virtual user must include a dynamic token that this virtual user received from the server. To achieve that, the dynamic tokens must be identified, extracted from the responses, and used to replace the recorded values in the subsequent requests.

Example 2. A web application maintains application-specific dynamic values that are generated on the server and are included in some of the requests. Parameterizing such requests is more difficult than in the previous example.

Several factors listed below complicate finding the dynamic values and the dynamic requests:

Load testing requirements. The process of finding and matching dynamic fields in the recorded requests to responses and creating parameterization rules by injecting proper dynamic values in the proper request, is called parameterization. StresStimulus supports manual and automatic parameterization:

Parameterization with User Data

Example. A test scenario includes a search page which submits a user's search text. When running a load test, the server receives the same recorded search text for all VUs. Due to server caching, the server's response will be substantially accelerated because a search result will be retrieved from memory without accessing the database. As a result, performance testing will be inaccurate.

Load testing requirements. For realistic performance testing, multiple sets of user data should be used during the replay to properly emulate multiuser data entry. Such dynamic sets of data can be either predefined or dynamically created on-the-fly.

StresStimulus supports all listed types of dynamic requests and provides increased performance testing accuracy as well as saves time on test configuration.