2. Correlation - Dynamic Session Parameters
This page is not comprehensive, but an extended excerpt of the ZebraTester-Installed User PDF Manual called the ZebraTester Users Guide.
Dynamic Session Parameters
However, it is often desirable - or even required - that the recorded web surfing session must first be edited. Some possible use-cases are:
The web application contains HTML form-based authentication, and it is required that each user use a known username and password to login to the web application.
You wish to take a URL call variable and make it a parameter and set the parameter's value each time before starting the load test—for example, a booking date of a flight.
The recorded session contains dynamically-exchanged session parameters, which must be extracted at run-time from the web pages, and then assigned to succeeding URL calls to run the load test program successfully.
Variable Handler “Var Handler” Introduction
All of these tasks and many more can be performed using the "central variable handler menu" called Var Handler, which manages all dynamically- applied modifications to web surfing sessions. The process involves two steps:
First, a variable must be defined or extracted.
Then variable must be assigned.
In other words, a variable must first be extracted before it can be assigned; however, some of the most commonly-used dialogs also support making automatic and/or global assignments. Extracting variables is completely independent of the assignment; thus, many combinations are possible, providing maximum flexibility.
VAR Extraction
Variables can be extracted by using the Web Admin GUI from the following sources:
from Input Files, whose data are read at run-time during the load test
from HTML form parameters; for example, hidden form fields
from values of received XML and SOAP data
from values of received JSON data
from values of received Google Protobuf data
from CGI parameters contained in hyperlinks, form actions, or HTTP redirects
from any text fragments of received HTML and XML data
from User Input Fields - which are arbitrary configurable load test input parameters
from HTTP response header fields
from output parameters of Load Test Plugins
Additionally, it is also possible to define stand-alone variables that have constant or dynamic initial values.
VAR Assignment
A variable can be assigned as follows, irrespective of how it was extracted:
to the value of an HTML form field -
to the value of a CGI Parameter of a URL call
to values of XML and SOAP data of a URL call
to values of Google Protobuf data of a URL call
to a text fragment of a URL call (within the HTTP request header or the HTTP request content.
to the protocol (HTTP/HTTPS), the hostname, or the TCP/IP port of one or all URL calls
to the user’s think time of a web page
The response verification algorithm of a URL call (searched text fragment or size of the received content.
to the number of iterations and/or the pacing delay of an inner loop F
to some HTTP request header fields (ZebraTester automatically handles most request header fields)
to an input parameter of a Load Test Plugin
Each variable also has a scope. Possible scopes are:
global
all users will see the same value of the variable during the load test.
user
although the variable has been defined only once, each user will see its own value during the load test. There are as many virtual instances of the variable as concurrent users during the load test.
loop
the variable is bound to the current loop (surf session repetition) of a user, and its value can change during each loop.
inner loop
the variable is bound to the user's inner loop and can change its value during each iteration of the inner loop.
Although seemingly complicated, the Var Handler is a powerful tool that is easy to use. It is possible to satisfy complex requirements quickly with a few mouse clicks, as described in the next sections. Programming knowledge is not required.
"WHAT ARE THOSE ICONS?"
Icons and what they do.
There are many tiny icons (seemingly identical!) that are actually context-sensitive in the ZebraTester. Generally:
A Dot/Circle in front of a Box Assigns Values to a Variable.
A Box in front of a Dot/Circle Extracts Values from a Variable.
Icon
Meaning
Example/Dialog
Var Assigner “Assign a Variable”
Dots in front Boxes ASSIGN a Var to something.
HTTP REQUEST HEADER: This first ASSIGN icon above the HTTP Request Header and it Assigns Var to an HTTP Header Field
Var Extractors “Extract a Variable”
Boxes in front of Dot EXTRACT a value to a Var.
HTTP RESPONSE HEADER: This first EXTRACT icon, Extracts the Var from the Header Field
Blue Left Arrow indicates that the value of the variable has been extracted.
Red Right Arrow inside the search result means that a (variable) string has been sent.
The Magnifier icon will change depending on the function it’s next to
“Var Extract Details” next to Blue Left Arrow displays more details about how the variable was extracted.
“Var Assign Details” next to Red Right Arrow displays more details about how the variable was extracted.
“Modify Input File Properties” next to Input File.
“Modify User Input Field Properties” next to User Input Field.
The Verify Input File Parsing Button displays a preview of how the input file will be parsed during load test execution.
Replace HTTP Response Content: directly modify the recorded data.
Download Response Content to a File
Expand the view of the HTTP Response Content
Var Finder: Supports finding and handling dynamically-exchanged session parameters easily.
Enable dynamic URL rewriting button in the Var Handler
Described in the J2EE URL Rewriting Section.
Define New Stand-Alone Var
Variables are usually defined implicitly by creating Input Files, User Input Fields, using the Var Finder, or extracting values using the Var Handler.
However, it is also possible to define variables directly for special-purpose use. Depending on the scope, directly-defined variables can have special initial values set during the load test by the load test program itself.
Declare External Resources
This menu allows you to declare additional external resources needed when executing a load test. Typically such external resources are Java library files (*.jar files) used by self-developed plug-ins or JUnit load test plug-ins, or Google Protobuf FileDescriptorSets (*.desc files) used to parse G-PROTOBUF messages. However, also any other file types can be declared.
Note: Any declarations made in the Var Handler menu, such as Input Files and Main Classes of Plug-Ins, are not external resources in this context and don't need to be declared because ZebraTester knows already these declarations.
Other edits, search/detail, and feature icons, but these Extract and Assign icons will be the most prevalent. The many use cases for these icons are beyond this demo's scope and this article.
The Var Handler UI Summary
The variable handler can be invoked by clicking on any recorded URL call in the main menu. On the left side of the window, all details of the URL call, which changes from call to call, are displayed. On the right side of the window, the Variable Handler is displayed and summarizes all extracted and assigned variables. This right-hand side part of the window remains constant (static) for all URL calls:
Load Test Plugins
ZebraTester Load Test Plugins are Extension Modules to the ZebraTester product. Plugins are configured using the GUI and are executed during a Load Test. The following are a few of the Plugins that are already predefined and delivered as part of the ZebraTester installation:
Plugin Designation in the GUI
Plugin Functionality
Abort Failed Test
Aborts a running Load Test if too many errors occur within a configured time interval.
Assign File Data to Request Content
Read the data of a file from disk and assign it to a URL call (only useful for HTTP/S POST requests and some WebDAV methods).
Cookie Injector
Sets a Cookie before or during the execution of a Load Test.
Get Cookie Value
Extracts the value of a Cookie into a GUI Variable. The extracted value can be later assigned to a CGI parameter of a succeeding HTTP/S Request (among other targets).
Defer Load Test Start
Delays the start of a Load Test Program for a configured time, expressed in minutes.
Delay Full Load
Limits the load - respectively, the number of the simulated users - for a configurable time. After this time is elapsed, the load is increased to the original number of planned users.
DNS Round Robin Load Balancing
Deprecated: Replaced by integrated DNS options that can be configured per test run.
Supports web servers that are using DNS Round Robin for load balancing.
dynaTrace Integration
Generic Output File
During a Load Test, writes the values of up to 6 GUIVariables line-by-line to a text file. The file scope is freely configurable - lines can be written per virtual test user, per loop execution, or URL call.
Input File List
Reads from a metafile a list of input files and assigns each simulated user a known input file. The simulated users read a new line from their input file each time before executing a new loop.
Large Input File
Reads data from a large input file which has an unlimited size ( 1 GB)
Large Response Content
Allows receiving response content data of a large size (up to 2 GB) for one or several URLs. Note that all response data are read as usual during load test execution but that only a part is stored internally.
Limit Response Content
Limit the receiving of response content data to a specified size. Further reading of data from the webserver during load test execution is aborted (skipped) for the configured URL when the maximum size is reached.
PKCS# 11 Security Device
Support for Smart Cards / PKCS# 11 Security Devices, which contain an SSL Client Certificate used for authentication against web servers.
Remove Cookie
Removes a cookie from the cookie store of a simulated user.
User Synchronization Point
Retains all active users at a configurable synchronization point until all of the users have reached this point. After that, the users are rereleased by applying a configurable deblock delay multiplied with the no. of the actual user (0, 1, 2 …).
The configuration of a Plugin, respectively adding a Plugin to a recorded web surfing session, can be done in the Var Handler:
Step
Screenshot
Add Input Parameters
Some Plugins require input parameters.
So, it may be necessary to define additional variables.
One option to define such variables is to create global visible stand-alone variables with constant initial values if constant values are required as Plugin input parameters.
Additional variables can also be extracted from other sources, for example, from Input Files, or User Input Fields, or responses of previous URL calls.
Add Plug-in when done.
Note the Var Handler UI will change to reflect the new Vars and the newly-added Load Test Plug-Ins.
Dynamically-Exchanged Session Parameters
The HTTP protocol by itself is stateless - there is no memory from URL call to URL call; however, most web applications require state information, such as the stage in a process that a user had reached - before login, after login, placed an order, and so on. Usually, cookies are used to keep state information. Cookies are set by the web server as additional HTTP response header fields and sent by the web browser back to the webserver and the HTTP requests of succeeding URL calls. This is normally not a problem because the load test program automatically does the correct handling of cookies.
However, some web applications use, as a special "session context" dynamically-generated CGI- or form-parameter values which are exchanged between the web application and the web browser in such a way that, if you repeat the same web surfing session, a more or less random algorithm changes the values of these parameters. If you use, during a load test, these "burned-in" values of dynamically-generated server-side CGI- or form-parameters, the load test will fail. A good example of this is the "__VIEWSTATE" parameter used by Microsoft web servers.
The solution to this problem is that the values of these dynamically-exchanged session parameters must be extracted at runtime (during the load test) and then assigned to the corresponding parameters of succeeding URL calls.
To make this task easier, ZebraTester provides the Var Finder menu. You can invoke the Var Finder either from the main menu or from the Var Handler:
Automated Handling of Dynamically-Exchanged Session Parameters (Var Finder)
The Var Finder menu provides an overview of all URL request parameters and their values used anywhere in the entire recorded web surfing session. In this view, a parameter "name-value" pair is shown only once, even if the same "name-value" pair is used by more than one URL call. If the same parameter(-name) is used with different values, it will be shown multiple times, once for each distinct value.
Process
Step
Screenshot
In the example above, the various parameter names containing ViewState are dynamically-exchanged session parameters. But the one “ctl00$MainContent$TeamNamesDropDownList=AC Milan” is not because the value “AC Milan” had been entered manually into forms, via the drop-down list, during the recording of the web surfing session.
To do this, click the
“Click here to perform automatic handling for dynamically-exchanged session parameter” icon at the left of the parameter name.
Success
If you receive a success message, there is nothing more to do for this parameter. In this example, the levid var was successfully created with the auto-extraction. Note the 2 with the left blue arrow; a var extraction.
The corresponding definitions inside the Var Handler are automatically created.
In this example, the parameter __VIEWSTATE could be handled automatically. The other parameters (d & t) must be extracted manually since these parameters are listed more than once (i.e., the same name with different values); the extraction must also be done more than once for each distinct value.
Manual Extraction of Dynamically-Exchanged Session Parameters
Beyond the scope of this online documentation. Beginning with ZebraTester V4.4-G, the "Var Extractor Wizard" was added to the product. For further information, the dedicated manual about the Handling of "Dynamically- Exchanged Session Parameters" is included in the installation and is attached.
Replacing Text Patterns
In rare cases, the name of an HTTP request parameter is variable instead of the parameter value being a variable. Even rarer are cases where a file path of a URL call contains variable parts.
You can handle such cases as follows:
Use the text pattern-based variable extractor.
At the last step, use the checkbox Assign Var automatically to all HTTP requests containing the same text pattern (full binary replacement of recorded value overall requests) instead of Assign var automatically to all HTTP requests that contain form CGI parameters with the same recorded value.
There are also other rare cases in which a text pattern must be extracted from an HTTP response header because a variable HTTP redirection occurs. A part of the URL file path, or a part of a CGI parameter, is variable. This is also supported - if two extractor icons are present, you simply use the second one.
Extracting and Assigning Values of XML and SOAP Data
In case that XML or SOAP data have been recorded, ZebraTester parses such data automatically and displays an additional XML Icon within the title of the “HTTP response Content” and the “HTTP request content” box:
HTTP File Uploads
If a recorded web surfing sessions contain HTTP file uploads, you can also use a variable for each file upload which allows selecting the uploaded file dynamically during the load test. Such a variable is often extracted from an input file whose lines contain different file names (without file paths).
Note: Before you start the load test, you have to place all files uploaded into the same project navigator directory where the compiled load test program resides. Before you start the load test, you have to zip the compiled *.class of the load test program together with all files uploaded (and together with all used input files). After this, execute the zipped archive itself as a load test program.
Overview of most commonly used Extract and Assign Options
The following illustration is not exhaustive.
Directly-Defined Variables (stand-alone Variables)
Variables are usually defined implicitly by creating Input Files, User Input Fields, using the Var Finder, or extracting values using the Var Handler.
However, it is also possible to define variables directly for special-purpose use. Depending on the scope, directly-defined variables can have special initial values set during the load test by the load test program itself.
Supported combinations of scope and initial values are:
Initial Value
global var
user var
loop var
inner loop var
constant value
x
x
x
x
null
x
x
x
x
current user counter
-
x
x
x
loop counter
x¹
x²
-
-
inner loop counter
-
-
-
x
system time milliseconds
x
x
x
x
load source IP hostname
x
x³
x³
-
load source IP address
x
x³
x³
-
¹ = (outer) loop counter overall users
² = (outer) loop counter of the user
³ = inclusive multi-homing support
Initial Values:
constant value
the variable is initialized with an arbitrary constant value.
null
the value of the variable is not valid/undefined at initialization time.
current user counter
the variable is initialized with the sequence number of the simulated user (0, 1, 2 ..).
loop counter
global var scope - the variable is initialized with the outer loop counter (0, 1, 2 ..) - counted over all simulated user/user var scope: the variable is initialized with the outer loop counter of the actual simulated user (0, 1, 2 ..).
inner loop counter
the variable is initialized with the iteration counter of the inner loop (0, 1, 2 ..) - of the actual simulated user.
system time milliseconds
the variable is initialized with the current operating system time, in milliseconds since 1970.
load source IP hostname
the variable is initialized with the Exec Agent hostname.
load source IP address
the variable is initialized with the Exec Agent IP address.
J2EE URL Rewriting
The web application developers can configure a Java (J2EE) application server. A procedure called "URL rewriting" is used to build the session context instead of using session cookies. In this case, the server will assign a special dynamic session parameter to every returned hyperlink at runtime and to every form, which contains the session context.
An example of a hyperlink with applied URL rewriting is as follows:
<a href="http://www.d-fischer.com:8080/prxtool/servlet/WebMainMenu;jsessionid=bu3fy0bbj1?currentDir=344">forward</a>
The URL rewriting parameter [jsessionid=bu3fy0bbj1] is appended to the URL file-path[http://www.d-fischer.com:8080/prxtool/servlet/WebMainMenu], separated by a semicolon, and appears before the normal CGI parameters [currentDir=344], which start with a question mark.
Usually, a Java application server supports both session cookies and URL rewriting; however, only one of these procedures is applied, on a per-user basis, to build the session context. The inner algorithm of the application server works as follows:
When a web browser requests any page from the server for the first time, the server does not know if the web browser supports session cookies. For this reason, the server sends a session cookie to the web browser and performs additional URL rewriting for all hyperlinks and forms for the first web page.
When the web browser requests a second page from the server and transmits the received session cookie back to the server, the server will know that it supports cookies. For the current and all succeeding web pages, URL rewriting will no longer be done.
If on the second-page request, the web browser does not send back the cookie, or if the application server is configured to disable the use of session cookies (in which case an initial cookie will not have been sent anyway), the webserver notes the absence of the session cookie. It does URL rewriting for the current web page and all succeeding web pages.
You do not usually have to do anything special in this case because most Java application servers support session cookies. However, if session cookies are disabled, you must first enable URL rewriting support inside the Var Handler before the load test can be executed successfully. You will recognize the need for this when you review the recorded URLs in the main menu - if the URL rewriting parameter is found in all URL calls in most web pages, you will have to enable URL rewriting support in the Var Handler.
Proceed as follows:
Step
Screenshot
Step
Screenshot
Choose any URL detail menu.
Click the Enable Dynamic URL Rewriting button in the Var Handler.
Enter the name of the URL rewriting parameter in the field Rewrite Parameter
Enter an arbitrary variable name in the field Map to Var Name
Use the option automatically for the field Dynamic Handling.
After URL rewriting has been enabled, the Var Handler shows only the first extraction of the URL rewriting parameter - but not its assignment. This is normal behavior because the assignment in succeeding URL calls will be done automatically later in the load test without additional configuration.
Note: the URL rewriting parameter may also have a name other than jsessionid because the name itself can be configured inside the web application server. You must enter the actual parameter name in the field Rewrite Parameter.
It's also possible that the URL rewriting parameter's value can change during the web surfing session, for example, after logging in to the web application or after logging out. In this case, you will see two or more extractors for the URL rewriting parameter inside the Var Handler.
Last updated
Was this helpful?
