Generate Program

Only URLs which are visible in the main menu are used by the load test program. This means that you can use the URL filter to exclude certain types of URLs from being executed by the load test program.

image

Filter Input Fields
No Binary Data (Images ...) suppresses all URLs which are 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 web server (recommended option).
No Errors suppresses all URLs with an incomplete response from the web server, and also suppresses all error responses from the web server (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 host names 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 Handler menu to generate the load test program.

image

image

Normally, you should only have to enter the name of the load test program and to configure the Runtime Execution Behavior (serial or parallel execution order of the URLs within the Web pages - applied per simulated user), without having to choose or modify any other options.

Special options are only needed if:

  • You have to execute the load test over an outbound proxy server
  • You want to use more than one user account for Basic Authentication or if Digest Authentication is required against the web server
  • NTLM authentication was required to record the web surfing session
  • An X509 client certificate was required to record the web surfing session
Input Fields
Java™ Classname Desired name of the load test program. .
Content Test Algorithm Defines how the received content of the URL calls will be verified during the load test:.

- [+]   apply (heuristic) methods from recorded session: Means that the automatically-applied content test algorithms will be used, including for modifications which 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 which ensures that the received web pages are correctly verified.

  • [±]   compare all URL calls with recorded size (+/- 5%): Means that only the size of the received content 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 you may not detect some errors which are embedded within a HTML page which is of the correct size.
  • [-]   none - content test disabled: 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 for 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.
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.
Accept \*/\* Header Field 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 use this option only if you have no direct TCP/IP connection between the load test program and the web server.
Basic Authentication This option enables user-specific, individual, basic authentication against the web server. 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 compiled class of the load test program 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 web server. If you choose the option use common Username / Password, the same username and password is used for all simulated users. By choosing the option Apply individual Digest Authentication per user from 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 together with the digestauth.txt file and then you must execute the zipped archive itself as load test program.
NTLM Authentication This option enables NTLM (Windows) authentication. If you choose the option use common NTLM account from Personal Settings menu , the same NTLM username and password is 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 compiled class of the load test program together with the ntlmauth.txt file and then execute the zipped archive itself as load test program.
HTTPS Client Certificates This option enables HTTPS X509 client certificate authentication on the load test program. If you choose the option use common, active PKCS# 12 certificate from Personal Settings menu , the same client certificate is used for all simulated users, and this certificate will be automatically transferred into the source code of the load test program. If you choose the option apply individual PKCS# 12 certificate per user from input file, each simulated user uses its own certificate, in which case you must manually create two Input Files:.

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

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

Both Input Files 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 compiled class of the load test program together with the pkcs12auth.txt file and pkcs12certs.zip files. Then you must execute the zipped archive itself as load test program.

Program Description optional, arbitrary text description of the load test program. The description will be transferred to the generated Java code.

Tip: Instead of clicking on the Continue button, you can also just press the enter key. The following dialogue will then be displayed:

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

On the right-hand side, the title Display Load Test 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

Here 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 you have made any changes. This can be done by clicking on the icon.

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

  • Enable the checkbox Overwrite & Compile
  • Click the Save Load Test Program button

The Project Navigator menu will then be displayed:

image

The newly-created (and compiled) load test program is marked with a dark blue background and can now be started by clicking on the icon.

Executable load test programs (*.class files) which 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 itself must be started as the load test program. The GUI checks every time when a simple load test program (*.class file) is started to see if Input Files or Plugins are needed. If so, you will receive an appropriate information message, with the hint that you must build a ZIP archive for the load test. This can easily be done by just clicking on the “ ZIP and execute…” button:

image

Background information: load test programs can also be transferred and executed on remote systems in the same manner as on the local system; therefore, all data which are needed during program execution must be packed to one ZIP archive.

If the load test program contains other dependent files which are not Input Files and not Plugins - for example files which should be uploaded to the web server - you have create the ZIP archive manually by using the ZIP functionality of the Project Navigator. The corresponding instructions are displayed in the lower part of the window.

Tip: if the date of one of the files which has been added to the ZIP archive is newer than the date of archive itself, you will be asked, at the start of the load test, if the archive should be automatically re-zipped. This means that you only have to create the ZIP archive once; afterwards, you can just start the zipped load test program directly:

image