| Table of Contents |
|---|
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:
...
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:
...
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:
...
Each variable also has a scope. Possible scopes are:
| all users will see the same value of the variable during the load test. |
| 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. |
| the variable is bound to the current loop (surf session repetition) of a user, and its value can change during each 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 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. | ||
| Supports web servers that are using DNS Round Robin for load balancing. | ||
dynaTrace Integration | Creates additional data during a Load Test for analysis using dynaTrace Diagnostics. The dynaTrace Integration Handbook contains further information about how to integrate ZebraTester with dynaTrace. | ||
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 |
|---|---|
Start Add Plug-in from Var Handler Main Menu |  |
Select Plug-in from Drop-down.Click Continue… |  |
Add Input ParametersSome 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.
|   |
...
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.
...
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 |
|---|---|
Review the recorded valuesTry to judge which values could be dynamically-exchanged session parameters. If the value contains a long number or a cryptic hexadecimal string, it has a good chance of being a dynamically-exchange session parameter. |  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. |
Auto-Extract the dynamically-exchanged session parametersThis succeeds in approximately 50% of all cases. | 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. |
ErrorOn the other hand, if you receive an error message, you must manually extract the dynamically-exchanged session parameter (see the next subchapter). |  |
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. |  |
Hint: you can use this menu as a checklist of already dynamically handled parameters, irrespective of whether the extraction is done automatically or manually. The handling is already done if the line contains a Left (extract) arrow and a Right (assign) arrow.
...
Manual Extraction of Dynamically-Exchanged Session Parameters
| Note |
|---|
Beyond the scope of this online documentation. |
...
| View file | ||
|---|---|---|
|
...
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.
...
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.
...
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
...
³ = inclusive multi-homing support
Initial Values:
| the variable is initialized with an arbitrary constant value. |
| the value of the variable is not valid/undefined at initialization time. |
| the variable is initialized with the sequence number of the simulated user (0, 1, 2 ..). |
| 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 ..). |
| the variable is initialized with the iteration counter of the inner loop (0, 1, 2 ..) - of the actual simulated user. |
| the variable is initialized with the current operating system time, in milliseconds since 1970. |
| the variable is initialized with the Exec Agent hostname. |
| 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.
...
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 | ||
|---|---|---|---|
|  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. | ||
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. |
|
