Generate HTTP(S) Load Test Program

No Binary Data (Images ...)

It suppresses all URLs received along with a 200 (ok) HTTP status code, but with non-ASCII content data. This will strip away all images and other kinds of binary data, such as flash animations.

No CSS, JS (Only HTML)

suppresses all successfully-received (200 ok HTTP status code) ASCII text-data which are not in HTML format. This will strip away style sheets (CSS) and JavaScript files.

No Cached Data (304)

suppresses all browser-side cached URLs received with a 304 (found) HTTP status code from the webserver (recommended option).

No Errors

It suppresses all URLs with an incomplete response from the webserver and suppresses all error responses from the webserver (HTTP status codes equal to or greater than 400). If you do not activate this option, the load test will check that error is still there; that is, an error.

Host

suppresses all URLs which are not received from a given hostname. You may use this option to strip away foreign content such as advertisements from a banner server. Additionally, the usage of an exclamation mark “!” in front of the hostname is also supported, which means that items from this host are suppressed. Several hostnames can be entered, separated by commas (,) - with or without an exclamation mark.

Click the Generate Load Test button in the main menu or in the URL Details / Var Handlermenu to generate the load test program.

Generate Load Test Program Menu

Script Options

Java™ Classname

Desired name of the load test program.

Content Test Algorithm

Defines how the URL calls' received content will be verified during the load test.

[+]   apply (heuristic) methods from recorded session to check received content: This means that the automatically-applied content test algorithms will be used, including for modifications that have been done manually (see section 4.2.2). Additionally, the received HTTP status code (200, 302..) and the MIME type (text/HTML, image/gif ..) of each URL call will also be verified. This is the only option that ensures that the received web pages are correctly verified.

[±]   compare all URL calls with recorded size (+/- 5%): This means that only the received content's size is compared with the recorded size. The automatically-applied test algorithms will not be applied during the load test; however, the HTTP status code and the MIME type will be verified. The allowed tolerance range of the received size is implicitly set to +/- 5% for all URL calls. This option is not recommended because you may get misleading errors if a dynamically-generated HTML page changes in size or may not detect some errors embedded within an HTML page of the correct size.

[-]   none - content test disabled: This means that only the HTTP status code and the MIME type will be verified during the load test. The results of such tests are often invalid because errors embedded within an HTML page will not be detected.

Character Encoding

Defines which character set is used to search for strings within the received content, and data read from Input Files. Usually, you can use the default option "OS Default," which means that the default character set of the (local) operating system is used; however, if you execute remote tests on other operating systems different from your local OS (Windows - Unix), it is recommended that you use the character set ISO-8859-1 to avoid problems with special characters, such as umlauts.

Generate External Files for XML and SOAP Request Data

Apica Table Server

A toggle to apply the Apica Table Server API configuration from Personal Settings

HTTP Protocol Options

HTTP Protocol Version

Usually, the HTTP protocol version 1.1 should be used for tests. This protocol version is supported by all newer web browser and web server products and allows the re-use of network connections over several URL calls (HTTP keep-alive option). If HTTP protocol version 1.0 is chosen, the network connections cannot be re-used, and a new network connection is opened and closed for each URL call.

Allow Keep-Alive

the re-use of network connections can also be disabled for HTTP protocol version 1.1 using this option; however, this is not recommended.

Strip Referer Header Field

The HTTP referer header field is not commonly used by web applications, and therefore often dropped by (local) internet security tools. Enabling this option reduces the data transfer and makes the load test program smaller.

Strip Accept Header Field to */*

The HTTP Accept header field is not commonly used by web applications but contains a long text string. Setting the accept header field to */* reduces the data transfer and makes the load test program smaller.

Load Test over HTTP(S) Proxy

This option allows the execution of a load test through an (outgoing) proxy server by applying the next proxy configuration from the menu "Personal Settings" You should only use this option if you have no direct TCP/IP connection between the load test program and the webserver.

HTTP/SSL Authentication Options

Basic Authentication

This option enables user-specific, individual, basic authentication against the webserver. Please note that ZebraTester already automatically supports "common" basic authentication. If all simulated users use the same username and password for basic authentication, this option must not be enabled. If this option has been enabled, you must manually create an Input File - named basicauth.txt - which contains a line for the username and the password for each simulated user. These two elements on each line must be separated by semicolons (;). The Input File must be located in the same directory as the generated load test program. After compiling the load test program inside the Project Navigator, you must first ZIP the load test program's compiled class together with the basicauth.txt file and then execute the zipped archive itself as the load test program.

Digest Authentication

This option enables digest authentication against the webserver. If you choose to use a common Username / Password, the same username and password are used for all simulated users. By choosing the option Apply individual Digest Authentication per user from the input file, each simulated user uses its own username and password. In such a case, you must manually create an input file - named digestauth.txt - which contains on each line the username and the password per simulated user. These two line-elements must be separated by semicolons (;). The input file must be located in the same directory where the generated load test program is stored. After compiling the load test program inside the Project Navigator, you must ZIP the compiled class of the load test program and the digestauth.txt file, and then you must execute the zipped archive itself load test program.

NTLM Authentication

This option enables NTLM (Windows) authentication. If you choose to use common NTLM account from the Personal Settings menu, the same NTLM username and password are used for all concurrent users. By choosing the option apply individual NTLM account per user from input file, each simulated user uses its own username and password, in which case you must manually create an Input File - named ntlmauth.txt - which contains a line for the domain, the username, and the password for each simulated user. These three elements on each line must be separated by semicolons (;). The Input File must be located in the same directory as the generated load test program. After compiling the load test program inside the Project Navigator, you must first ZIP the load test program's compiled class together with the ntlmauth.txt file and then execute the zipped archive itself as a load test program.

Kerberos Authentication

This option enables Kerberos authentication against web servers and/or outbound proxy servers. If you choose the option use common Kerberos account from Personal Settings menu, the same username and password is used for all simulated users. By choosing the option apply individual Kerberos account per user from input file, each simulated user uses its own username and password. In such a case, you must manually create a file - named kerberosauth.txt - which contains on each line the username and the password of a user account. These two line-elements must be separated by semicolons (;). The file must be located in the same directory where the generated script is stored.
After compiling the script inside the Project Navigator, you are requested to ZIP the script's compiled class together with all Kerberos configuration files. After that, the load test can be started by clicking on the corresponding ZIP file.

PKCS#12 Client Certificates

This option enables HTTPS X509 client certificate authentication against web servers. If you choose the option use common, active PKCS#12 certificate from Personal Settings, the same client certificate is used for all simulated users, and this certificate will be automatically transferred into the source code of the script.
By choosing the option apply individual PKCS#12 certificate per user from input file, each simulated user uses its own certificate. In such a case, you must manually create two files:

• pkcs12auth.txt - this text-file contains on each line the PKCS#12 filename and the password of the PKCS#12 file per simulated user. These two line-elements must be separated by semicolons (;)

• pkcs12certs.zip - this zip-file contains in one archive all PKCS#12 client certificate files, which are referenced in pkcs12auth.txt.

Both files must be located in the same directory where the generated script is stored. After compiling the script inside the Project Navigator, you must ZIP the script's compiled class together with the pkcs12auth.txt file and together with the pkcs12certs.zip file (ZIP file inside ZIP file). After that, the load test can be started by clicking on the corresponding ZIP file.

DER/PEM Client Certificates

This option enables HTTPS X509 client certificate authentication against web servers. If you choose the option use common, active DER/PEM certificate from Personal Settings, the same client certificate is used for all simulated users, and this certificate will be automatically transferred into the source code of the script.
Each simulated user uses its own certificate by choosing the option apply individual DER/PEM certificate per user from input file. In such a case, you must manually create two files:

• dpClientCerts.txt - this text-file contains on each line the filename of a DER or PEM encoded client certificate.

• dpClientCerts.zip - this zip-file contains in one archive all DER or PEM encoded client certificate files that are referenced in dpClientCerts.txt.

Both files must be located in the same directory where the generated script is stored. After compiling the script inside the Project Navigator, you must ZIP the script's compiled class together with the dpClientCerts.txt file and together with the dpClientCerts.zip file (ZIP file inside ZIP file). After that, the load test can be started by clicking on the corresponding ZIP file.

Program Description

Optional, free text description of the script. The description will be transferred to the generated java code and displayed as a hint in the Project Navigator file list.

Tip: After entering a Program Description, instead of clicking on the Continue button, you can also press the enter key. The following dialogue will then be displayed.

You can choose the Project Navigator directory on the left-hand side in which the load test program will be stored. The current directory is marked in grey. You can also create new subdirectories by clicking on the Create New Subdirectory icon.

On the right-hand side, the title Display Script Java Program is shown. This allows you to view/examine the automatically- generated load test program before it is stored.

Directly below this, the Response Verification Summary is shown. This contains an extract of the automatically-applied content test configuration. The overview contains only URLs

a) whose received content is verified by a search string (text fragment), or

b) whose content test configuration was manually modified; for example, a disabled content test configuration for a particular GIF image because it was a rotating banner advertisement

You can again modify the content test configuration by clicking on the corresponding magnifier icons. It is recommended that you save the web session after making any changes. This can be done by clicking on the Save Recorded Session Icon.

To store and compile the automatically-generated load test program:

• As needed, enable the checkbox Overwrite & Compile.

  • In this example, we will check the box.

• Click the Generate Script button.

The newly-created (and compiled) script is marked with a dark grey background and can now be started by clicking on the Execute Load Test icon to the file's far-right.

Load Test Programs with Dependent Files

Executable load test programs (*.class files) that use dependent files, such as Input Files or Plugins, must first be zipped together with the dependent files into a single ZIP archive.

Thereafter, the ZIP archive must be started as the load test program. The GUI checks whenever a simple load test program (*.class file) is started to see if Input Files or Plugins are needed.